1097780 - python-client: Figure out temporary credentials issue in taskcluster-client.py

Status: RESOLVED FIXED

(Taskcluster :: Services, defect)

Description

[John Ford [:jhford] CET/CEST Berlin Time]

Temporary credential generation doesn't work properly in the Python client for Taskcluster.  I'm not 100% sure why, as the data generated by the Python client is seemingly equivalent to that generated by the JS client.  Once the UUID routine is modified to return a constant string, the exact same access token is generated.  The only differences I see are the ordering of the JSON contained in the returned credentials.

Comment 1

[John Ford [:jhford] CET/CEST Berlin Time]

See https://github.com/jhford/taskcluster-client.py/commit/cd70ad535a0cc8d597e9cbe38c5409946dee0c5e for more details

Comment 2

[Pete Moore [:pmoore][:pete]]

I can also have a look at this when I work on bug 1179789. Maybe I'll hit the same issue!

Comment 3

[Pete Moore [:pmoore][:pete]]

https://github.com/jhford/taskcluster-client.py/blob/cd70ad535a0cc8d597e9cbe38c5409946dee0c5e/taskcluster/client.py#L526 looks suspicious - I think scopes here is an array, but http://docs.taskcluster.net/auth/temporary-credentials/#signature-generation says each scope should be on a new line.

I'll add some debugging to check...

Comment 4

[Pete Moore [:pmoore][:pete]]

Oh I am dumb! As soon as I submitted that, I spotted the scopes sit inside the join method, not outside it. Whoops. Ignore comment 3!

Comment 5

[Pete Moore [:pmoore][:pete]]

So I looked at this too, and reached the same conclusion, I get e.g.:

taskcluster-client:

{
  "clientId": "clientId",
  "accessToken": "AKUz6E8M1x2DoJFxL2oey0GUZwIg5bITKfYrx9K6xH8",
  "certificate": "{\"version\":1,\"scopes\":[\"auth:credentials\"],\"start\":1415741173,\"expiry\":1415741173,\"seed\":\"MkT8gE3gRgOzM1Z3Ai_ilwZBqX-G9mQkyCM_EB-CSMqw\",\"signature\":\"zBRvaGBIik7W4Ts9gzUuJ40mEW1X/Gi70ys6ekMEFT4=\"}"
}

taskcluster-client.py:

{
  "certificate": "{\"scopes\":[\"auth:credentials\"],\"version\":1,\"expiry\":1415741173,\"start\":1415741173,\"seed\":\"MkT8gE3gRgOzM1Z3Ai_ilwZBqX-G9mQkyCM_EB-CSMqw\",\"signature\":\"zBRvaGBIik7W4Ts9gzUuJ40mEW1X/Gi70ys6ekMEFT4=\"}", 
  "accessToken": "AKUz6E8M1x2DoJFxL2oey0GUZwIg5bITKfYrx9K6xH8", 
  "clientId": "clientId"
}

They are indeed the same objects, but the ordering is different.

I don't think this is a problem though. Do the properties need to appear in a given order?

Comment 6

[Pete Moore [:pmoore][:pete]]

The json spec (http://www.json.org/) says:

"An object is an unordered set of name/value pairs."

So I think by definition the orders should not matter.

I did spot one anomaly though: in the javascript implementation, if start is not specified, the current timestamp is used. However, in the python library, the now variable is generated, but never used[2].

1: https://github.com/taskcluster/taskcluster-client/blob/b9d45bc23b8755bec792138b9b2458a08bd49cd5/lib/client.js#L584-L591
2: https://github.com/taskcluster/taskcluster-client.py/blob/694f3b2bfba3ee04497e8b3cbf017c44c5e2ca0a/taskcluster/client.py#L519-L520

Comment 7

[John Ford [:jhford] CET/CEST Berlin Time]

(In reply to Pete Moore [:pmoore][:pete] from comment #6)
> "An object is an unordered set of name/value pairs."
> 
> So I think by definition the orders should not matter.

I wouldn't put much stock in JSON implementers all adhering to the spec sadly.  It could be that this is being parsed by a dumb/bad json parser, or not even a json parser at all.  I don't know the details.

I think that sadly the next step here is to use a formatter and spit out exactly the JSON we need, sadly.  Yuck!
 
> I did spot one anomaly though: in the javascript implementation, if start is
> not specified, the current timestamp is used. However, in the python
> library, the now variable is generated, but never used[2].

Hmm, the start parameter is not a kwarg, so it has to be passed.  I guess it could be passed as None and we should use now in that case.  I remember this failing with an explicit 'start' param being passed in.

Comment 8

[Jonas Finnemann Jensen (:jonasfj)]

So you guys should probably look at the logs for the service you are hitting, check the error message:
https://github.com/taskcluster/taskcluster-base/blob/master/api.js#L145-L225

In taskcluster-client I debug with a local node server, so it's easy to get errors.
But if you use something low traffic like auth it should be easy to find the error message.

Comment 9

[Jonas Finnemann Jensen (:jonasfj)]

I think this was fixed long ago..