Presumably you mean PasswordResetTokenGenerator when you write PasswordResetToken.
Seems like a fairly small feature, but my security sense is tingling when you say you're putting the secret key of one application in a variable for another. Normally in a situation where multiple applications need to share login data, I would consider having a centralized application for identity management. Also in your current structure, you don't necessarily need to replace _make_token_with_timestamp (which is prone to break if Django changes that code) - you could (somewhat hackily) wrap with override_settings(SECRET_KEY=other_key) around your call to PasswordResetTokenGenerator.make_token. On 17 March 2017 at 20:54, jann.haber via Django developers (Contributions to Django itself) <django-developers@googlegroups.com> wrote: > Hi everybody, > > I have two sites in my project. One is for internal use to add members of > our club to our database, one is a self-service page for our members. > On registration of a member using our internal site, I want to send a > password reset link to the member for easy registration to our self-service > page. > Since the two sites run on different servers and different SECRET_KEYs, I > need to specify a different secret for the token generated with our > internal site to work on the self-service page. > I managed to do so by overwriting the method _make_token_with_timestamp > of PasswordResetToken, however, I think this is quite an ugly solution. > > How would you think about the secret being an attribute of the > PasswordResetToken class, which is then passed to salted_hmac? The default > could be settings.SECRET_KEY for backwards compatibility. > > I have so far not contributed to django, but I would like to start and I > believe, this small change might be a good start. If you agree, I could > open a ticket in trac. > > Best Regards, > Jann > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-developers/ca9e1cde-002d-491b-899a- > 02bfd50fbed6%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/ca9e1cde-002d-491b-899a-02bfd50fbed6%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Adam -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM1HSZhwVzU9pNuUHv28cWeRqc6n22PzsPk9Zgo_wtedQw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
