Verify email does not seems to behave like expected about django-rest-registration HOT 8 CLOSED

Ok So I have read documentation and understand that url to activate email is not provided. So question I have now is how frontend should know about email address. Because the the link in email does not pass email address to the view that user should implement.

I don't understand why we can't have GET endpoint to do activation? I would prefer this think our of the box, without me going and implementing addition views.

from django-rest-registration.

So question I have now is how frontend should know about email address. Because the the link in email does not pass email address to the view that user should implement.

We don't need to pass the email in case of user verification, because the email is already saved in the user model. We only need the user verification to switch the "is_active" flag (see 'USER_VERIFICATION_FLAG_FIELD' key in REST_REGISTRATION setting).

But we need to pass the email in the params in case when we want to change the email (with the register-email view), because we want the email to be replaced in the user model only when the verification succeeds.

I don't understand why we can't have GET endpoint to do activation? I would prefer this think our of the box, without me going and implementing addition views.

This is because you usually implement single page app (SPA) in one technology (usually some JavaScript framework like React.js, Angular.js, Vue.js) so there is no sense for having frontend served by both your SPA and by Django views (you would need to share statics, template generation, etc). And implementing such logic is not so difficult (see example ). This argument does not apply so much in case of having only mobile app + backend setup, but I (and anyone else?) never used django-rest-registration in that manner.

What could be somewhat useful for people who don't want to implement the verification views in their webapp, could be to add optional Django verification views, which would redirect to "success" / "failure" static pages, which the user would have to implement - even if we provided such ones in 99% the user would need to provide their own to have consistent layout, branding, etc. What do you think about this idea?

from django-rest-registration.

I totally I agree. I think t's would be totally useful, if there would be a separate installable django app that would provide all ancillary endpoints.

from django-rest-registration.

Btw, what about the issue, have you been able to replicate the issue?

from django-rest-registration.

Unfortunately I can't reproduce the bug. There are unit tests covering this case. I even tested how it behaves with the example application but it seems to work. I need more info about the way how you pass the parameters to the REST API endpoint:

• Do you pass something else than user_id, timestamp, signature? You mentioned that you tried to pass the email address.
• Do you use some custom User model? I see that user_id is in UUID form, so my guess is yes. If yes, could you send some info how your User class looks like?
• How do you pass the data in the POST request to endpoint? Are you sending JSON payload with Content-Type: application/json or do you use some other method? How does the payload look like?

I may try to create test with custom User model where id will be UUID but I don't see how it would cause the problem, because all values are normalized to str before signing / veryfying anyway.

from django-rest-registration.

@polinom Hi, did you make any progress on this issue? You didn't answer my questions so I'm not sure what is the status of the problem you encountered.

from django-rest-registration.

Closing this issue due to lack of activity.

from django-rest-registration.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

from django-rest-registration.