Description of problem: Run domain/app/account relevant commands with a non-existing user using -l option,meet spring error. # rhc domain show -l xiu1 Unable to complete the requested operation due to: "\xE6" from ASCII-8BIT to UTF-8 Reference ID: 8267daa852089ddfe158dfd59454fe58 After setup this user,run above command again,could domain show this user. Full log of development.log in attachment. Version-Release number of selected component (if applicable): devenv_5020 rhc-1.28.4 How reproducible: always Steps to Reproduce: 1.Domain show a non-existing user with -l option 2. 3. Actual results: # rhc domain show -l xiu1 Unable to complete the requested operation due to: "\xE6" from ASCII-8BIT to UTF-8 Reference ID: 8267daa852089ddfe158dfd59454fe58 Expected results: Could domain show a non-existing user Additional info: Get infomation of an non-existing user via restapi curl -k -u xiu1:redhat https://ec2-184-73-45-239.compute-1.amazonaws.com/broker/rest/domains|json_reformat { "api_version": 1.7, "data": [ ], "messages": [ ], "status": "ok", "supported_api_versions": [ 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7 ], "type": "domains", "version": "1.7" }
Created attachment 922028 [details] Fulllog of developemt.log
Also met this issue during create app with downloadable cartridge on my devenv_5021. ^[[0;37m2014-07-29 09:04:00.929^[[0m [^[[0;37mDEBUG^[[0m] FAILURE ACTION=LIST_DOMAIN USER_ID=53d7999427552536f9000001 LOGIN=bmeng DOMAIN= Unable to complete the requested operation due to: "\xE6" from ASCII-8BIT to UTF-8 (pid:147) Seems it failed to get the domain info for the user.
Often happens when the broker trying to generate a token for a new user which without -p option passed in the rhc cli.
It's not clear what the intended behavior for the request should be from the CLI, and the expectation from the corresponding REST request. This also appears to be a consequence of the devenv environments and do not think it should be a blocker bug for release. Should the CLI send a request where a -l is provided but not a corresponding -p? To be clear, we are not intending to support impersonation of another user via rhc in this scenario?
Could only reproduce on devenvs, lowering severity so it doesn't block the release.
Recreation steps: 1. Set up a user to a server with token auth using rhc setup 2. Make a call to the same server, overriding the user with "-l <username>", specifying a username that doesn't exist. This causes token auth to attempt to help connect to the server, but since we don't have a valid token for the specified user, it sends an empty bearer token, which results in a 500 response: GET /broker/rest/domains HTTP/1.1 accept: application/json;version=1.7 authorization: Bearer This was caused by this change to token auth: https://github.com/openshift/rhc/commit/17db574a Brenton, any suggestions here? Is sending an empty bearer token likely to cause problems like this? We can probably fix the current 500 error (I think we should be getting a 401), but will this break us against older servers?
I tested a few cases in OSE 1.2, 2.0 and 2.1 and whenever an empty bearer token was submitted I saw a 401. I wasn't testing using missing users though.
Ideally, we'd update RHC::Auth::Token#to_request to do the following: if !token and auth and @allows_tokens and client and client.supports_sessions? debug "Attempting to generate token" token_rejected(nil, client) end if token debug "Using token authentication" (request[:headers] ||= {})['authorization'] = "Bearer #{token}" elsif auth debug "Bypassing token auth" auth.to_request(request, client) end request This would require a few things: 1. Passing client into Auth#to_request 2. Avoiding involving the auth chain in the initial /rest/api request (to avoid recursion) 3. Making token_rejected tolerate a nil "response" object
Short-term, we should avoid sending an empty Bearer token, if only by sending an invalid token like "DEADBEEF"
Fixed token auth to not sent empty tokens in https://github.com/openshift/rhc/pull/636 Please verify
test with rhc-1.29.6 Can't reproduce this issue. This issue could pass when the broker trying to generate a token for a new user which without -p option in the rhc cli.