Add nocache_headers() to action_authorize() to prevent servers from caching 301 redirect #187
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
An issue where authenticated users were posting as another random user was identified on a high traffic site where 301 redirects were being cached by the web server. After applying this fix, the issue appears to be resolved.
When using "open in a new window" (using right click or similar action) to display the authentication dialog from a comment reply form, the plugin makes a GET request to the server instead of a POST request. By default, POST requests are usually not cached by most web hosts and HTTP servers. However, the GET request is often cached including the 301 redirect in the response headers. The GET request creates a nonce to act as the user ID / OAuth token within the MailChimp proxy service. The OAuth token gets cached within the HTTP headers of the response from the Social plugin. Having multiple identical OAuth tokens being sent to MailChimp and then being associated to different Facebook / Twitter accounts may cause unexpected behavior and could possibly produce issues where previously authenticated users will post as someone they did not intend to post as. Posts may instead be authored as a user who signed up immediately after them.
This situation may be difficult to reproduce in production environments due to the following attributes of this bug: