"the self-service site is basically a small subset of our internal site. So if somebody would gain access to our interal site, he/she would already have access to a superset of data of the other site. So there is really no point to also take over to the other site."
Just curious: why not just use the same SECRET_KEY for both sites? On Sat, Mar 18, 2017 at 6:11 AM, jann.haber via Django developers (Contributions to Django itself) <django-developers@googlegroups.com> wrote: > Thank you for your input. Yes I meant the PasswordResetTokenGenerator, > sorry for this. > > It agree, it would be a fairly small addition to Django, however there > doesn't seem to be an easy (non-hackish) way to get around. Since the > impact on Django would be very small, I wanted to share my thoughts here. > In our scenario, the self-service site is basically a small subset of our > internal site. So if somebody would gain access to our interal site, he/she > would already have access to a superset of data of the other site. So there > is really no point to also take over to the other site. > > I'll give the override_settings a closer look, but this seems like > something one wouldn't want in a production environment. > > Am Samstag, 18. März 2017 10:32:06 UTC+1 schrieb Adam Johnson: >> >> 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(SE >> CRET_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-d...@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-develop...@googlegroups.com. >>> To post to this group, send email to django-d...@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/ms >>> gid/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/4e1c275f-1ea5-482d-affa- > e70b95ffac24%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/4e1c275f-1ea5-482d-affa-e70b95ffac24%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAFO84S48FxQXoZt8H2_Uf7xR0%2BfGgOexGJijQNjwThx7zcHdQw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
