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


(Firefox Affiliates Graveyard ::, defect)

Not set


(Not tracked)



(Reporter: stephend, Unassigned)




(Whiteboard: [fromAutomation][prod][blocksAutomation])


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
3. Click on "SIGN IN"
4. Sign in via the Persona dialog (I used my LDAP:

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:

Whiteboard: [fromAutomation][prod]
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 (jcrawford@m.c.). 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]
Depends on: 1014338
No longer depends on: 1014338
Commit pushed to master at
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
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.
Depends on: 1014747
The fixes above plus seem to have done the trick, I can't replicate anymore on prod and automation seems happy. :D
Closed: 9 years ago
Resolution: --- → FIXED
Thx, Mike - this WFM now in production.  Verified FIXED.
Product: Firefox Affiliates → Firefox Affiliates Graveyard
You need to log in before you can comment on or make changes to this bug.