Public bug reported: I had to root cause a very odd problem today, where a user complained that they had a token that worked with neutron but didn't work with keystone. E.g. they could list networks, but couldn't list projects. I thought there must be some mistake, but I was finally able to reproduce it and they were correct. Here's a script that shows the problem:
OPENSTACK=<my_ip_address> AUTH_FILE=/root/auth.json TOKEN=`curl -s -1 -k -i -X POST https://$OPENSTACK:5000/v3/auth/tokens -H "Accept:application/json" -H "Content-Type: application/json" -d @${AUTH_FILE} | grep X-Subject-Token | awk '{FS=":"; print $2}'` echo 'neutron:'; curl -1 -k -X GET https://$OPENSTACK:9696/v2.0/networks -H "X-Auth-Token: $TOKEN" -H "Content-Type: application/json"; echo; echo echo 'keystone:'; curl -1 -k -X GET https://$OPENSTACK:5000/v3/projects -H "X-Auth-Token: $TOKEN" -H "Accept: application/json"; echo; echo With debug=True and insecure_debug=True and default_log_levels=keystonemiddleware=True, this yields something like: neutron: {"networks": []} keystone: {"error": {"message": "auth_context did not decode anything useful (Disable insecure_debug mode to suppress these details.)", "code": 401, "title": "Unauthorized"}} I was finally able to figure out why... the awk command used to parse the token out of the X-Subject-Token header was leaving a \r on the end of the $TOKEN value, and apparently that's handled fine when you make the request to neutron (and presumably any non-keystone service), but not when you are talking to keystone directly. That makes some sense, since keystone has to do its own token validation differently. Changing the following line in the script above (adding the gsub to trim the \r) fixed the issue: TOKEN=`curl -s -1 -k -i -X POST https://$OPENSTACK:5000/v3/auth/tokens -H "Accept:application/json" -H "Content-Type: application/json" -d @${AUTH_FILE} | grep X-Subject-Token | awk '{FS=":"; gsub(/\r$/,"",$2); print $2}'` We should fix this to be consistent with non-keystone token validation, to save someone else the trouble debugging this if nothing else. Keystone was doing weird things, where the debug logs would show that the context knew the user and roles, but had no token... leaving one to wonder how it figured out the user and roles if it didn't have a token?!? Not a good user experience for someone trying to write a script to our APIs. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1689468 Title: odd keystone behavior when X-Auth-Token ends with carriage return Status in OpenStack Identity (keystone): New Bug description: I had to root cause a very odd problem today, where a user complained that they had a token that worked with neutron but didn't work with keystone. E.g. they could list networks, but couldn't list projects. I thought there must be some mistake, but I was finally able to reproduce it and they were correct. Here's a script that shows the problem: OPENSTACK=<my_ip_address> AUTH_FILE=/root/auth.json TOKEN=`curl -s -1 -k -i -X POST https://$OPENSTACK:5000/v3/auth/tokens -H "Accept:application/json" -H "Content-Type: application/json" -d @${AUTH_FILE} | grep X-Subject-Token | awk '{FS=":"; print $2}'` echo 'neutron:'; curl -1 -k -X GET https://$OPENSTACK:9696/v2.0/networks -H "X-Auth-Token: $TOKEN" -H "Content-Type: application/json"; echo; echo echo 'keystone:'; curl -1 -k -X GET https://$OPENSTACK:5000/v3/projects -H "X-Auth-Token: $TOKEN" -H "Accept: application/json"; echo; echo With debug=True and insecure_debug=True and default_log_levels=keystonemiddleware=True, this yields something like: neutron: {"networks": []} keystone: {"error": {"message": "auth_context did not decode anything useful (Disable insecure_debug mode to suppress these details.)", "code": 401, "title": "Unauthorized"}} I was finally able to figure out why... the awk command used to parse the token out of the X-Subject-Token header was leaving a \r on the end of the $TOKEN value, and apparently that's handled fine when you make the request to neutron (and presumably any non-keystone service), but not when you are talking to keystone directly. That makes some sense, since keystone has to do its own token validation differently. Changing the following line in the script above (adding the gsub to trim the \r) fixed the issue: TOKEN=`curl -s -1 -k -i -X POST https://$OPENSTACK:5000/v3/auth/tokens -H "Accept:application/json" -H "Content-Type: application/json" -d @${AUTH_FILE} | grep X-Subject-Token | awk '{FS=":"; gsub(/\r$/,"",$2); print $2}'` We should fix this to be consistent with non-keystone token validation, to save someone else the trouble debugging this if nothing else. Keystone was doing weird things, where the debug logs would show that the context knew the user and roles, but had no token... leaving one to wonder how it figured out the user and roles if it didn't have a token?!? Not a good user experience for someone trying to write a script to our APIs. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1689468/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp