#25030: The /admin/login/ should observe external authentication even when it
appears in POST
------------------------------+------------------------------------
Reporter: adelton | Owner: nobody
Type: New feature | Status: new
Component: contrib.auth | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
------------------------------+------------------------------------
Comment (by adelton):
Replying to [comment:2 claudep]:
> Regarding the current test failure for the patch, you are right about
ticket #19327 not being an issue any more with the new design.
Thanks for the confirmation.
> However, your patch is still slightly changing the "overriden-login"
behavior. Currently if I have two windows/tabs with a login form and I try
to login with two different users, the second POST will log the second
user which becomes then the current session user. With your patch, the
second POST will redirect to admin index while the first user is still the
current session user (already logged-in behavior). I understand that this
is an edge use case, as normally users logout before logging in as a
different user.
I understand the problem. However, checking the situation you describe
(open two tabs with unauthenticated /admin/login/, get two forms, submit
the first, submit the second with different username), I get
{{{
Forbidden (403)
CSRF verification failed. Request aborted.
}}}
So it looks like lately this scenario is not really possible, at least
with the django.middleware.csrf.CsrfViewMiddleware which seems enabled by
default.
I wonder if we have any way to figure out that the user was just
authenticated (their session marked as authenticated) in the current
request, presumably by some middlerware, to distinguish from the situation
when we piggybacked on some other long-running session.
> Your current proposal is only addressing the admin login use case, isn't
it? I'd be in favor of solving it directly in contrib.auth so every login
would benefit from it.
Yes, I only looked at admin. I will need to dig deeper into contrib.auth
to understand the interactions there.
> We might find a way to short-circuit the contrib.auth login view when
request.user is already authenticated and user.backend point to
RemoteUserBackend or a subclass. Thoughts?
That would certainly allow us to target the use case that I have in mind
most precisely. But I'm afraid that it might break the logic separation,
if we started to poke into users' backends directly -- it feels like
something that the application should not really care about.
--
Ticket URL: <https://code.djangoproject.com/ticket/25030#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.55175b3ca18a93199469cd5655a9d12a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
