So.. what can we do about this? This has now been a problem for some time. We should at least find a short term fix - maybe introducing delays might work here?
Sadly I cannot replicate this so I feel pretty useless and frustrated that I am unable to fix this myself..
On Fri, Mar 21, 2014 at 2:49 PM, Arthur Richards arichards@wikimedia.org wrote:
On Fri, Mar 21, 2014 at 2:40 PM, Chris McMahon cmcmahon@wikimedia.org wrote:
On Fri, Mar 21, 2014 at 2:27 PM, Arthur Richards arichards@wikimedia.org wrote:
(in prod, we at least used to use memcached to store session data, but dunno if this is still the case or if this is the case for betalabs). Anyways, there could be something wonky there causing token mismatch problems. This seems somewhat unlikely to me because if this were a problem, we would probably experience more issues on betalabs than we have been - but it certainly still seems possible.
Chris mentioned to me earlier that he pinged Coren about this on IRC - any followup yet, Chris?
Yes, I talked with Coren and hashar both briefly. We're using memcache in beta labs for session storage also. Neither Coren nor hashar had any further illumination.
:-/ I dont know much about the under-the-hood aspect of this but is there some way we can see what's going into and coming out of memcached while replicating the problem? It would be nice to rule this out.
So here's another question:
This code is in MF:
private function submitSettingsForm() { $context = MobileContext::singleton(); $request = $this->getRequest(); if ( $request->getVal( 'token' ) !=$context->getMobileToken() )
if the token in $request is always expected to be equal to the token in $context, then why does this if() statement even exist? Why do this check in the first place? Whatever this is guarding against seems to be actually happening.
While the tokens are expected to be equal, they aren't always. Usually when they aren't equal, it is for some benign reason, but it can be the result of someone attempting to use the form as a cross site request forgery vector (https://www.mediawiki.org/wiki/Cross-site_request_forgery). Long story short, we do this for security reasons - the approach here is very common throughout mediawiki and a standard way to prevent CSRF attacks.
-- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687