The validation pattern UUID module provides needs a little refinement. The current pattern simply checks for hexidecimal numbers, lowercased, in the pattern 8-4-4-4-12. The accepted patterns are a little more nuanced than that.


In the canonical representation, xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, the most significant bits of N indicates the variant (depending on the variant; one, two, or three bits are used). The variant covered by the UUID specification is indicated by the two most significant bits of N being 1 0 (i.e., the hexadecimal N will always be 8, 9, A, or B).

The variant covered by the UUID specification has five versions. For this variant, the four bits of M indicates the UUID version (i.e., the hexadecimal M will be either 1, 2, 3, 4, or 5).

Additionally, UUIDs are case-insensitive, per RFC4122 Section 3:

'The hexadecimal values "a" through "f" are output as lower case characters and are case insensitive on input'.

More detailed info is available from the RFC4122 document (which I know the maintainers are familiar with; not implying anything).

I'll attach a patch with an updated validation pattern.



timcosgrove’s picture

Patch attached.

  • skwashd committed 18bb3ea on 7.x-1.x authored by timcosgrove
    Issue #2365281 by timcosgrove: Refine UUID validation pattern
  • skwashd authored 447c0c9 on 7.x-1.x
    Merge pull request #6 from skwashd/uuid-2365281-uuid-validation
    Issue #...
skwashd’s picture

Status: Active » Fixed

Nice catch. Thanks for the patch, I've applied it.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

sylus’s picture

It looks like this change results in all of my features needing to be updated.

Brief example:

            'sidebar' => array(
-             0 => 'new-084cd973-73fa-87d4-9dc4-d1e195a45dfd',
-             1 => 'new-15d0ad18-f2b8-9c64-7573-176bf8bc58dc',
-             2 => 'new-3fbeea9b-b02b-7ed4-41ec-378fb72d541e',
-             3 => 'new-8ca4ffdd-3548-2854-69f4-cc530df7cd6b',
-             4 => 'new-8f2de99f-296c-e514-c143-e283b888ebf8',
-             5 => 'new-95564a77-8b5b-4c74-0dfa-5117da097884',
-             6 => 'new-d8ca4dfe-15a7-4ae4-451e-a0a39e495ada',
+             0 => 'new-42032f9c-f021-4341-99e7-05d41bef0c8a',
+             1 => 'new-5d26405b-45a8-43cd-8362-01a54c301209',
+             2 => 'new-6649b5a1-ebe3-4d46-ae24-bf116717fba2',
+             3 => 'new-757cf4f0-25eb-4ecd-ae29-483d6d75d118',
+             4 => 'new-b1ba1e92-7d5b-4e0b-b641-37b5ab1c32a2',
+             5 => 'new-c7ce28d7-9b0d-4f41-bcf4-53bedb0da6fa',
+             6 => 'new-ee225632-8f13-48f6-b0fe-fc9aaf1b0ece',

My real concern is that say a UUID context was leveraged and that is in the feature. Would that original UUID still work?

skwashd’s picture

@sylus please open a new issue for you problem. This patch was applied several weeks ago and included in a release.

A quick check of the posted UUIDs, the first batch validated as generic UUIDs. The second batch are valud v4 UUIDs. I used for the validation.