I am trying to generate a v5 UUID by referring to the function (http://www.ietf.org/rfc/rfc4122.txt) :
/* uuid_create_sha1_from_name -- create a version 5 (SHA-1) UUID
using a "name" from a "name space" */
void uuid_create_sha1_from_name(
uuid_t *uuid, /* resulting UUID */
uuid_t nsid, /* UUID of the namespace */
void *name, /* the name from which to generate a UUID */
int namelen /* the length of the name */
);
I have read the help, but I am still not clear on what is the difference between the 2nd(uuid_t nsid) and 3rd (void *name) parameters of above function?
Could someone explain me the above with an example ?
I would also like to understand what the below means in the RFC4122 link and does it have any significance to the 2nd parameter ?
/* Name string is a URL */
uuid_t NameSpace_URL = { /* 6ba7b811-9dad-11d1-80b4-00c04fd430c8 */
0x6ba7b811,
0x9dad,
0x11d1,
0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
};
The name is the key that is unique to whatever thing you're generating uuid's for
The namespace is a constant UUID that identifies the context in which you're generating UUIDs
If you look at the RFC, you'll see section 4.3 defines these characteristics of a name-baesed UUID:
The UUIDs generated at different times from the same name in the
same namespace MUST be equal.
The UUIDs generated from two different names in the same namespace
should be different (with very high probability).
The UUIDs generated from the same name in two different namespaces
should be different with (very high probability).
If two UUIDs that were generated from names are equal, then they
were generated from the same name in the same namespace (with very
high probability).
These are all important properties to have in a name-based UUID. For example, let's say you and I are implementing HR systems for our respective companies. The systems are completely unrelated to one another, but because UUIDs are awesome, we're both using name-based UUIDs to identify employees. And because it's a rather obvious thing to do, we use employee names as the name from which the UUIDs are generated.
Without namespaces we would both create the same UUID for anyone named "John Smith"... but that'd be Bad (tm) since our systems are unrelated and we're dealing with different John Smiths. "So what," you say! ... but what happens when our companies merge next year and we have to combine our HR databases? Well, at that point we find ourselves merging database records that have the same ID and pretty soon the paychecks for every John Smith in the company are crossing in the mail and HR is handing us our pink slips.
To prevent this sort of thing from happening, the RFC specifies that we each independently choose a UUID to use as our namespace. Namespaces will typically be fixed and associated with a specific system in which UUIDs are being generated, so we'll probably just hardcode this as a constant in some configuration file somewhere. Thus, within my namespace (e.g. 87c9cdf7-101d-4c05-a89d-c7aaff3a3fcf) I can trust that the UUID I generate for John Smith will always be the same. But I can also count on it being different from any UUID you create since you'll be using a different namespace. And so if/when our systems merge, there won't be any issues.
Quoting from section 4.3 of the RFC, there is this step:
Allocate a UUID to use as a "name space ID" for all UUIDs generated from names in that name space; see Appendix C for some pre-defined values.
As far as I understand this, the aim of this namespace is to ensure that using the same name with the same meaning will result in the same UUID, whereas using the same name with a different meaning will result in a different UUID. The namespace UUID is concatenated with the actual name, and both are hashed together.
The code snippet about the 6ba7b811-9dad-11d1-80b4-00c04fd430c8 UUID comes from that section C. So when you use that as a namespace, you should use a URL as a name. For example, you'd call the function as
uuid_t result_uuid;
const char* url = "http://www.example.com/document.txt";
uuid_create_sha1_from_name(&result_uuid, NameSpace_URL, url, strlen(url));
In contrast to this, a UUID for the whole example.com domain would be created using
uuid_t result_uuid;
const char* domain = "example.com";
uuid_create_sha1_from_name(&result_uuid, NameSpace_DNS, domain, strlen(domain));
Related
Is it possible to decode the namespace or the name from a given UUID?
My idea is to generate the uuid with a particular namespace or name later and later retrieve it to check whether 2 UUIDs belong to the same namespace or name. Is this possible?
As stated in RFC4122, UUID3 and UUID5 namespaces and names are hashed (with either MD5 or SHA1), which means there is no other way to “decode” the namespace or name from a given UUID than bruteforce (that is the whole point of hash functions).
Compute the hash of the name space ID concatenated with the name.
RFC422 - 4.3 - Algorithm for Creating a Name-Based UUID
However you can directly compare the hashed namespaces and name to detect whether two UUIDs belong to the same namespace and have the same name, indeed. Here is an example in Python (using the standard uuid module):
import uuid
name = 'stackoverflow.com'
a = uuid.uuid5(namespace=uuid.NAMESPACE_DNS, name=name)
b = uuid.uuid5(namespace=uuid.NAMESPACE_DNS, name=name)
assert a == b
print(a)
print(b)
cd84c40a-6019-50c7-87f7-178668ab9c8b
cd84c40a-6019-50c7-87f7-178668ab9c8b
'id' command does give me all the supplementary groups, but the following code is just returning the primary groups for which the use belongs:
gid_size = getgroups(0, NULL); //1 is getting returned here
grouplist = malloc(gid_size * sizeof(gid_t));
getgroups(gid_size, grouplist); //Even with gid_size>1, only primary groups is returned.
My question is, whether there's any other alternative way to get all the supplementary groups on macOS.
You should be able to get up to 16 more groups by invoking initgroups() first, but even this is not ideal.
From the initgroups(3) man page:
Processes should not use the group ID numbers from getgroups(2) to determine a user's group membership. The list obtained from getgroups() may only be a partial list of a user's group membership. Membership checks should use the mbr_gid_to_uuid(3), mbr_uid_to_uuid(3), and mbr_check_membership(3) functions.
So if you're trying to check if the user is a member of a specific group, the mbr_*() functions are the way to go.
Note that the source code of the id command is available and based on a very quick inspection it looks like it uses the undocumented getgrouplist_2().
It looks like this is a variant of the getgrouplist() function, but without the 16-group limitation.
I don't think this function is declared in any public headers, id.c uses the prototype
int32_t getgrouplist_2(const char *, gid_t, gid_t **);
I have a non-standard question to CakePHP 3.3. Let's imagine that in my database I have two tables: A and B (both are identical, first is dedicated for data in the first language, second is dedicated for data in the second language).
I correctly coded the whole website for table A (table B is not yet in use). Additionally, I implemented the .po files mechanizm to switch the language of the interface. The language of the inteface switches correctly.
How can I easily plug the table B - I do not want to make IF-ELSE statements in all cases because the website is getting big, and there are many operations in table A already included. Is there a possibility to somehow make a simple mapping that table A equals table B if language pl_PL is selected to en_US (through .po files)?
The most simple option that comes to my mind would be to inject the current locale into your existing table class, and have it set the database table name accordingly.
Let's assume your existing table class would be called SomeSharedTable, this could look something along the lines of:
// ...
class SomeSharedTable extends Table
{
public function initialize(array $config)
{
if (!isset($config['locale'])) {
throw new \InvalidArgumentException('The `locale` config key is missing');
}
$table = 'en_table';
if ($config['locale'] === 'pl_PL') {
$table = 'pl_table';
}
$this->table($table);
// ...
}
// ...
}
And before your appplication code involves the model layer, and after it sets the locale of course (that might for example be in your bootstrap), configure the alias that you're using throughout your application (for this example we assume that the alias matches the table name):
\Cake\ORM\TableRegistry::config('SomeShared', [
'locale' => \Cake\I18n\I18n::locale()
]);
Given that it's possible that the locale might not make it into the class for whatever reason, you should implement some safety measures, I've just added that basic isset() check for example purposes. Given that a wrongly configured table class could cause quite some problems, you probably want to add some checks that are a little more sophisticated.
I'm trying to retrieve user information in Active Directory, but am finding some things to be poorly documented. For example, the LDAP connection strings I have seen contain some keywords that I don't know the meaning of. Here's a sample:
LDAP://ofmdcoly302.ofm.wa.lcl/ou=employees,dc=ofm,dc=wa
What are the keywords "ou" and "dc" supposed to signify? In our case "ou=employees" seems to identify a particular AD node. However when I try to do a .FindAll() on the above directory entry, I get "A referral was returned from the server". I guess that means it couldn't find what I was looking for, but it might be available somewhere else? In one place I read "A referral is AD's way of saying, 'this object probably exists in another domain'".
What are "ou" and "dc" supposed to mean? And if I had this A/D structure, how would I code the LDAP connetion string to retrieve information in the "AR" node:
ou and dc are not keywords, they are attributes, "organizational unit" and "domain component", respectively. Attributes are defined in the directory server schema. Attributes are gathered together into entries, of which the distinguished name is the primary key.
Taken in this context, ou and dc are "distinguished name components", together comprising a "distinguished name", which is the aforementioned primary key of an LDAP entry. ou=employees,dc=ofm,dc=wa is a distinguished name composed of the various relative distinguished name components.
This entry has two mistakes: it's not using root (dc=lcl), you also skipped one ou, should be ou=employees,ou=Users - OFMGOV,dc=ofm,dc=wa,dc=lcl
TBH if your really want to understand this notation I would suggest using ADSI Edit instead of ADUC that you probably use ATM - it will show you path the same way, so it will be easier to translate. It will also prevent you from shooting yourself in a foot with special containers like 'CN=Users' and 'CN=Computers':
For the OU you have highlighted it would most likely be:
ou=AR,ou=Citrix,ou=Users - OFMGOV,dc=ofm,dc=wa,dc=lcl
I'm trying to avoid reinventing the wheel when it comes to storing street addresses in a table only once. Uniqueness constraints won't work in some common situations:
100 W 5th Ave
100 West 5th Ave
100 W 5th
200 N 6th Ave Suite 405
200 N 6th Ave #405
I could implement some business logic or a trigger to normalize all fields before inserting and use uniqueness constraints across several fields in the table, but it would be easy to miss some cases with something that varies as much as street addresses.
What would be best would be a universal identifier for each address, perhaps based on GPS coordinates. Before storing a new address look up its GUID and see if the GUID already exists in the Address table.
An organization like Mapquest, the Postal Serice, FedEx, or the US government probably has a system like this.
Has anyone found a good solution to this?
Here's my Address table now (generated by JPA):
CREATE TABLE address
(
id bigint NOT NULL,
"number" character varying(255),
dir character varying(255),
street character varying(255),
"type" character varying(255),
trailingdir character varying(255),
unit character varying(255),
city character varying(255),
state character varying(255),
zip integer,
zip4 integer,
CONSTRAINT address_pkey PRIMARY KEY (id)
)
Look up the address in Google maps and use the spelling they use.
You need support for regular expressions like syntax. You can come up with some kind of automata function that will parse tokens and try matching them and then expand or contract them into abbreviations. I'd look into glob() like functions that give support to *? etc on unix as a quick dirty fix.
I wasn't looking for address validation or normalization, although address validation is a good idea. I need a unique identifier for each street address to avoid duplicate records.
It looks like geocoding can provide a solution. With geocoding the input can be a street address and the output will be latitude and longitude coordinates with enough precision to resolve a specific building.
There's a more serious problem with street address ambiguity than I thought. This is from the Wikipedia page on geocoding:
"...there are multiple 100 Washington Streets in Boston, Massachusetts because several cities have been annexed without changing street names."
The Wikipedia page on geocoding has a list of resources (many free) to perform geocoding.
I settled on the USC WebGIS service due to their nice web service interface and being easy to sign up for.
Geocodes aren't suitable as a unique key for street addresses, though, for a number of reasons. For example, geocoding cannot distinguish between different units in a condominium complex or apartment building.
I decided to use the parsed address from the geocoding result and put unique constraints on the street number, street name, unit, city, state, and zip. It's not perfect, but it works for what I'm doing.