Fix: Update UUID_REGEX

[kevin-glare]

The current format (/\A\h{8}-\h{4}-\h{4}-[89AB]\h{3}-\h{12}\z/i) supports only the UUID variant DCE Security (89AB).
So I've updated the regular expression to support more uuid variants.
I also noticed that in the tests there is an option using such a regular expression.

[davishmcclurg]

I originally went with this variant because the json schema spec says:

uuid:
A string instance is valid against this attribute if it is a valid string representation of a UUID, according to [RFC4122].

And the variant described in RFC4122 matches [89AB], but I'm ok with loosening the restriction here.

I'm curious: what UUIDs are you seeing that don't match?

[davishmcclurg]

I think we should leave this using \A \h and \z. Should just need to change the {3} to {4} and remove [89AB].

[kevin-glare]

Thank you very much! I have already fixed this to /\A\h{8}-\h{4}-\h{4}-\h{4}-\h{12}\z/i.

The regular expression UUID_REGEX =/\A\h{8}-\h{4}-\h{4}-[89 AB]\h{3}-\h{12}\z/i will not allow the following valid UUIDs to be checked:
• UUID version 1 with odd ninth octets and a sixth octet not equal to 4 or 5.

For example, the following valid UUID will not pass verification:
• d5b7f84c-1b49-11ef-9262-0242ac120002

This is because the regular expression checks whether the ninth octet is one of 89 AB, and in this UUID, the ninth octet is 2.

[kevin-glare]

I remembered another example - Nil UUID
00000000-0000-0000-0000-000000000000

[davishmcclurg]

For example, the following valid UUID will not pass verification: • d5b7f84c-1b49-11ef-9262-0242ac120002

This is because the regular expression checks whether the ninth octet is one of 89 AB, and in this UUID, the ninth octet is 2.

It looks like that UUID validates ok:

repos/json_schemer main % bin/console --simple-prompt
>> schema = JSONSchemer.schema({ 'format' => 'uuid' })
=> #<JSONSchemer::Schema @value={"format"=>"uuid"} @parent=nil @keyword=nil>
>> schema.valid?('d5b7f84c-1b49-11ef-9262-0242ac120002')
=> true
>> schema.valid?('invalid')
=> false

The [89AB] character is a 9 in that example.

I remembered another example - Nil UUID
00000000-0000-0000-0000-000000000000

Nil UUID is handled separately:

json_schemer/lib/json_schemer/format.rb

Line 78 in 6798248

NIL_UUID = '00000000-0000-0000-0000-000000000000'

json_schemer/lib/json_schemer/format.rb

Line 143 in 6798248

UUID_REGEX.match?(data) || NIL_UUID == data

[kevin-glare]

I'm sorry for the confusion. I spent a lot of time, but I could not figure out 100% why this uuid dff55168-b012-11e8-3c87-fa163eb33c9d does not pass validation.

[davishmcclurg]

dff55168-b012-11e8-3c87-fa163eb33c9d doesn't pass because it has a 3 where an 8, 9, A or B are currently expected ([89AB]). Do you know where that UUID came from?

[kevin-glare]

This uuid came to me from an external system. [89AB] is a prerequisite for all versions and variants of uuid? I'm trying to find a different uuid from this condition but I can't do it(
Therefore, I cannot guarantee that this uuid is correct. But in postgresql it is considered valid.

[davishmcclurg]

Thanks @kevin-glare! I just released as this in 2.3.0