This updates various references to use NOTIFICATION_EMAIL, since that's
what we actually send the emails too.
Also change the moderators group to be 'pgweb moderators'.
render_to_response does not work on newer django, so it needs to be
replaced. And using a speicfic context actually overcomplicates things,
it's easier to just use a wrapper function. For those cases where we
don't need NavContext, just use render() (the new shortcut function from
django), which also removes the need to use RequestContext.
Community authentication 1.0 relied on PostgreSQL connections between
all servers, and hasn't been used for years.
This includes removing the code that migrates users from the old
community authentication system to the new one. This means that any user
who has not logged in since 2011 will no longer be able to user their
oan account, and have to create a new one.
We were already using signals for everything except delete, and even
in our old version of django the delete signal exists (it didn't exist
when this code was first written).
Django doesn't really like models to be OOP like this, so keeping PgModel
would cause issues with upcoming changes in django 1.8. Using simple functions
is easier, and the actual functionality is replicated straight off.
This lets downstream systems securely search for users that are in
the system, so they can populate their local database with users
before they have logged in if necessary. This can be used for example
for the commitfest management system to be able to flag users as
authors and reviewers even before they have logged in.
Import the code from the PostgreSQL Europe website to handle this, since it's
well proven by now.
Any points that send email now just write them to the database using the
functions in queuedmail.util. This means we can now submit notification
emails and such things within transactions and have them properly roll bcak
if something goes wrong (so no more incorrect notifications when there is
a database error).
These emails are picked up by a cronjob that runs frequently (typically
once per minute or once every 2 minutes) that submits them to the local
mailserver. By doing it out of line, this gives us a much better way of
dealing with cases where mail delivery is really slow.
The submission from the cronjob is now done with smtp to localhost instead
of opening a pipe to the sendmail command - though this should have no
major effects on anything.
This also removes the setting SUPPRESS_NOTIFICATIONS, as no notifications
are actually ever sent unless the cronjob is run. On development systems
they will just go into the queuedmail table, and can be deleted from there.
This makes it possible to pass URLs that will fail when they end up being double
escaped in some cases, since they contain non-url-safe characters. Instead, they'd
be base64-encoded, and thus safe.
Also update the django community auth provider to do just this, including encrypting
the data with the site secret key to make sure it can't be changed/injected by
tricking the user to go directly to the wrong URL.
In order to provide a consistent user experience, we must sign the
user out from the main website if the community site provides a logout
button - else that button will appear not to work...
This system relies on http redirects and signing in to the main website
instead of using cross-internet pgsql connections and signing in individually
to each website.
This increases session security, obviously... It will also break local development
installs, which will have to add the two rows that this patch adds to the
documentation.
