Use of threading.local() ... what is the risk?
I have read https://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser and numerous other discussions about the use of threading.local() yet I still see it being employed in various projects.
I have recently implemented a referral system in which the use of threading.local() makes the app very portable and very simple as I can simply use the post_save signal (which cannot access the session). What I'm doing...
1. When a user first gets to the site, middleware stores the referral ID found in the URL and puts it into a session variable.
2. The session variable is copied to a threading.local() variable on every request.
3. A handler for the post_save on the User model checks this threading.local() variable, finds the User the referral code belongs to, and associates the referral user with the referred user in referral model. This handler also creates the referral code for the new user.
I like this approach because there is no need to think about the referral system in the views, forms, or models of the auth system. I haven't deployed this because of the big threading.local() warnings.
So this referral code is the only thing vulnerable here. This code is a uniquely generated code which is associated with a User. What risks does this pose and why?
-- You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home