Now, there's just one spot at the beginning of the function where we
inspect the string key the user gave us; and after that point, we not
only have validated that string but in fact are working from our own
record that it pointed to, not the string itself.
This simplifies the code a bit, e.g. by not repeatedly searching the
database for the key (and hoping everything agrees so that we keep
getting the same row), and it will simplify adding logic to inspect
row attributes like `presume_email_valid`.
The previous code gave the user an extra day past
REALM_CREATION_LINK_VALIDITY_DAYS. Also rewrote it to match the parallel
logic in get_object_from_key.
This change:
* Prevents weird potential attacks like taking a valid confirmation link
(say an unsubscribe link), and putting it into the URL of a multiuse
invite link. I don't know of any such attacks one could do right now, but
reasoning about it is complicated.
* Makes the code easier to read, and in the case of confirmation/views.py,
exposes something that needed refactoring anyway (USER_REGISTRATION and
INVITATION should have different endpoints, and both of those endpoints
should be in zerver/views/registration, not this file).
Except in:
- docs/writing-bots-guide.md, because bots are supposed to be Python 2
compatible
- puppet/zulip_ops/files/zulip-ec2-configure-interfaces, because this
script is still on python2.7
- tools/lint
- tools/linter_lib
- tools/lister.py
For the latter two, because they might be yanked away to a separate repo
for general use with other FLOSS projects.
Also adds Confirmation.type, and cleans up the rest of Confirmation to look
more like the model definitions in zerver.
In the migration, all existing confirmations adopt the type
USER_REGISTRATION, to be conservative. In a few commits, different
confirmation types will have different validity periods, and
USER_REGISTRATION will have the shortest default.
This commit removes the ability to configure different validity durations
for different types of confirmation links. I don't think the extra
configurability was worth the extra complexity, either for the user trying
to understand the settings, or for the developer trying to understand the
code.
The commit replaces all confirmation validity duration settings with a
single setting, settings.EMAIL_CONFIRMATION_DAYS.
The only setting it removes is settings.EMAIL_CHANGE_CONFIRMATION_DAYS,
which was introduced in 5bf83f9 and never advertised in prod_settings.py.
Wasn't being used outside the file, the URL is specific to
ConfirmationManager, and it makes
EmailChangeConfirmationManager.get_activation_url more obviously parallel
to ConfirmationManager.get_activation_url.
I think it makes sense to wrest the email sending from confirmation, now
that we have a clean email-sending interface in send_email. A few other
reasons:
* send_confirmation is get_link_for_object followed by send_email, but those
two functions have no arguments in common.
* Sending email through confirmation obfuscates the context dict, and is a
relatively complicated piece of the codebase anyone trying to deal with
the email system has to understand.
* The three emails previously being sent through confirmation don't have
that much in common, other than that they happen to have a confirmation
link in them.
The .split('/')[-1] in registration.py is a hack, but a hack used several
places in the codebase, so maybe one day get_link_for_object will also
return the confirmation_key.
This commit replaces all uses of django.core.mail.send_mail with send_email,
other than in the password reset flow, since that code looks like it is just
a patch to Django's password reset code.
The send_email function is in a new file, since putting it in
zerver.lib.notifications would create an import loop with confirmation.models.
send_future_email will soon be moved into email.py as well.
No change in behavior; render_to_string(template, context) is a shortcut for
get_template(template).render(context). render_to_string is the function we
use to render email templates in the rest of the codebase.
I think it's fine to trust that we won't mess this up. I assume this is here
because it was copied from similar code in Django (e.g. see our code from
the password_reset flow), rather than because it was a problem in our
subject templates.
Relies on the fact that all the email template names now follow the same
pattern.
Note that there was some template_prefix-like computation being done in
send_confirmation (conditioned on obj.realm.is_zephyr_mirror_realm); that
computation is now being done in the callers.
Greg Price
rht
Rishi Gupta
sandeepsajan0
Vishnu Ks
Tim Abbott