Bug 1124146
Summary: | Met "Unable to complete the requested operation due to: "\xE6" from ASCII-8BIT to UTF-8" when run domain/app/account commands using '-l' option with non-existing user | ||||||
---|---|---|---|---|---|---|---|
Product: | OpenShift Online | Reporter: | XiuJuan Wang <xiuwang> | ||||
Component: | oc | Assignee: | Jordan Liggitt <jliggitt> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | libra bugs <libra-bugs> | ||||
Severity: | low | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 2.x | CC: | bleanhar, bmeng, decarr, jliggitt, jokerman, mmccomas | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2014-10-10 00:49:54 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
XiuJuan Wang
2014-07-29 05:28:12 UTC
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. |