Menu
▾
▴
#3053 Skin login needs documentation
OK, I just tested. Logging in to Slashdot or any other
Slash site that uses plugins/Login and multiple skins
is broken. There is a fix, not an easy fix, but a fix,
that we must do.
As far as I can tell, this basically means that nobody
has been able to log in to the Games section, or any
other section, since the section-topics went live or
maybe since plugins/Login went live, unless (1) they
were logged in to Games before or (2) they know the trick.
(The trick is to go to games.slashdot.org/users.pl
instead of any of the existing methods that all point
you to login.pl.)
The reason the trick works is that all the login.pl
methods have a form that submits your username/password
data to //slashdot.org/login.pl, whereas the old
users.pl method just submits to /users.pl. So basically
login.pl is keyed to not ALLOW you to log in to
anything but the main skin.
So this is definitely a bug, not a feature request.
The fix is that we need to, yes, submit a login to
//real_rootdir/login.pl, but with a special op that
means "bounce me through a sectional rootdir too."
Let's say that op gets called "bounce1". That op needs to:
1. log the user in (create the logtoken in the DB and
emit it in a Set-Cookie in the HTTP headers as normal)
2. redirect the user automatically to any skin domain
(pick the first one alphabetically), hitting its
//foo.example.com/login.pl with an op of "bounce2",
passing it the logtoken that was just created in the
DB, and passing along the correct 'returnto' value
(default to the homepage).
The "bounce2" op needs to:
1. confirm the logtoken is correct (using the main DB
since this may happen a fraction of a second later and
the readers may not be caught up)
2. emit the logtoken in a Set-Cookie in the HTTP headers
3. at last, redirect the user to the correct 'returnto'
value.
Perhaps in later code we can update this to be even
cleverer, bouncing the user through a series of
redirects if there are multiple domains in the skins
table or under other circumstances (e.g. if we ever get
single signon between linux.com and newsforge.com). But
for now the criterion should just be whether there
exist any 'hostname' fields in the skins table that
match /\w\.$constants->{basedomain}$/.
One last thought -- ultimately we want to have the user
always send their password over https, and then if
appropriate bounce them back to http. So we should
always be sending that initial login.pl hit, the one
that actually contains the username and password, to
https://example.com/login.pl. And, assuming the
password is correct and the user needs to go to
non-https (i.e. on Slashdot, the user is not a
subscriber), there should be two bounces, one to
http://example.com/login.pl and a second from there to
//foo.example.com/login.pl (and then a bounce to the
returnto). But that gets rapidly complicated. For now,
we can ignore scheme and assume that the user is
submitting that initial form using the scheme they're
authorized for and let the chips fall where they may.
Logged In: YES
user_id=3889
OK, per our IRC discussion...
1. For now, I am just going to document the cookiedomain var
and skins.cookiedomain fields in docs/sectiontopics.pod.
For later (maybe in the next couple weeks...)
2. I still think the default should be to work with the
common case where the site is installed at example.com and
skins can be set up at example.com and foo.example.com and
it "just works". This would be done by MySQL.pm scanning the
skins table, seeing that all hostname fields match that
pattern, and setting the cookiedomain automatically to
".example.com".
3. In the unusual cases like use.perl.org and
foo.sourceforge.net, where a Slash site is installed on a
domain that its maintainer does not have full control over,
there should be only that one domain defined in skins, and
MySQL.pm could still scan the skins table and automatically
recognize that cookies should go directly to that domain.
4. In the really unusual cases when a site has one skin at
foo.com and another at bar.com, then yes, we will have to go
to the current system of those skins having their
cookiedomain fields defined manually. But that's a 1% case
and it shouldn't stop us from making the other 99% "just work."
How's that sound?