On Mon, Mar 30, 2015 at 10:20 AM, Ien C. <ien@alum.mit.edu> wrote:
Thanks Russ!
Good point about the validation logic. Will definitely keep that in mind. And yes, my basic approach here is the same code base working on different subsets of data by default, with the ability for data to be optionally "seen" by both sites as needed.One more question: there's no need to keep settings.SECRET_KEY the same across the sites, is there? In the context of this question, someone told me that SECRET_KEY is used for hashing db reads/writes, but that doesn't sound right to me and I don't see anything about that in the docs. The two sites can (and should) have different SECRET_KEY values, right?
Depends on what your "secret" sharing policy is between the two sites. If you want a truly shared login (as in - log into site A, login is recognised on size B), or shared session payloads, you would need to have a shared SECRET_KEY (along with some other cookie domain tweaks). However, if they're independent sites, and you explicitly *want* someone to log into site A and site B separately, then different SECRET_KEYs are advisable.
I don't know what your "someone" meant about hashing db read/writes - unless they were referring to the session table. It certainly isn't something that is applied to *all* DB read/writes, or would prevent data written with one site from being read by the second.
Yours,
Russ Magee %-)
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAJxq849buUK-ESY0PTaSNjTvOFjgRqN3mDg2R0OBM6Y%3DzET7sA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment