If a project is using an AUTHENTICATION_BACKENDS with only the default
backend in it, and then at some point they need to make some small tweak
(case-insensitive lookups, perhaps), so they subclass it and now have an
AUTHENTICATION_BACKENDS setting that still has only one backend,
basically the sa
Hi Unai,
On 05/25/2015 10:52 AM, Unai Zalakain wrote:
>> We can't default the `backend` argument to anything but a sentinel
>> value, because if it's supplied, it should take priority, but if it's
>> not supplied we need to maintain backwards compatibility with existing
>> behavior, where the `use
We can't default the `backend` argument to anything but a sentinel
value, because if it's supplied, it should take priority, but if it's
not supplied we need to maintain backwards compatibility with existing
behavior, where the `user.backend` annotation is used.
So, to sum app, the behaviour wou
On 05/24/2015 02:17 AM, Unai Zalakain wrote:
>> 3) Use the only configured backend, if there is only one.
>> 4) Raise ValueError("You have multiple authentication backends
>> configured; you must provide the `backend` argument to `login`.")
>
> What about defaulting the backend argument to Django'
On Sat, May 23, 2015 at 3:38 PM Carl Meyer wrote:
> On 05/23/2015 11:37 AM, Marc Tamlyn wrote:
> > If the backend is inferred by a single value in the settings and not
> > stored alongside the user ID, what would happen to existing users
> > who are already logged in when a second bac
3) Use the only configured backend, if there is only one.
4) Raise ValueError("You have multiple authentication backends
configured; you must provide the `backend` argument to `login`.")
What about defaulting the backend argument to Django's default auth
backend? This way most of the sites wil
On 05/23/2015 11:37 AM, Marc Tamlyn wrote:
> If the backend is inferred by a single value in the settings and not
> stored alongside the user ID, what would happen to existing users
> who are already logged in when a second backend is added to the
> settings and deployed? Django wou
>
> If the backend is inferred by a single value in the settings and not
> stored alongside the user ID, what would happen to existing users who are
> already logged in when a second backend is added to the settings and
> deployed? Django would no longer know which backend to use to fetch the
> aut
Hey all,
A note on Carl's first suggestion. I currently override the authenticate
function with my own that does something similar. Instead of passing in a
single backend I pass in an iterable (usually a set for O(1) checks) that
optionally overrides settings.AUTHENTICATION_BACKENDS.
I haven't
I agree, why not always pass the single auth backend into the login
function?
If the backend is inferred by a single value in the settings and not stored
alongside the user ID, what would happen to existing users who are already
logged in when a second backend is added to the settings and deplo
Hi Paulo!
If the application has only one backend we always infer it in the login
function. If it isn't, the client needs to provide one explicitly.
Why not pass the single auth backend into the login function? It makes
the design and the documentation much simpler.
--
unai
--
You receive
Hi Paulo,
On 05/22/2015 02:42 PM, Paulo Gabriel Poiati wrote:
> I completely agree with the API design, it can be improved. What I'm
> really trying here is to keep things simple.
>
> I don't see that importance in keeping the authentication backend
> information in the http session (maybe I'm mi
Tks Carls,
I completely agree with the API design, it can be improved. What I'm really
trying here is to keep things simple.
I don't see that importance in keeping the authentication backend
information in the http session (maybe I'm missing something), we can
always use some kind of audit to han
> On May 22, 2015, at 3:07 PM, Carl Meyer wrote:
>
> Hi Paulo,
>
> On 05/22/2015 01:49 PM, Paulo Gabriel Poiati wrote:
>> I understand your points Carl, but I'm more inclined to think about the
>> average django developer and the new comers. Most people don't know or
>> don't want to know what
Hi Paulo,
On 05/22/2015 01:49 PM, Paulo Gabriel Poiati wrote:
> I understand your points Carl, but I'm more inclined to think about the
> average django developer and the new comers. Most people don't know or
> don't want to know what an Authentication Backend is, they just want to
> write their a
I understand your points Carl, but I'm more inclined to think about the
average django developer and the new comers. Most people don't know or
don't want to know what an Authentication Backend is, they just want to
write their app. That is why I don't like exposing this kind of detail in
the client
On 05/22/2015 09:44 AM, Tim Graham wrote:
> Could you elaborate on what use case you are trying to solve?
>
> On Friday, May 22, 2015 at 11:36:21 AM UTC-4, poiati wrote:
>
> Hello guys,
>
> I want to discuss the current login workflow in django. As it is we
> need to call `authentica
Here is a related ticket for doing this in tests, where frankly I don't
care about authentication. https://code.djangoproject.com/ticket/20916
On 22 May 2015 at 17:30, Paulo Gabriel Poiati
wrote:
> Good point James,
>
> It make sense if you could login the user without the credentials
> (proposa
Good point James,
It make sense if you could login the user without the credentials
(proposal).
On Fri, May 22, 2015 at 1:21 PM James Brewer
wrote:
> Hey Paulo,
>
> As you mentioned, the raw password should still be present in the form,
> along with the username. You can use these as parameters
One advantage of authenticate() is that it isn't coupled to a request and
is roughly stateless. Maybe an authenticate_and_login() would be nice. :)
On Friday, May 22, 2015 at 12:21:15 PM UTC-4, James Brewer wrote:
>
> Hey Paulo,
>
> As you mentioned, the raw password should still be present in th
Hey Paulo,
As you mentioned, the raw password should still be present in the form,
along with the username. You can use these as parameters for
`authenticate()`.
More to your original point, I would be interested in knowing why
`authenticate()` and `login()` are separate methods. There is no
info
Maybe this is not the perfect example because we have the plain password in
the form. Another one is if a backoffice user can log as any user of the
system.
On Fri, May 22, 2015 at 12:53 PM Paulo Gabriel Poiati <
paulogpoi...@gmail.com> wrote:
> Of course Tim,
>
> One instance is if you need to l
Of course Tim,
One instance is if you need to login the user after registration:
class RegistrationView(CreateView):
...
def form_valid(self, form):
user = form.save()
login(self.request, user)
# redirect
I don't have the user password because it's an one way has
Could you elaborate on what use case you are trying to solve?
On Friday, May 22, 2015 at 11:36:21 AM UTC-4, poiati wrote:
>
> Hello guys,
>
> I want to discuss the current login workflow in django. As it is we need
> to call `authenticate` before `login` because we need to set the
> authenticati
Hello guys,
I want to discuss the current login workflow in django. As it is we need to
call `authenticate` before `login` because we need to set the
authentication backend in the user model. We can use login without
authenticate if we set the backend attr manually, but this need some
implementati
25 matches
Mail list logo
