Closed Bug 1456165 Opened 7 years ago Closed 7 years ago

Permission-denied error when publishing an edit to a document

Categories

(developer.mozilla.org Graveyard :: Editing, enhancement, P1)

All
Other
enhancement

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: rjohnson, Assigned: rjohnson)

References

Details

(Keywords: in-triage, Whiteboard: [specification][type:bug])

What did you do? ================ 1. Using your browser, open a tab and go to https://developer.allizom.org/en-US/docs/user:escattone/test1$edit 2. Open another tab and go to https://developer.allizom.org/en-US/ 3. Return to your first tab, make a change, and hit the publish button What happened? ============== You will get a 403 (Permission Denied) error What should have happened? ========================== Your edit should have been successfully published. Is there anything else we should know? ====================================== This bug has been introduced by the new CDN, and it exists on both the stage and production instances.
Assignee: nobody → rjohnson
Keywords: in-triage
Priority: -- → P1
Is there a workaround or is it random? Because I saved some edits on a different topic earlier in the day.
Not official one, but I heard editing with a single MDN tab is better.
Often, refreshing the edit page and re-submitting will allow the request to complete successfully. The problem is much more likely to appear if you have MDN open in multiple tabs or windows. If you need to do a lot of cross-referencing to edit a page, you might want to edit in a single tab in one browser (such as Firefox), and do your research in a second browser (such as Chrome). The root cause is that our CDN is not passing a user's CSRF token cookie for some views. This makes it likely that a new cookie will be generated, and the server's idea of the CSRF token will be different from the user's browser. Navigating to a new page may generate yet another CSRF token, invalidating the one in the browser session. Sticking to a single-tab workflow will avoid these issues, but is overly restrictive for a long-term solution. We're investigating moving the CSRF token to the session, which is more reliably passed through the CDN.
Commits pushed to master at https://github.com/mozilla/kuma https://github.com/mozilla/kuma/commit/7cd152dd20b0c5e520b92b4eb2e7f66f8c5c9053 bug 1456165: remove csrfmiddlewaretoken from wiki.document view responses https://github.com/mozilla/kuma/commit/556041859e1b03d0f55fbc3d2a1f0fd60b77859a Merge pull request #4757 from escattone/csrf-exemptions-1456165 bug 1456165: remove csrfmiddlewaretoken from wiki.document view responses
Change pushed to stage and production, edits in multiple tabs works.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.