Bug 1124146 - 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
Summary: Met "Unable to complete the requested operation due to: "\xE6" from ASCII-8BI...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: OpenShift Online
Classification: Red Hat
Component: oc
Version: 2.x
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: ---
Assignee: Jordan Liggitt
QA Contact: libra bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-29 05:28 UTC by XiuJuan Wang
Modified: 2015-05-15 02:29 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-10 00:49:54 UTC


Attachments (Terms of Use)
Fulllog of developemt.log (15.03 KB, text/plain)
2014-07-29 05:32 UTC, XiuJuan Wang
no flags Details

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@redhat.com 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.


Note You need to log in before you can comment on or make changes to this bug.