[Yahoo-eng-team] [Bug 1689468] Re: odd keystone behavior when X-Auth-Token ends with carriage return

2017-08-04 Thread Lance Bragstad 
This appears to be addressed by the keystonemiddleware patch. Marking
this as invalid for keystone server. Please feel free to reopen if the
issue resurfaces.

** Changed in: keystone
   Status: In Progress => Invalid

-- 
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):
  Invalid
Status in keystonemiddleware:
  Fix Released

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=
  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

[Yahoo-eng-team] [Bug 1689468] Re: odd keystone behavior when X-Auth-Token ends with carriage return

2017-08-01 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/482971
Committed: 
https://git.openstack.org/cgit/openstack/keystonemiddleware/commit/?id=efb1fb99d87f754a008877f2e2d391221cb43721
Submitter: Jenkins
Branch:master

commit efb1fb99d87f754a008877f2e2d391221cb43721
Author: Matthew Edmonds 
Date:   Wed Jul 12 09:45:59 2017 -0400

strip whitespace from token

This change strips whitespace from incoming tokens to prevent errors
that are difficult for a caller to root cause.

Change-Id: I4b3fd18314c3ca94beb3b0c8c17280451d6c8755
Closes-Bug: #1689468


** Changed in: keystonemiddleware
   Status: In Progress => Fix Released

-- 
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):
  In Progress
Status in keystonemiddleware:
  Fix Released

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=
  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

[Yahoo-eng-team] [Bug 1689468] Re: odd keystone behavior when X-Auth-Token ends with carriage return

2017-07-12 Thread Gage Hugo 
** Also affects: keystonemiddleware
   Importance: Undecided
   Status: New

** Changed in: keystonemiddleware
   Status: New => In Progress

-- 
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):
  In Progress
Status in keystonemiddleware:
  In Progress

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=
  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