Merge lp:~lukasz-czyzykowski/rnr-server/fix-duplicate-consumer into lp:rnr-server
Status: | Merged |
---|---|
Approved by: | Michael Nelson |
Approved revision: | 154 |
Merged at revision: | 156 |
Proposed branch: | lp:~lukasz-czyzykowski/rnr-server/fix-duplicate-consumer |
Merge into: | lp:rnr-server |
Diff against target: |
122 lines (+55/-6) 3 files modified
Makefile (+1/-1) src/reviewsapp/models/oauthtoken.py (+29/-5) src/reviewsapp/tests/test_auth.py (+25/-0) |
To merge this branch: | bzr merge lp:~lukasz-czyzykowski/rnr-server/fix-duplicate-consumer |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Michael Nelson (community) | Approve | ||
Review via email: mp+53750@code.launchpad.net |
Commit message
[r=noodels][bug=706035] Workaround for Bug:706035 to enable access to api when there is more than one oauth consumer with the same consumer_key.
Description of the change
Overview
========
This branch works around the problem of having duplicate oauth consumers in the database with the same consumer_key.
Details
=======
In principle the situation when there is more than one oauth consumer with the same consumer_key should never happen. But because it had happened on our servers the workaround proposed here is to:
- not fail miserably, when trying to use api using oauth consumer key when such bad situation had happened,
- clear the situation, so future access will be quicker and saner.
Testing
=======
Follow `README` instructions to setup environment and then issue `make test`.
09:36 <@noodles> lukasz: with your branch, the code change looks fine, but I think there should be a comment in the code along the lines of "There should not be more than one, but so that we don't error..."...
09:36 < lukasz> k
09:36 <@noodles> and, I wonder if it would be worth logging the deletion when it occurs?
09:36 <@noodles> (so that we can eventually track it down?)
09:37 < lukasz> I wondered about that
09:37 < lukasz> or just leave alone
09:37 < lukasz> the code can cope with that
09:38 < lukasz> noodles: the deletion was achuni's idea
09:38 <@noodles> Hrm... are we certain that the duplicates are always for the same user? (based on the consumer_key, they have to be?)
09:38 < lukasz> noodles: no, they can't be fore the same user (that's a unique thing for Consumers)
09:39 * noodles tries to re-read that statement
09:39 < lukasz> but, same person can have two django users
09:39 < lukasz> in my opinion this can only happen if you switch open_id providers
09:40 <@noodles> Ah - between staging/production?
09:40 < lukasz> but I'm not sure
09:40 < lukasz> yes
09:40 <@noodles> Which would fit, time-wise too.
09:41 <@noodles> OK, lets put that knowledge in the comment with the code, so that if we come back to it in 6months, we can understand why we did it?
09:41 < lukasz> maybe just switch that to log such situation and leave it alone
09:41 <@noodles> (although, you've linked to the bug too)
09:41 < lukasz> ok
09:41 <@noodles> +1 for logging and leaving (so we can always investigate)
09:42 <@noodles> if our assumptions turn out to be false...
09:43 < lukasz> ok