hello guys!
I added a new changeset to reflect what we discussed here
Please check it out.
https://github.com/django/django/compare/master...sergeyglazyrindev:master
середа, 10 січня 2018 р. 21:02:41 UTC+1 користувач Sergey Glazyrin написав:
>
> or we can add a simple builder helper
> def build_ba
or we can add a simple builder helper
def build_backend_django_object(class_, request):
obj = class_()
if hasattr(obj, 'request'):
warnings.warn('Please change your auth backend because now we pass to
the instance of backend HttpRequest object')
else:
obj.request = request
return obj
середа
ok, let me know if there would be any consensus and I'll change my solution
according to maintainers consensus.
середа, 10 січня 2018 р. 20:10:46 UTC+1 користувач Tom Forbes написав:
>
> Django has managed this before by examining the function signature. Adding
> a property directly onto the ins
Django has managed this before by examining the function signature. Adding
a property directly onto the instance could cause some issues, for example
if there is already a user property. I guess this could be detected and a
deprecation warning issued though.
Anyway, this is all academic unless the
We use function load_backend in django about 5 times in production code,
so, it shouldn't be a big change
About signals idea: yes, I can implement it using signals abstraction
though I prefer to be tied to the "Builder" idea, there would no big
difference between signals and Builder implementati
I would be in favour of a mechanism to help with this use case, I ran into
a somewhat similar issue when using JWTs and a non-model backed user.
Adding a user parameter seems like the easiest solution and quite simple,
whereas adding a builder class into this particular section of Django seems
lik
that would allow another python packages to subscribe to specific parts of
building django objects and that would be very expandable solution
середа, 10 січня 2018 р. 19:18:28 UTC+1 користувач Tim Graham написав:
>
> Without studying the openstack code much it's hard for me to say if the
> solut
Yes, that would be a consensus but who knows the future, what if one day
another django auth backend will need request in another method,
that's why I prefer the idea of implementing it into design pattern
"Builder" way. It's much more cleaner solution, imho
середа, 10 січня 2018 р. 19:18:28 UTC
Without studying the openstack code much it's hard for me to say if the
solution there is the best approach and that a more elegant solution
doesn't exist. It looks like if we added 'request' to the signature of the
authentication backend get_user() method, that would remove the need for
monkey
Btw, I see no way how do I use this auth_user.create_user_from_token to
solve this problem.
It uses django contrib auth get_user function, so the proper place is to to
use django auth backend logic.
середа, 10 січня 2018 р. 14:17:50 UTC+1 користувач Tom Forbes написав:
>
> I think Tim’s assessme
But the one thing I don't like is monkey patching. It's ok when you patch
some whole implementation of something, for example, replace socket
implementation in gevent with socket implementation in redis.
But when we need to patch something internally in function, that's bad
So, I want just to
Hello Tom
Thank you for your reply
Let me explain the situation again
Openstack auth doesn't use django models at all, it uses keystoneauth
authorization logic
And this logic requires some data from request to recognize user
https://github.com/openstack/horizon/blob/master/openstack_auth/backend
I think Tim’s assessment in the ticket is on point, a DjangoObjectBuilder
would look very strange and out of place if included (it’s not particularly
pythonic either).
Seems like there might be a legitimate issue here (or maybe just bad
designs in OpenStack?), but unless I’m misunderstanding somet
Hello guys!
I faced a situation when auth backend needs access to request object inside
of get_user auth backend function
https://code.djangoproject.com/ticket/29005
I can patch it following way (function to be patched is
django.contrib.auth.get_user)
def get_user(request):
>
..
> code
14 matches
Mail list logo
