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: ocAssignee: Jordan Liggitt <jliggitt>
Status: CLOSED CURRENTRELEASE QA Contact: libra bugs <libra-bugs>
Severity: low Docs Contact:
Priority: medium    
Version: 2.xCC: 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 Flags
Fulllog of developemt.log none

Description XiuJuan Wang 2014-07-29 05:28:12 UTC
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"
}

Comment 1 XiuJuan Wang 2014-07-29 05:32:27 UTC
Created attachment 922028 [details]
Fulllog of developemt.log

Comment 2 Meng Bo 2014-07-29 09:07:34 UTC
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.

Comment 3 Meng Bo 2014-07-29 09:13:26 UTC
Often happens when the broker trying to generate a token for a new user which without -p option passed in the rhc cli.

Comment 4 Derek Carr 2014-07-29 20:22:50 UTC
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?

Comment 5 Fabiano Franz 2014-07-29 21:18:51 UTC
Could only reproduce on devenvs, lowering severity so it doesn't block the release.

Comment 6 Jordan Liggitt 2014-07-30 17:06:40 UTC
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?

Comment 7 Brenton Leanhardt 2014-07-30 17:16:39 UTC
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.

Comment 8 Jordan Liggitt 2014-07-31 15:13:26 UTC
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

Comment 9 Jordan Liggitt 2014-07-31 17:06:31 UTC
Short-term, we should avoid sending an empty Bearer token, if only by sending an invalid token like "DEADBEEF"

Comment 10 Jordan Liggitt 2014-08-15 18:46:01 UTC
Fixed token auth to not sent empty tokens in https://github.com/openshift/rhc/pull/636

Please verify

Comment 11 XiuJuan Wang 2014-08-18 04:34:46 UTC
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.