Hello,
This is my fist post, so I'm not fully aware of any posting policies you
have, but at least I'll try to present my ideas in clear way.
*Very brief description of what I suggest:*
Optionally delegate password change and password reset to authentication
backend.
*Motivation:*
Django
User is only annotated with backend when calling authenticate(). On
subsequent requests, or in non-request situations like the Python shell,
how will you know which backend to delegate to?
How do existing LDAP backends deal with this problem? (or do they just
ignore it?)
On Thursday, December
All right, that's what I've missed. Thank you, for this point.
Existing LDAP backends I've reviewed do not support password change/reset
at all.
On Thursday, December 11, 2014 7:49:05 PM UTC+4, Tim Graham wrote:
>
> User is only annotated with backend when calling authenticate(). On
> subseque
I've researched a little more, and looks like there is BACKEND_SESSION_KEY
so it is possible to annotate user with backend on subsequent requests.
https://github.com/django/django/blob/master/django/contrib/auth/__init__.py#L169
Look like it should be a one line fix for this like
user.backend = ba
I haven't used external authentication backends for any projects, but I
still think the concept of dynamically changing how the password change
form/views work based on which backend you authenticated with is too much
complexity. This scheme feels very brittle and I'm not sure that making
this
Tim,
It's not about the benefit, it's about the possibility. The one simply
cannot use two external backends with support of password change because
each backend will have to provide own User model. I understand your point,
and I agree that some logic I suggest seems controversial, but current
Yes, I am by no means speaking definitively on the issue -- just voicing
some concerns that I see. I'd love if people with experience with
third-party authentication backends would join the discussion.
On Saturday, December 13, 2014 4:28:52 AM UTC-5, Roman Akopov wrote:
>
> Tim,
>
> It's not abo
I've used third party authentication backends, but your request seems a bit
odd to me. I think I'm being caught up on the some of the specifics without
enough context. Why can you not use a custom User that stores the backend
that created it (or last used for authentication) and overrides
set_passw
First, of course I can use custom User model, but two indendetly developed
backends, like backend authenticating against LDAP, and backend
authenticating against custom HTTP service will provide two User models,
each with set_password implementation supporting only one backend and I'll
have to
I've been maintaining a custom django backend for quite awhile now. It
delegates authentication and authorization to an internal API. I do not use
a custom User model at all.
The backend completely handles the reset/change password logic, and the
form uses the methods on the backend directly. I
Great!
I would like to take a look at any source code you can share.
On Sunday, December 14, 2014 10:10:58 AM UTC+4, Josh Smeaton wrote:
>
> I've been maintaining a custom django backend for quite awhile now. It
> delegates authentication and authorization to an internal API. I do not use
> a c
https://gist.github.com/jarshwah/c5b9abebb452f2e3286f
I've removed some of the error handling and custom application bits, and
I've also renamed the classes. But this is the meat of auth for my project.
You'll notice that the backend is hardcoded in the constructor, because we
only use this bac
Thanks a lot.
To make it clear, do I understand right that you have some custom view to
process APIPasswordChangeForm and not using
django.contrib.auth.views.password_change?
On Sunday, December 14, 2014 2:17:16 PM UTC+4, Josh Smeaton wrote:
>
> https://gist.github.com/jarshwah/c5b9abebb452f2e3
Correct - I've updated the
gist: https://gist.github.com/jarshwah/c5b9abebb452f2e3286f
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, sen
All right, that's exactly what I'm talking about.
You wrote more than 50 lines of python code, reimplemented standard
inextensible features, just to call one function. And changing password is
simple task actually, reseting password needs to deal with tokens, emails,
etc. So it will be a few Mu
Ok, I see where your suggestions could make a lot of sense. Thanks for
persisting with me.
I've updated my gist again with what a refactor could allow it to look
like: https://gist.github.com/jarshwah/c5b9abebb452f2e3286f
The backend remains unchanged. The form removes most custom handling,
as
16 matches
Mail list logo
