As mentioned in bug 4134, we need a mechanism that can let a user log in
and then track who is logged in (via a session cookie) and other bits of
information (in a database, probably).
For the database, we could either ask the fdo people to hook us up with
one in whatever RDBMS they use, or we could go with DBD::Trini or SQLite
or something along those lines, or, in a pinch, flat files. Then we can
wrap a couple of easy Class::DBI classes around it and use it site-wide.
Basically, what goes on, conceptually, is this:
1. Upon visiting the site initially, the user will be anonymous,
2. If the user logs in (by entering a username and password into
a form that goes to a login cgi, which checks against the db),
then two things happen:
2A: A record is created in the DB in a sessions table, that
holds the user id, possibly some other info (such as an
IP address and expiration datetime), and a pseudorandom
unique session ID string.
3A: The session ID string is sent to the user in a cookie.
3. Any page that wants to know if the user is logged in can check
the cookie, look up the session ID string in the database, and
get the user id from the record. The user id is then also a key
into the users table and possibly some other tables.
4. A cron job can periodically delete expired sessions from the
sessions table; also, when the user logs in, the login script
could clear out any old sessions from that user before
adding the new one.
5. When a new user wants to create an account, we ask them for
(among other things) an email address, and the account is
created with an inactive status and a datestamp, and an email
is sent to the provided address containing a magic token,
which is also stored in the newly created user record.
The user retrieves the email and feeds the magic token from
it into the account-activation form, proving the address is
valid, and the account is then activated so that the user
can log in. A captcha could also be employed if we have
problems with bogus accounts, but I suspect that will not
be necessary, at least for now.
The advantage of getting an RDBMS account is that PHP portions of the site
could also access it; whereas, with something like Trini that would be
rather harder to do directly.
Ways this would be used on the site are many and varied, but some examples:
* The upload clipart form could auto-prefill the author portions
(both author name and URI); the user would still be able to edit
the values before submitting.
* If we offer a choice of stylesheets, we can store the user's preference
and always use it when the user logs in. We could also store preferences
for other things, such as which sidebar sections to show, and stuff.
* When the DMS is in place, we can make it so that logged-in users
can update their own clipart and/or its metadata.
* Also with the DMS in place, we can make it so that users can leave
feedback about specific items of clipart; anyone would be able to
view this feedback, and the author can be notified next time he logs
in. Private feedback for just the author is also a possibility,
if that is a desired feature.
* With the DMS in place, we can add an interface whereby users can
help with categorization, and a given user's contributions in this
regard can be tracked, so that if a vandalism problem develops they
can be reverted.
this is all done by cchost now... yay!
on Mar 30, 2017 at 08:47:17.
(provided by the Example extension).