Closed Bug 1014273 Opened 9 years ago Closed 9 years ago
403 FORBIDDEN error trying to log in with a clean profile (using LDAP) to Affiliates on production
STR: 1. Clear all cookies/session data 2. Using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 on Windows 7, load https://affiliates.mozilla.org/en-US/ 3. Click on "SIGN IN" 4. Sign in via the Persona dialog (I used my LDAP: email@example.com) Expected Result: After logging in, you should get returned to the homepage, after a reload, and the SIGN IN should change to the AFFILIATE dropdown menu Actual Results: We get a 403 on the POST: https://affiliates.mozilla.org/browserid/login/ Screencast: http://screencast.com/t/26fqIUgMUVC
I can reproduce this. You'll see the 403 in the network pane of devtools. The behavior in browser is that the logged-out homepage never refreshes to the logged-in state. I have only reproduced this for NEW accounts. I have not reproduced it yet for an existing account.
I have reproduced this using a non-LDAP email.
I have reproduced this with an existing account (firstname.lastname@example.org.). However, it is sporadic. Most times I am able to login.
Reproducing this only requires that you clear cookies.
OS: Windows 7 → All
Hardware: x86_64 → All
Whiteboard: [fromAutomation][prod] → [fromAutomation][prod][blocksAutomation]
9 years ago
No longer depends on: 1014338
Commit pushed to master at https://github.com/mozilla/affiliates https://github.com/mozilla/affiliates/commit/4cc5bad66ed7ae438e550b69998de1f1fc920973 Bug 1014273: Do not cache CSRF token view. The production site seems to be caching the index page and CSRF token view used by django_browserid to fetch a token for POSTing the Persona assertion. This causes failures when logging in as you POST with a cached token. Trying to login again works, however, because the failed POST doesn’t get cached and you get assigned a proper token, which updates your CSRF cookie. Since you now have a different cookie and all requests vary by cookie while not logged in, the second time it will fetch the correct token and POST it properly. By marking the CSRF view as not cached, we force the request to set a CSRF cookie and to send the correct CSRF token, which means the POST that follows it will go through correctly.
Commit pushed to master at https://github.com/mozilla/affiliates https://github.com/mozilla/affiliates/commit/eb86e4aaf662a0b0d983eff827c2b795d597692d Bug 1014273: Do not cache for anonymous users getting cookies. Our load balancer is currently caching responses that send no cookies, which causes a problem when that response sends a CSRF cookie. Since it caches the response, all users get the same CSRF cookie, which causes 403 issues when the user attempts to POST during login. The solution is to not cache responses under the specific circumstance where a user is anonymous, sent no cookies, and received cookies. This way, if a user comes in with cookies already set, we can still benefit from caching for them without an issue since we vary on cookies. But users who need their cookies set with the CSRF token for the first time can get an un-cached response.
The fixes above plus https://github.com/mozilla/affiliates/commit/2a0246d3ef28e473e4920432621923a32d8dca94 seem to have done the trick, I can't replicate anymore on prod and automation seems happy. :D
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Thx, Mike - this WFM now in production. Verified FIXED.
Status: RESOLVED → VERIFIED
Product: Firefox Affiliates → Firefox Affiliates Graveyard
You need to log in before you can comment on or make changes to this bug.