URL parsing issue with IPv6 Auth URL in Keystone Client 0.3.2

[boddepalli srikanth]

While executing keystone commands with IPV6 auth URL (OS_AUTH_URL) we are facing parsing issues.
Following are the details:

Auth URL:
    OS_AUTH_URL=http://[2001:ef07::1234]:5000/v2.0

>> keystone --debug user-list

REQ: curl -i -X POST http://[2001:ef07::1234]:5000/v2.0/tokens -H "Content-Type: application/json" -H "User-Agent: python-keystoneclient"
REQ BODY: {"auth": {"tenantName": "admin", "passwordCredentials": {"username": "admin", "password": "admin"}}}

Authorization Failed: Failed to parse: Failed to parse: 2001:ef07::1234:5000

[Dolph Mathews (dolph)]

I recall a similar issue being fixed in keystoneclient.middleware.auth_token since 0.3.2, but I'm betting this is still an issue in the 0.4.x series.

[Davanum Srinivas (DIMS) (dims-v)]

One fix for python-keystoneclient went in https://launchpad.net/bugs/1208784 (commit - https://github.com/openstack/python-keystoneclient/commit/852421130dd8a950377056b4b24d942d807ed672)

[Will Angenent (will-angenent)]

I've run into another validation problem as well using Juno keystone v3. This test code demonstrates the problem with the regular expression:

import re

foo = {
    'pat': '^https?://'
           '(?:(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?\.)'
           '+[a-zA-Z]{2,6}\.?|'
           'localhost|'
           '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})'
           '(?::\d+)?'
           '(?:/?|[/?]\S+)$'
}

pat = foo['pat']

print bool(re.match(pat, 'https://foo')) # Bad
print bool(re.match(pat, 'https://foo.l')) # Bad
print bool(re.match(pat, 'https://foo.lo')) # Good
print bool(re.match(pat, 'https://foo.loc')) # Good
print bool(re.match(pat, 'https://foo.loca')) # Good
print bool(re.match(pat, 'https://foo.local')) # Good
print bool(re.match(pat, 'https://foo.locald')) # Good
print bool(re.match(pat, 'https://foo.localdo')) # Bad
print bool(re.match(pat, 'https://foo.localdoma')) # Bad

It appears the above domain name has to be between 2 and 6 characters. The [a-zA-Z]{2,6} part is responsible for that. Looking at the diff for the IPv6 fix, it should solve this one too.

[Will Angenent (will-angenent)]

Oops, comment #3 was meant to go into bug https://bugs.launchpad.net/keystone/+bug/1386376, although it is also relevant.