provide a .verify(uuid) method about uuid HOT 12 CLOSED

Interesting idea. For starters, I'm not sure how much demand there is for this - this is the first request I've had. But... I'm not completely averse to the idea (obviously, or I wouldn't have bothered including with the parse() method :) )

Second, and more important, I worry that this is a slippery slope. Validating v4 IDs is sufficiently trivial (just check the variant and version fields) that it's not clear how much value we'd be adding. (But, agreed, it's arguably part of the problem space we're tackling). v1 IDs are a different story. If you care about validating v1 IDs, it's not unlikely that you'd care about more than insuring valid variant and version fields. You probably also care about things like insuring consecutive IDs have increasing timestamps.

So... what specifically would you expect a verify() method to be validating.

from uuid.

My use case was less so about validating a specific type of ID and more about validating that it matched a valid format (either with the dashes or without).

This came up when I was processing user input (a uuid) and giving it to postgres in a where clause. Postgres has builtin support for handling uuid but sends errors in the uuid is malformed. So instead of sending this query off to postgres with malformed uuid and then getting an error back, I check the uuid first and send a BadRequest back to the user if their input is erroneous.

Maybe my use case was too specific but I figured others might also like a simple "string" validation before trying to use the uuid in queries or other cases.

from uuid.

Right now I am just using the following regex(ies?) to validate:

var valid_re1 = /[0-9a-f]{22}/;
var valid_re2 = /[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}/;

It gets the basic job done for me.

// true if str is a valid uuid
uuid.is_valid = function(str) {
    str = str.toLowerCase();
    return (valid_re1.test(str) ? true : valid_re2.test(str));
};

from uuid.

So basically what you're asking for is "validateUUIDWontBreakPostgres(...)" :) Which implies we would have to duplicate whatever logic Postgres is using (which may simply be your regexs, for all I know.)

Providing a one-liner regex check is nice, but probably not that useful to the majority of node-uuid users currently. btw, the one-liner version of your method:

uuid.validate = function(str) {
  return /[0-9a-f]{22}|[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}/i.test(str);
}

I'd like to hear from other people on what they'd like a validate method to do before adding anything to the API. To that end, I'd invite you to post a pull request that people could comment on (with the understanding that it may sit indefinitely if there just isn't sufficient interest.)

Sound reasonable?

from uuid.

Sure, but to the same end it also validates the uuid string for anyone else wishing to use it for some sort of input.

I agree, more input on what it should do is worth hearing. I will not be crushed if this is not added to the API, it was just a suggestion and figured others might have similar use cases :)

from uuid.

+1 on some sort of verification method. I actually expected parse to throw some sort of error when handing it a bad id but it just zero padded the rest of the id it handed back.

from uuid.

@xstevens - what would you require of a verification method? Is a simple regex like the above sufficient, or do you need something more that's more rigorous in how it enforces RFC any constraints defined by the RFC?

from uuid.

Personally, the regex enforcement would probably be sufficient. From an API perspective though I think there would be an expectation from users to make sure that it's RFC compliant.

from uuid.

I think the regex approach is at least a start (and fast). For the cases I have encountered validation was more about making sure the string fit the correct layout rather than specific RFC compliance.

from uuid.

Since there is a parse/unparse method which expects some sort of string. A validation method which can accept the same types of strings does not seem that crazy. At least the first pass can validate using something simple.

from uuid.

👍

I want this as a preventative measure against abuse of a publicly-visible webservice I'm running, i.e. "don't accept requests with an invalid uuid"

from uuid.

Continuing this in #72

from uuid.