Skip to content

Conversation

@imposeren
Copy link
Contributor

this is an alternative to #15 without changes to database. To start email change process:

  1. set settings.SIGNUP_EMAIL_CHANGE_PROCESSING = True
  2. initiate email change somewhere in views or forms:
EmailConfirmation.start_email_change(user_instance, new_email=new_email, send_email=True, request=request)

if settings.SIGNUP_EMAIL_CHANGE_TWO_STEPS == True then this will:

  1. send message to current (old) email address of user with special link.
  2. Visiting link from message will show notice that additional confirmation is needed and will send another message to new email address.
  3. Visiting link from second message will change email of a user.

if settings.SIGNUP_EMAIL_CHANGE_TWO_STEPS == False then this will:

  1. send message to new email address.
  2. visiting link from this message will change email of user

Custom confirmations are easy to implement:

  1. generate urls using `email_confirmation_instance.confirmation_url_for_data('some-confirmation-domain', some_data_dict)
  2. connect some receiver to`sig_generic_confirmation_received`` signal:
@receiver(sig_generic_confirmation_received)
def some_receiver(sender, confirmation_domain, code, decrypted_data, request, *args, **kwargs):
            if confirmation_domain == 'some-confirmation-domain' and isinstance(decrypted_data, dict):
                # process ``decrypted_data`` which is the same as some_data_dict used to generate url
                # ``code`` is the same instance of EmailConfirmation that was used to generate url
                pass

@idlesign
Copy link
Owner

Overall impression of the approach is fine, yet we need to polish some rough edges.

@imposeren imposeren closed this by deleting the head repository Sep 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants