crowdfavorite/wp-social — pull request #187 by tarodenberg (2014-03-24 17:56:13+00:00)
Title: Add nocache_headers() to action_authorize() to prevent servers from caching 301 redirect

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:
1) Most users are likely not opening the link in a new tab/window and are simply clicking the link to open the authentication dialog.
2) Most web hosts and web servers by default (if set to cache 301 redirect response headers at all) will only cache responses for a short duration (ie. 15 minutes) and sites with lower traffic will have significantly less occurrences of the situation in attribute #1 occurring within the cached duration.