Last modified: 2013-10-16 21:44:05 UTC
Now that $wgSecureLogin defaults to true for most WMF wikis, Special:UserLogin/signup redirects account creation to https. When it does so it drops all URL parameters to signup apart from returnto and returntoquery. As a result, we're losing campaign information, and other control over login such as &showGettingStarted=false. To reproduce: Browse enwiki over http, visit a random page, click Edit, if the yellowish "You are not logged in...." anoneditwarning bar appears, then note the http: link for " or create an account" contains &campaign=anoneditwarning" But when you click it, you are redirected to https://en.wikipedia.org/w/index.php?title=Special:UserLogin/signup&returnto=Ectoedemia_sabina&returntoquery=&fromhttp=1 with no campaign parameter. One fix is to test for campaign and add it back to the $query, in the execute() function in includes/specials/SpecialUserlogin.php. Or, include all query string parameters in the redirect URL.
campaign is not part of core, so if you need to add it here, it should be through a hook. But is there any reason not to preserve the entire query string (then add fromhttp=1)?
spage, whatever is inserting that link isn't accounting for the campaign parameter correctly. The signup form is correct redirecting back to the passed in returnto and returntoquery, which that link is incorrectly generating. For example, if you manually add "&campaign=asdf" to your url, and then click the normal nav bar's "Create account", the returntoquery is correctly set.
Chris, it's not meant to be a parameter on the page they come back to (e.g. we don't want to send them to https://en.wikipedia.org/wiki/Ectoedemia_sabina?campaign=foo. It's meant to be a parameter on the create page itself, since it's checked in the UserCreateForm hook. I.E. https://en.wikipedia.org/w/index.php?title=Special:UserLogin/signup&returnto=Ectoedemia_sabina&returntoquery=&campaign=foo&fromhttp=1
(In reply to comment #1) > But is there any reason not to preserve the entire query string (then add > fromhttp=1)? Not that I can see for the purposes of the redirect. In load(), SpecialUserlogin.php adjusts mReturnTo and mReturnToQuery and on $wgSecureLogin redirect builds a new query string out of them; but my hunch is there's no harm redirecting to https with the entire original query string, and doing all query param processing in https processing.
Setting to high priority since this means ongoing data collection is being interrupted. Visible at: http://ee-dashboard.wmflabs.org/graphs/enwiki_campaigns
Change 90125 had a related patch set uploaded by Anomie: Include miscellaneous query parameters in $wgSecureLogin redirect https://gerrit.wikimedia.org/r/90125
Change 90125 merged by jenkins-bot: Include miscellaneous query parameters in $wgSecureLogin redirect https://gerrit.wikimedia.org/r/90125
https://gerrit.wikimedia.org/r/#/c/90125/ reviewed and merged
