This security upgrade has caused issue with my application:
The Bugzilla page indicates that the cookie is returned with the first login request. I never used/stored this HTTP cookie, but instead built the cookie using the "enwiki_session=","enwikiUserID=", and other response fields.
These fields are no longer present in the first HTTP response (or the second -- which fails due to lack of cookie). Is this functionality we should expect to return?
Thanks, -AW
2010/4/7 Andrew G. West westand@cis.upenn.edu:
This security upgrade has caused issue with my application:
The Bugzilla page indicates that the cookie is returned with the first login request. I never used/stored this HTTP cookie, but instead built the cookie using the "enwiki_session=","enwikiUserID=", and other response fields.
These fields are no longer present in the first HTTP response (or the second -- which fails due to lack of cookie). Is this functionality we should expect to return?
Ouch. That's not intended, as you absolutely do need these fields to build your cookies when you're using the DIY method. I'll fix this ASAP.
Roan Kattouw (Catrope)
2010/4/7 Roan Kattouw roan.kattouw@gmail.com:
Ouch. That's not intended, as you absolutely do need these fields to build your cookies when you're using the DIY method. I'll fix this ASAP.
Since you only need the wikiname_session cookie in this scenario, I've added the sessionid and cookieprefix fields to the NeedToken response on both trunk and the live site, will backport to the 1.16 branch.
Roan Kattouw (Catrope)
mediawiki-api@lists.wikimedia.org