detecting stale session data

[testbackupacct]

Hi,

I'm pretty new to Django and am having a problem with a race conditions 
while modifying my session data. I'm using the standard session backend in 
Django 1.4.1,, backed by Mysql.

I have view A, which can take a long time to process, and view B, which is 
usually faster. I store multiple data fields, fieldA and fieldB, in the 
session dictionary. View A modifies fieldA, and view B modifies fieldB.

Sometimes, view A starts up with a copy of the session data as it exists at 
t1. Then, while it's processing, view B starts up. It completes quickly, 
modifying fieldB in the session data at time t2. Then view A finally 
completes, modifying its field in the session data at time t3. But what I 
wind up with is fieldA at time t3 and fieldB at time t1. In other words, 
when view A completes its write, it's storing the stale version of fieldB 
that it read when it started. What I want in that situation is t3's version 
of fieldA and t2's version of fieldB.

My questions: (1) is there a way to check if your copy of the session 
dictionary is stale? And if so, is there a way to do it atomically? (2) Is 
there a way to selectively write just part of the session data, instead of 
the whole thing? (3)  Or, is there a better solution besides either of 
these ideas?

The only thing I can think of using RAM memory to keep track of a 
last_write timestamp for each session -- but that's not a scalable 
solution. Is there a better way?

Thanks in advance,

Spork

-- 
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+unsubscr...@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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Right way to modify contrib auth package?

[testbackupacct]

I'm sure that this is all obvious to experienced Django developers, but I 
thought I'd document what I did for my fellow Django newbies. Again, thanks 
to Anton for his advice.

>  
In my application directory, I subclassed PasswordChangeForm and 
SetPasswordForm. Then I added my custom validation code, which is just 
making sure the password is at least eight characters long:

from django import forms
from django.contrib.auth.forms import PasswordChangeForm, SetPasswordForm
from django.utils.translation import ugettext_lazy as _

class MyPasswordChangeForm(PasswordChangeForm):

new_password1 = forms.CharField(label=_("New password"),
min_length=8,
widget=forms.PasswordInput)
new_password2 = forms.CharField(label=_("New password confirmation"),
min_length=8,
widget=forms.PasswordInput)

class MySetPasswordForm(SetPasswordForm):

new_password1 = forms.CharField(label=_("New password"),
min_length=8,
widget=forms.PasswordInput)
new_password2 = forms.CharField(label=_("New password confirmation"),
min_length=8,
widget=forms.PasswordInput)


Then I imported my new classes into registration\auth_urls.py and added my 
new classes as parameters to password/change and 
password/reset/confirm/(?P[0-9A-Za-z]+)-(?P.+)/:

 url(r'^password/change/$',

  auth_views.password_change,

  {'password_change_form': MyPasswordChangeForm},

  'auth_password_change'),

and
 
url(r'^password/reset/confirm/(?P[0-9A-Za-z]+)-(?P.+)/$',
auth_views.password_reset_confirm,
{'set_password_form': MySetPasswordForm}, 

And that's it.

Spork

-- 
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+unsubscr...@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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Right way to modify contrib auth package?

[testbackupacct]

Anton,

Great -- this is exactly what I needed to know. Thanks for the guidance.

Spork

On Thursday, May 2, 2013 7:31:57 AM UTC-7, bak1an wrote:
>
> Hi.
>
> I think that subclassing PasswordChangeForm and doing password length 
> check in child's clean method is more "correct" way to do this.
>
> Note that contrib.auth's views accept form class as parameter (
> https://github.com/django/django/password_resetblob/master/django/contrib/auth/views.py#L242),
>  
> so you can pass your custom form class to view at urls.py, like that:
>
> url(r'^/url/$', view, {'password_change_form': CustomPasswordResetForm})
>
> On Thu, May 2, 2013 at 5:45 AM, wrote:
>
>> Hi,
>>
>> I'm fairly new to Django, and would like to enforce a minimum password 
>> length for my site's users. I'm using James Bennett's registration package 
>> and have made the needed changes to forms.py. It works great.
>>
>> Now I'd like to apply the same password requirements when a user changes 
>> or resets their password. This functionality is handled by the contrib.auth 
>> package, and at first blush it looks like all I need to do is edit the 
>> forms.py there.
>>
>> But I'm wondering if that's the "correct" way to fold changes into a core 
>> package like auth. Is there a better way to do this?
>>
>> Thanks in advance,
>>
>> Spork
>>
>> -- 
>> 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...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/django-users?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>
>
> -- 
> Regards,
> Anton Baklanov
>  

-- 
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+unsubscr...@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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Right way to modify contrib auth package?

[testbackupacct]

Hi,

I'm fairly new to Django, and would like to enforce a minimum password 
length for my site's users. I'm using James Bennett's registration package 
and have made the needed changes to forms.py. It works great.

Now I'd like to apply the same password requirements when a user changes or 
resets their password. This functionality is handled by the contrib.auth 
package, and at first blush it looks like all I need to do is edit the 
forms.py there.

But I'm wondering if that's the "correct" way to fold changes into a core 
package like auth. Is there a better way to do this?

Thanks in advance,

Spork

-- 
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+unsubscr...@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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Newbie CSRF protection questions

[testbackupacct]

Russ,

This is a really great explanation of CSRF vulnerabilities, and I think I 
have a handle on what I need to do now.

Thanks for taking to time to spell things out for me.
>
>
Best,

Spork

-- 
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+unsubscr...@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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Newbie CSRF protection questions

[testbackupacct]

Hi,


I'm fairly new to web development and Django, and I'm trying to make sure 
my application is protected against CSRF attacks. I've read through 
https://docs.djangoproject.com/en/dev/ref/contrib/csrf/, but I'm not 
confident I'm understanding it fully. I'd be very grateful for some 
feedback on what I'm doing.


I started by enabling CsrfViewMiddleware. Then I looked at my POST forms:


 1) I have POST forms that go to internal URLs in templates, both in my own 
