Page MenuHomePhabricator

wgSecureLogin redirect to https drops campaign and other URL parameters
Closed, ResolvedPublic


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

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.

Version: 1.22.0
Severity: normal



Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 2:37 AM
bzimport set Reference to bz55761.
bzimport added a subscriber: Unknown Object (MLST).

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 It's meant to be a parameter on the create page itself, since it's checked in the UserCreateForm hook. I.E.

(In reply to comment #1)

But is there any reason not to preserve the entire query string (then add

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.

swalling wrote:

Setting to high priority since this means ongoing data collection is being interrupted. Visible at:

Change 90125 had a related patch set uploaded by Anomie:
Include miscellaneous query parameters in $wgSecureLogin redirect

Change 90125 merged by jenkins-bot:
Include miscellaneous query parameters in $wgSecureLogin redirect