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)
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 | ||
Updated•7 years ago
|
Assignee: nobody → rjohnson
Comment 1•7 years ago
|
||
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.
Comment 3•7 years ago
|
||
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.
Comment 5•7 years ago
|
||
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
Comment 6•7 years ago
|
||
Change pushed to stage and production, edits in multiple tabs works.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Updated•5 years ago
|
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•