no relationship between session and user model

[Vaal]

Hello!

There is a reason why in the framework (by default), there is no connection between the models user and session?

I mean ForeignKey(to User) in Session model for example.

This would be useful in a situation when the user changes the password, and we could remove all the sessions of that user.

For example the user changes the password because he believes that pass has been compromised. But if the attacker was already has active session - it will not be interrupted.

p.s. sorry for my English

p.p.s. I understand that can modify the application sessions for their needs and make a new application or to find a ready-made.

[Alexandr Shurigin]

Interesting question. Really django provides few sessions backends by default and only 2 of them store any session info in database (db, cached_db). All other backends save session info in various cache storages like memcache, redis, files, local cache, etc. Right now sessions built as a part of http protocol only, not user level.

This relation is not possible out of the box if we want to have highly customizable framework :)

Don’t worry, my english is ugly too ;)

-- 
Alexandr Shurigin

--
You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8ac582df-e1f1-4619-863c-134cadefc405%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Vladimir Ulupov (Vaal)]

This relation is not possible out of the box if we want to have highly customizable framework :)

But backends already have differences.

For example: only two implemented a method clear_expired 

https://github.com/django/django/blob/master/django/contrib/sessions/backends/file.py#L190

https://github.com/django/django/blob/master/django/contrib/sessions/backends/db.py#L81

How such a relationship may limit customizable? btw it's maybe as option...

четверг, 19 июня 2014 г., 20:40:14 UTC+4 пользователь Alexandr Shurigin написал:

[Alexandr Shurigin]

Other storages doesn’t need it.

cached_db inherits DbStorage https://github.com/django/django/blob/master/django/contrib/sessions/backends/cached_db.py#L17

and of course have implemented same clear_expired.

signed_cookies uses cookie expiring i think (not checked).

and cache storages uses caching expiring features.

I think dependency of user_id must not be in core, not all storages can implement api (find all sessions of user for example) for this feature simple (file based sessions for example. You will need to process all sessions or use some type of meta file with dependencies). This is application level feature, not framework. I think you can simple implement your session database backend with this feature (don’t forget on user login/logout change user_id) included and share for community if nobody did it already :)

-- 
Alexandr Shurigin

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/848d8356-2614-4fc3-a20e-18b69786fda4%40googlegroups.com.

[Alexandr Shurigin]

Take a look for https://pypi.python.org/pypi/django-user-sessions please.

Looks like what you need.

-- 
Alexandr Shurigin

[Aymeric Augustin]

Previous answers explain why the sessions API makes it impossible to create a FK from Session to User. However, it looks like this isn't the question you wanted to ask.

Your real question seems to be: "how can I invalidate sessions on password change?" Fortunately, Django 1.7 includes a new middleware for this purpose.

https://docs.djangoproject.com/en/dev/ref/middleware/#django.contrib.auth.middleware.SessionAuthenticationMiddleware

-- 

Aymeric.

[Ramiro Morales]

On Thu, Jun 19, 2014 at 1:07 PM, Vaal <vaa...@gmail.com> wrote:

> This would be useful in a situation when the user changes the password, and
> we could remove all the sessions of that user.
> For example the user changes the password because he believes that pass has
> been compromised. But if the attacker was already has active session - it
> will not be interrupted.
>

Django 1.7 changes this. See

https://docs.djangoproject.com/en/1.7/topics/auth/default/#session-invalidation-on-password-change

Regards,

--
Ramiro Morales
@ramiromorales

[Vladimir Ulupov (Vaal)]

You are right about my question. Next time I will read carefully the release notes. Thx!

четверг, 19 июня 2014 г., 21:34:02 UTC+4 пользователь Aymeric Augustin написал: