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

[Javier Guerra Giraldez]

On Sat, Jan 19, 2013 at 3:03 PM, <testbac...@gmail.com> wrote:
> 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 think you _do_ want it to be persisted.

remember that HTTP is a stateless protocol. to have it even slightly
scalable (anything beyond a handful of users), you have to realize
that your sessions are longer than the request/response cycle, and can
be handled by any one of several processes. that's why the session
object saves its data to some backend.

now, not every backend have to necessarily write to disk. i think you
could simply use the memcached backend.

> 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.

not the same problem, but if you want session-long data, the best
place to save it is on the session object.


> 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?


that's definitely a bad idea. it will break down as soon as you use a
non-single-process deployment.

the session object is specifically thought to share data between not
only from one request to the next, but also between the different
processes that might handle it. tying the user to a single process
creates a very low performance ceiling.


--
Javier

[testbac...@gmail.com]

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

[Nikolas Stevenson-Molnar]

If I understand correctly, you just need to set
SESSION_EXPIRE_AT_BROWSER_CLOSE = True in your settings:
https://docs.djangoproject.com/en/1.4/topics/http/sessions/#browser-length-sessions-vs-persistent-sessions

When the user closes their browser, the session ends. True, the
associated data isn't deleted right when this happens (the server has no
way of knowing when the user has done this), but that data will no
longer be associated with anyone. If you're particularly concerned about
the data not going to disk, you can use a cached session engine (with
memcached) , as Javier suggests:
https://docs.djangoproject.com/en/1.4/topics/http/sessions/#using-cached-sessions

It may help to know a little bit more about what you're trying to
accomplish. Is your concern security or user experience related?

_Nik

On 1/19/2013 12:03 PM, testbac...@gmail.com wrote:
> 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...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.

[testbac...@gmail.com]

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

[Nikolas Stevenson-Molnar]

Hi Spork,

See this section of the sessions docs:
https://docs.djangoproject.com/en/1.4/topics/http/sessions/#clearing-the-session-table

While it mentions file and db backends specifically, I assume the cache
backend would work similarly. I.e., you need to periodically run a
cleanup of session data. According to the docs, Django will
automatically delete session data when the user logs out, but not
otherwise (again, the server has no reliable way of knowing the user has
closed the browser window) so if you want the data gone, you have to
clean it up periodically.

Taking a step back, I don't think this is a good approach to security.
This data is still residing on your server for however short a time
period. The issue should be less one of how long the data exist there,
and more about how to keep it safe. How to do that depends somewhat on
the nature of the data (e.g., SSNs or credit card numbers should reside
only on a system not connected directly to the internet).

_Nik

> --
> 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.

[Nikolas Stevenson-Molnar]

Upon a second glance, it looks like the clearsession command will only
have an effect as of Django 1.5. For <=1.4 if you're using the DB
backend, you could always clear them out yourself with a query:

now = datetime.datetime.now()
Session.objects.filter(expire_date__lt=now).delete()

_Nik