6 digit verification for email address verification

[webpn]

feature-request

6 digit code verification has recently become a common practice: instead of having the user click on a verification link, you email him a 6 digits code that he has to write down in the final step of the sign-up form. This is quite useful when the user is using a computer where he cannot easily read his email (so he could read the 6 digits code on his phone), or vice versa.

Ideally, it would be great to enable both methods: in order to verify the user email address you send him the verification link and the 6 digits code, so that the user can choose which method is easier for him.

[hafizSiddiq7675]

Any workaround for this?

[ayushin]

anybody working on this?

[khylbom]

I'm also looking to try and do the same thing. If anyone comes up with a clean production-ready solution, please share!

[ebarojas]

I think this is critical to avoid users losing track of the confirmation email and if it's going to SPAM, catching it early on.

[9mido]

Linking the following issue since it relates:

https://github.com/pennersr/django-allauth/issues/2814

[bene25]

+1

[ayushin]

we use django-otp

[bene25]

django-otp

are you using it with rest?

[ayushin]

yes, but allauth + dj-rest-auth + otp requires a lot of tweaking as we use it together with drf-yasg

basically allauth is not really drf friendly and dj-rest-auth breaks all drf-yasg shemas

time for a big refactor?

[derek-adair]

This issue is a good feature request.

@pennersr how do you feel about moderating off topic comments? Pretty uncommon in your project but this issue is full of it.

[ayushin]

One should check django-otp and django-df-auth

[derek-adair]

If django-allauth integrates with that out of the box this can probably be closed and mentioned in the docs as the recommended solution for such a thing.

[olarcher]

@derek-adair I would argue that a lot more people use dj-rest-auth than django-df-auth, so it would be great to have a solution that works with dj-rest-auth as well.

[derek-adair]

Not sure what you are arguing. I'm dispassionate about which of these allauth would support. My comment was simply that we should look at what, if anything, can be done to make these projects play nice together. For example, if someone could post up an example / tutorial / whatever of what kind of problems people have working with these projects togther that would be a great start!

Also @ayushin how is it that django allauth does not play nice w/ DRF? I have active projects that use allauth and django together and have no issues.

[josylad]

Hello, Can anyone who has successfully integrated django OTP and allauth share some code samples? I want to send OTP on user login, redirect them to OTP confirmation page, verify the OTP and then send them to their dashboard.

This system works with allauth right now, except for the login OTP part. @ayushin @webpn @derek-adair

P.S. I am using Django template, not DRF.

[pennersr]

@josylad Just to be sure I fully understand, what you are referring to -- sending a OTP on login -- is something different from using a OTP for email verification, right? So, I think there are 2 distinct feature requests here:

• Being able to confirm email addresses with a simple code (instead of following a link as is now).
• Using your email as a 2nd factor, so that on each login you are sent a OTP that you will have to confirm.

[josylad]

@josylad Just to be sure I fully understand, what you are referring to -- sending a OTP on login -- is something different from using a OTP for email verification, right? So, I think there are 2 distinct feature requests here:

• Being able to confirm email addresses with a simple code (instead of following a link as is now).
• Using your email as a 2nd factor, so that on each login you are sent a OTP that you will have to confirm.

Yes, you are correct. @pennersr

[pennersr]

@josylad See #3550 -- feel free to provide your use case specifics there.

[josylad]

@josylad See #3550 -- feel free to provide your use case specifics there.

Done, thanks.

[francosbenitez]

This would be awesome.

[krystofbe]

I've been following the discussion on implementing a one-time code for email verification in django-allauth, and I'd like to offer a summary and some thoughts for further consideration.

In modern web applications, it's becoming increasingly common to verify a user's email address through a one-time code, as opposed to the traditional confirmation link. This approach ensures real-time verification of the email address before the completion of the registration process. It's particularly useful in scenarios where immediate verification is crucial and adds an additional layer of security.

A key point for discussion is whether entering this verification code should be mandatory or configurable via Django settings. This raises questions about how it would interact with the existing functionality of django-allauth.

[pennersr]

A key point for discussion is whether entering this verification code should be mandatory or configurable

Definitely configurable, as allauth is used in all sorts of context, and mandatory email verification by code is not applicable everywhere.

[pennersr]

I would like to see this implemented in allauth. For that to happen, we need to make a few decisions.

When email verification by code is enabled, do we still send the link as well? Or, do we need to support three options for verification: link only, link + code, code only.

You could argue that one reason for sending the code is that users are trained not to click on links in mails, so sending a link and code in one and the same email does not make sense. But, I would like to know what your thoughts are, and what is most commonly required.

Any input is welcome.

[PabloCastellano]

@pennersr My two cents:

I am eager to see this feature implemented in django-allauth. In my case, I would simply configure it to only send the code. Having the link sent along with the code seems unnecessary to me. The code-based solution is preferable because it allows me to easily switch between devices; I can open my email on my phone and enter the code on my laptop without losing focus on the signup process.

I find that when a user wants to make a purchase on my website, it's better to maintain their focus by sending them a code to enter rather than redirecting them to the "Confirm your email" page like now. With the code-based approach, they can simply enter the code and proceed with the purchase without the additional steps of closing the confirmation page, clicking on the email link, and navigating back to the cart page.

Thank you for your work! By the way, I've just become your 20th sponsor ❤️

[pennersr]

I would simply configure it to only send the code

I concur -- I envision a simple setting, something along the lines ACCOUNT_EMAIL_VERIFICATION_BY_CODE = True to flip the current behavior over from sending links to using codes.

I've just become your 20th sponsor

@PabloCastellano Much appreciated, that really helps -- in any case, this topic will get traction in the upcoming future. Thanks!

[PabloCastellano]

@pennersr Is there anything I can help you with to ship this feature faster?

[pennersr]

Work is currently ongoing to get webauthn support in, and I do expect to be able to look into this after that, but I cannot give any ETAs. Unless anybody is willing to contribute this feature, for me the only way to make it ship faster is more sponsors as that implies more time can be dedicated towards allauth development.