| 2009-01-21 19:04:30 |
Brad Crittenden |
bug |
|
|
added bug |
| 2009-01-21 19:04:45 |
Brad Crittenden |
who_made_private |
|
bac |
|
| 2009-01-21 19:21:17 |
Brad Crittenden |
description |
Using lplib in a long-running script that made tens of thousands of request I was occasionally seeing "Invalid nonce/timestamp" errors as shown below[1].
Reviewing the code in db/oath.py for ensureNonce vs the OAuth spec[2] it seems our implementation is exactly backwards. Rather than require nonce uniqueness only for the period of a given timestamp (1 second), our implementation allows nonce reuse for a period of [t-60, t+60] seconds for any timestamp t and then raises an error if the nonce is used again outside of this window. As described in the spec, re-using a nonce with different timestamps should be allowed, not an error condition.
At the top of db/oath.py there is a rationale given for the use of this expanded window but the justification is not strong. It would be better to follow the spec strictly until the need to deviate is demonstrated and well understood.
[1] https://pastebin.canonical.com/12941/
[2] http://oauth.net/core/1.0/#nonce |
Using lplib in a long-running script that made tens of thousands of request I was occasionally seeing 401-Unauthorized errors that are actually shown to be "Invalid nonce/timestamp" errors as shown below[1].
Reviewing the code in db/oath.py for ensureNonce vs the OAuth spec[2] it seems our implementation is exactly backwards. Rather than require nonce uniqueness only for the period of a given timestamp (1 second), our implementation allows nonce reuse for a period of [t-60, t+60] seconds for any timestamp t and then raises an error if the nonce is used again outside of this window. As described in the spec, re-using a nonce with different timestamps should be allowed, not an error condition.
At the top of db/oath.py there is a rationale given for the use of this expanded window but the justification is not strong. It would be better to follow the spec strictly until the need to deviate is demonstrated and well understood.
[1] https://pastebin.canonical.com/12941/
[2] http://oauth.net/core/1.0/#nonce |
|
| 2009-01-21 19:22:55 |
Brad Crittenden |
bug |
|
|
added subscriber Brian Murray |
| 2009-01-21 20:42:04 |
Brian Murray |
launchpad: status |
New |
Confirmed |
|
| 2009-01-21 20:42:04 |
Brian Murray |
launchpad: statusexplanation |
|
I have seen these errors too when trying to find information about all the bug tasks assigned to particular people. |
|
| 2009-01-23 22:05:47 |
Brad Crittenden |
bug |
|
|
added subscriber Francis J. Lacoste |
| 2009-01-23 22:20:48 |
Francis J. Lacoste |
launchpad: status |
Confirmed |
Triaged |
|
| 2009-01-23 22:20:48 |
Francis J. Lacoste |
launchpad: title |
Bug #319710 in Launchpad itself: "Incorrect nonce processing in API" |
Bug #319710 in Launchpad Foundations: "Incorrect nonce processing in API" |
|
| 2009-01-23 22:20:48 |
Francis J. Lacoste |
launchpad: importance |
Undecided |
High |
|
| 2009-01-23 22:20:48 |
Francis J. Lacoste |
launchpad: bugtargetname |
launchpad |
launchpad-foundations |
|
| 2009-01-23 22:20:48 |
Francis J. Lacoste |
launchpad: statusexplanation |
I have seen these errors too when trying to find information about all the bug tasks assigned to particular people. |
|
|
| 2009-01-23 22:20:48 |
Francis J. Lacoste |
launchpad: bugtargetdisplayname |
Launchpad itself |
Launchpad Foundations |
|
| 2009-01-23 22:21:54 |
Francis J. Lacoste |
who_made_private |
bac |
|
|
| 2009-01-23 22:31:09 |
Francis J. Lacoste |
launchpad-foundations: milestone |
|
2.2.2 |
|
| 2009-01-31 12:41:15 |
Brad Crittenden |
description |
Using lplib in a long-running script that made tens of thousands of request I was occasionally seeing 401-Unauthorized errors that are actually shown to be "Invalid nonce/timestamp" errors as shown below[1].
Reviewing the code in db/oath.py for ensureNonce vs the OAuth spec[2] it seems our implementation is exactly backwards. Rather than require nonce uniqueness only for the period of a given timestamp (1 second), our implementation allows nonce reuse for a period of [t-60, t+60] seconds for any timestamp t and then raises an error if the nonce is used again outside of this window. As described in the spec, re-using a nonce with different timestamps should be allowed, not an error condition.
At the top of db/oath.py there is a rationale given for the use of this expanded window but the justification is not strong. It would be better to follow the spec strictly until the need to deviate is demonstrated and well understood.
[1] https://pastebin.canonical.com/12941/
[2] http://oauth.net/core/1.0/#nonce |
Using lplib in a long-running script that made tens of thousands of requests I was occasionally seeing 401-Unauthorized errors that are actually shown to be "Invalid nonce/timestamp" errors as shown below[1].
Reviewing the code in db/oath.py for ensureNonce vs the OAuth spec[2] it seems our implementation is exactly backwards. Rather than require nonce uniqueness only for the period of a given timestamp (1 second), our implementation allows nonce reuse for a period of [t-60, t+60] seconds for any timestamp t and then raises an error if the nonce is used again outside of this window. As described in the spec, re-using a nonce with different timestamps should be allowed, not an error condition.
At the top of db/oath.py there is a rationale given for the use of this expanded window but the justification is not strong. It would be better to follow the spec strictly until the need to deviate is demonstrated and well understood.
[1] https://pastebin.canonical.com/12941/
[2] http://oauth.net/core/1.0/#nonce |
|
| 2009-02-02 22:06:25 |
Francis J. Lacoste |
launchpad-foundations: status |
Triaged |
In Progress |
|
| 2009-02-02 22:06:25 |
Francis J. Lacoste |
launchpad-foundations: assignee |
|
flacoste |
|
| 2009-02-18 13:12:40 |
Francis J. Lacoste |
launchpad-foundations: status |
In Progress |
Triaged |
|
| 2009-02-18 13:12:40 |
Francis J. Lacoste |
launchpad-foundations: assignee |
flacoste |
garyposter |
|
| 2009-02-18 13:12:40 |
Francis J. Lacoste |
launchpad-foundations: statusexplanation |
|
I haven't basically been able to start concretely on it. Gary will take care of it once he finishes the librarian bug. |
|
| 2009-02-24 13:57:33 |
Gary Poster |
launchpad-foundations: status |
Triaged |
In Progress |
|
| 2009-02-24 13:57:33 |
Gary Poster |
launchpad-foundations: statusexplanation |
I haven't basically been able to start concretely on it. Gary will take care of it once he finishes the librarian bug. |
|
|
| 2009-02-28 21:29:12 |
Gary Poster |
launchpad-foundations: status |
In Progress |
Fix Released |
|
| 2009-02-28 21:29:12 |
Gary Poster |
launchpad-foundations: statusexplanation |
|
The necessary database changes were rolled out as a part of 2.2.2. The code changes were committed to trunk after the deployment, but they are only pertinent to edge, and so they will be available very soon (the next time edge is updated from stable). |
|
| 2011-05-30 07:50:41 |
Robert Collins |
removed subscriber Launchpad Security |
|
|
|
