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 <[email protected]> wrote: > > > > On Fri, Mar 21, 2014 at 2:40 PM, Chris McMahon <[email protected]> > wrote: >> >> >> >> >> On Fri, Mar 21, 2014 at 2:27 PM, Arthur Richards <[email protected]> >> 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 _______________________________________________ QA mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/qa
