929704 - Getting 400 No token supplied for modification when creating or editing a bug

Status: RESOLVED FIXED

(Webtools Graveyard :: BzAPI, defect)

Description

[Steve Fink [:sfink] [:s:]]

I don't know if this is bzapi or the underlying stuff, but when creating a bug (via bzexport), I am getting back an error response:

{"bugzilla_url":"https://bugzilla.mozilla.org/process_bug.cgi","error":1,"code":32000,"message":"No token supplied for modification","http_code":"200"}

But it shouldn't need a token, because I'm not modifying -- I'm creating.

I *think* I'm using a POST. I am posting to the URL:

https://api-dev.bugzilla.mozilla.org/latest/bug?userid=359004&cookie=xxxxxxxxxx

with the data

{"status": "ASSIGNED", "product": "Release Engineering", "blocks": [], "cc": [], "depends_on": [], "component": "General Automation", "comments": [{"text": "I could\'ve sworn I had tested this..."}], "summary": "Fix --enable-threadsafe (the new default) JS shell builds", "platform": "All", "version": "unspecified", "assigned_to": {"name": "[e-mail]"}, "op_sys": "All"}

and custom headers

{'Content-Type': 'application/json', 'Accept': 'application/json'}

The bug *is* created. I just get that error back instead of the created bug id.

Comment 2

[Gervase Markham [:gerv]]

Hmm. This is working fine on my local machine with the latest BzAPI and the latest code from the bmo-4.2 bzr repo.

Bugzilla is actually refusing the process_bug.cgi call with a "Suspicious Action" error, implying that it thinks that the token being submitted is invalid. (The "no token" error actually comes from my own code; I will fix that to be more clear.)

The three bugs checked in to BMO recently which might be relevant are bug 917669, bug 927736 and bug 912661. However, I would expect to see the problem locally as well...

Gerv

Comment 3

[Gervase Markham [:gerv]]

My current theory is that the patch for bug 927736 means that it is now required to pass a delta_ts on a call to process_bug.cgi. BzAPI does not do this, and so the token validation fails.

BzAPI does not currently require the submission of delta_ts, known in BzAPI-speak as 'last_change_time' on a change request. So although the client may have this information, they are probably not submitting it. And so we would need to make a request for the full data on a bug before submitting an update request, which would be bad for performance.

In some cases, we have to make such a request anyway in order to get a token (e.g. for the hidden update which can follow a bug creation, or to get details of the current CC list or groups). So we can pass a delta_ts in that case. But I'd rather not extend the number of situations where we have to do that.

glob: can we instead modify the patch for bug 927736 so it takes the value from the bug if there is no value on the request?

i.e.
    check_hash_token($token, [$first_bug->id, $delta_ts || $first_bug->delta_ts]);
?

Gerv

Comment 4

[:glob ✱]

(In reply to Gervase Markham [:gerv] from comment #3)
> glob: can we instead modify the patch for bug 927736 so it takes the value
> from the bug if there is no value on the request?

no, that's the fix for bug 927736

Comment 5

[Gervase Markham [:gerv]]

My line of code above gives the value from the form preference - that avoids bug 927736. Only if no value is submitted (which will not be the case with the standard Bugzilla UI) do we fall back to the known value from the bug itself. 

The upshot, therefore, is simply to avoid mistakenly invalidating perfectly good unused tokens.

Requiring delta_ts on all process_bug.cgi submissions will lead to one of the following two eventualities:

* An API change for all BzAPI users, requiring them all to update their code; or
* A performance hit of one extra round trip bug request, just to get and send the delta_ts (a value Bugzilla already knows!) for every bug update.

Neither of these scenarios is particularly awesome. :-|

Gerv

Comment 6

[:glob ✱]

(In reply to Gervase Markham [:gerv] from comment #5)
> * A performance hit of one extra round trip bug request, just to get and
> send the delta_ts (a value Bugzilla already knows!) for every bug update.

a round-trip won't work as the delta_ts is used to validate the token.


for clarity here's what is happening:

1. an update token is issued, against the bug's delta_ts
2. user submits a form which includes the token
3. the token is validated, which requires a delta_ts
4. if the token is valid, the bug is updated

if the bug has been updated by someone else (ie a mid-air), then the following used to _always_ happen:

1. an update token is issued, against the bug's delta_ts
2. user submits a form which includes the token
3. mid-air detected by checking the provided delta_ts against the bug's current value
4. issue a new token using the bug's new delta_ts
5. display the mid-air confirmation page

recently CC-only changes were changed to not trigger a mid-air:

1. an update token is issued, against the bug's delta_ts
2. user submits a form which includes the token
3. mid-air detected by checking the provided delta_ts against the bug's current value
4. mid-air routine realises that only the CC field was changed, bails out
5. the token is validated, which requires a delta_ts

before bug 927736, the token was validated against the bug's _current_ delta_ts, which will be wrong because the token was created using an older delta_ts value.  we now validate against the delta_ts passed into us by our bug form.


it seems reasonable to fall back to the bug's current delta_ts if one isn't provided in the post data.  i'll file an upstream bugzilla bug and block this one.

Comment 8

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

This is also happening when I try to update a bug.  My code that does this has literally not changed in months.  It's worked flawlessly until I tried yesterday.

An example of what's happening:

1) I fetch bug 916231
2) Create a dictionary of the flags I want to set, and array of comments to add
3) copy the update token from 1) into the dictionary created in 2)
4) PUT the new object to the /bug/916231 endpoint.
5) Response from API is a 400 saying that I didn't supply a token, when I've verified 100% that I have.

My code lives here: https://github.com/jhford/uplift/blob/master/gaia_uplift/bzapi.py#L135



RAW LOGS:
=====================================================
This is what the program displays (dict is a local debug print)

Commenting on good bug 916231
Fetched bug 916231 in 0.48 seconds
{'token': u'1382550415-fa3bc13912c0c5adac508e70574987b6'}

This is in the api log (the log format is pretty horrid)

Status: 200 URL: get https://api-dev.bugzilla.mozilla.org/1.3/bug/916231?username=&password=&include_fields=_default%2Cassigned_to%2Ccomments%2Cflags
Status: 400 URL: put https://api-dev.bugzilla.mozilla.org/1.3/bug/916231?username=&password=
DATA
"{\"cf_status_b2g_1_2\": \"fixed\", \"token\": \"1382550415-fa3bc13912c0c5adac508e70574987b6\", \"comments\": [{\"text\": \"Uplifted c7803c6a23057cd3b3613f315d2fe5a5d4c83a51 to:\\nv1.2: 85adf28ddaac0985108b482f2babc71d83508718\\n\"}]}"
ERROR: {"bugzilla_url":"https://bugzilla.mozilla.org/process_bug.cgi?Bugzilla_login=&Bugzilla_password=","error":1,"code":32000,"message":"No token supplied for modification","http_code":"200"}

Comment 9

[Gervase Markham [:gerv]]

With the checkin of bug 930013, this should now be fixed. My test bug filing certainly works now. Let us know if it's not working for you.

Gerv

Comment 10

[David Lawrence [:dkl]]

Steve can you verify this is fixed now and close the bug?

Thanks
dkl

Comment 11

[Mozilla Shepherd (This account is used for automation and doesn't receive bugmail)]

The issues that I was having with this has been fixed now and I am back to a working state.  I wasn't filing bugs, but I was hitting the same issue when updating bugs.

Thanks everyone!

Comment 12

[Steve Fink [:sfink] [:s:]]

(In reply to David Lawrence [:dkl] from comment #10)
> Steve can you verify this is fixed now and close the bug?

Successfully created bug 930802. Thank you!! I couldn't believe how painful it was to not have this.