Hello, Jacob.
The current auth module has a very security bug, if the session cookie is
stolen by others, you cannot do anything to stop them.
You changed your password, but the session is still working. You signed
out, the session is still working. You can do nothing, but waiting for the
session to expire.
Here is my solution:
-------------------------------
user's session stores "%s,%s" % (user_id, user_password_hash) instead of
user_id.
and then we can get user from session.split(',')[0] and compare
user.password_hash == session.split(',')[1]
In this case, if a user changed his password, all sessions would be
invalid. And all the problems are solved.
On Saturday, 17 March 2012 00:53:11 UTC+8, Jacob Kaplan-Moss wrote:
>
> Hi folks --
>
> This discussion of user authentication by email is getting pretty nasty;
> can we start over? I know there's a lot of quite legitimate frustration
> here, but we really need to drop the personal stuff and focus on the
> problem at hand. I want to move this forward quickly, and I can commit to
> spending some time on it in the coming weeks, but I'm going to lose
> interest faster than than you can believe if the tone doesn't improve.
> Please: keep it professional, and focus on the tech. I promise things'll go
> smoothly if we all do.
>
> As I see it, there's two basic approaches we could take:
>
> 1. Incremental improvement: fix the most glaring issues with auth.User
> (starting with email addresses for login, clearly), and generally improve
> things a bit at a time. Once User's in a state where we're happy, move on
> the rest of the auth app -- again, a bit at a time. This approach would see
> the largest issues fixed more quickly, but would probably do so at the
> expense of code quality (e.g. requiring a one-off solution to schema
> migration of the User model) and would delay a more sweeping reform until
> later.
>
> 2. Complete improvement: recognize that the auth app is fundamentally
> flawed, and mercilessly refactor/replace/rewrite it, all in one go. The
> hypothetical results here would be better -- a modern auth system
> unencumbered by the decisions we made in 2005 -- but this would take far
> longer, and would block on things like the app refactor and schema
> migrations.
>
> There's also a middle-ground proposal from Clay: make the auth app
> swappable, thus making it possible for *users* to replace the auth app
> while leaving time for us to make either incremental or complete change, as
> we see fit.
>
> I think we need to come together and agree on an approach before we move
> forward, so I'd like to see some concrete proposals for each of these
> approaches. Since all options have merits and since I think it's unlikely
> we'll find consensus I'm prepared to make a BDFL ruling here. So if you
> feel strongly about one approach or another, please write a concrete
> proposal and post it here or on the wiki. I'll look these over -- and also
> review Clay's branch -- and (again, baring consensus) make a ruling next
> week.
>
> Just so my biases are clear: normally I'd lean more towards the
> completionist stance, but in this case I haven't seen an actual proposal to
> completely replace auth. Further, I think the fact that it's blocked on
> *other* pretty hairy issues means it'd be unlikely to see that much action
> that quickly. I'm also somewhat opposed to the "pluggable auth" idea since
> I think it dilutes the utility of having built-in auth. In other words, if
> we're going to make auth up to users, why not just get rid of the built-in
> auth altogether? So I'm leaning towards an incremental improvement
> approach, but only if I can see a concrete proposal that articulates what
> to change, and deals with the backwards-compatibility issues in a
> not-too-ugly way.
>
> Thanks!
>
> Jacob
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/OEIHlY6NBe8J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