application and in the registration library I'm using. All of them use the 
csrf_token tag, so I think I'm set there.


 2) I do POSTs to internal URLs from my client-side javascript. Some POSTs 
are already baked into this code, but one gets built on the fly.


My first question comes from the beginning of the doc, where it says,"The 
first defense against CSRF attacks is to ensure that GET requests are 
side-effect free." What's meant by "side effect free"?


I also have a question about this line: "In the corresponding view 
functions, ensure that the 'django.core.context_processors.csrf' context 
processor is being used." I'm interpreting this to mean: "in the view 
functions that are used to render your templates that do POSTs, ensure that 
the csrf context processor is being used." That is, I don't need to worry 
about the context processor in views that are just handling POSTs that 
originate via AJAX from my client side. Am I understanding this correctly?


I have one view that handles a webhook/POST that originates from outside my 
site and comes from a non-logged-in-user. I have decorated this view with a 
csrf_exempt decorator and don't return the CSRF token in my response. So I 
think I am covered there -- correct?


For the POSTs that originate from my client-side javascript code, I use the 
code given in the doc to get the token from csrf cookie and attach it to 
outgoing AJAX calls to internal URLs for HTTP/HTTPS methods that require 
it. But there is one POST form I build on the fly. Since the page that runs 
that code is generated by a template and the CSRF token is included in the 
context, I included this code:


 

var getCSRFToken = function () { return "{% csrf_token %}"; };




and call the function when I'm building my form. Is that the right way to 
handle this?


Thanks in advance for any advice or critiques you can give me.


Spork


-- 
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+unsubscr...@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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Newbie question: session-length data storage best practices?

[testbackupacct]

Nik,

My concerns are about security. I have some sensitive data associated with 
each user's session, and I'd like to make sure it is deleted when the user 
logs out or their session times out or closes their browser window. There's 
also some other clean up actions I'd like to do under the same 
circumstances.

I took a look at the session caching documents (thanks for the pointer), 
and I think I would have to go for the cached_db option; if I just used the 
plain vanilla cache option and the data got expired out of the cache, it 
would create a terrible user experience. But I would to understand the 
mechanism by which session data gets purged from the database backend. Can 
I rely on it getting purged with each log out/session time out/browser 
window closure? 

Again, thanks for the good feedback.

Spork

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/SOs0zvR48PMJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Newbie question: session-length data storage best practices?

[testbackupacct]

Ok, you've made a very convincing argument. I really haven't spent much time 
thinking about scalability -- obviously it's time for me to do so!

Thanks for taking the time to respond.

Spork

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/fSWRIFv4ioEJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Newbie question: session-length data storage best practices?

[testbackupacct]

Hi,

I've got some data that I'll need read/write access to for the length of an 
authenticated session's lifetime. But once that browser tab is closed or 
the user logs out or the user session times out, I want that data to 
disappear.

If I'm reading the session docs correctly, if I add the data to the session 
object, it'll get persisted, which I don't want. I believe I'll have the 
same problem if I extend the user profile. And I *really* don't want to 
store the data in the session cookie. 

For the time being, I'm just storing it in a global data structure in my 
views.py, and deleting the data via a 'user logged out' signal. But I can't 
seem to find a 'session timed out' signal to catch. And, anyway, I can't 
shake the feeling that there's a better way to do this. Is there?

Thanks in advance!

Spork


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/dokMLZNlkbIJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.