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_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
>
> середа, 10 січня 2018 р. 20:13:06 UTC+1 користувач Sergey Glazyrin написав:
>>
>> 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 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 there is consensus.
>>>
>>> On 10 Jan 2018 19:00, "Sergey Glazyrin" <[email protected]> wrote:
>>>
>>> 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 implementation in this case because
>>> load_backend always returns a new instance of the class, so, I expect no
>>> threading problems, etc, it's just a way to distribute process of building
>>> objects
>>> About adding request to get_user, I don't like it because then all
>>> dependent of django projects will need to change backends, it would be
>>> worst for community
>>>
>>> середа, 10 січня 2018 р. 19:52:06 UTC+1 користувач Tom Forbes написав:
>>>>
>>>> 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 like it would be harder to get consensus.
>>>>
>>>> You could maybe get more traction if you suggested firing a signal that
>>>> is passed the auth instance as a parameter when it is initialized, which
>>>> is
>>>> akin to your suggestion, however IMO that's still not a great idea.
>>>>
>>>> On 10 Jan 2018 18:18, "Tim Graham" <[email protected]> wrote:
>>>>
>>>>> 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 patching. We did a similar change for the authenticate() method
>>>>> [1],
>>>>> I'm not sure if there would be consensus to make the change.
>>>>>
>>>>> [1] https://code.djangoproject.com/ticket/25187
>>>>>
>>>>> On Wednesday, January 10, 2018 at 1:12:55 PM UTC-5, Sergey Glazyrin
>>>>> wrote:
>>>>>>
>>>>>> 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 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 something
>>>>>>> couldn’t
>>>>>>> you call ‘auth_user.create_user_from_token’ yourself and set it on the
>>>>>>> request object rather than monkeypatch Django?
>>>>>>>
>>>>>>> On 10 January 2018 at 12:22:01, Sergey Glazyrin (
>>>>>>> [email protected]) wrote:
>>>>>>>
>>>>>>> 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
>>>>>>>> .....
>>>>>>>> backend = load_backend(backend_path)
>>>>>>>> backend,request = request
>>>>>>>> .....
>>>>>>>> code
>>>>>>>> .....
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> But I don't like this solution because I'll need to keep my eyes on
>>>>>>> this monkey patch while django upgrade, etc, and it's very dirty hack.
>>>>>>>
>>>>>>> Instead I propose to extend django behaviour using design pattern
>>>>>>> Builder to simplify integration of another apps into django object
>>>>>>> internals (it sounds hacky, but it's safe and simple to implement)
>>>>>>>
>>>>>>> with change I proposed, the patch would be done on django level, we
>>>>>>> need to add
>>>>>>>
>>>>>>> def get_user(request):
>>>>>>>>
>>>>>>>> ...
>>>>>>>> code
>>>>>>>> ...
>>>>>>>>
>>>>>>>> backend = load_backend(backend_path)
>>>>>>>> DjangoObjectBuilder.do_initialize_object(backend, request)
>>>>>>>> ....
>>>>>>>> code
>>>>>>>> ....
>>>>>>>
>>>>>>>
>>>>>>> and in another django package we subscribe to this object
>>>>>>> initialization:
>>>>>>>
>>>>>>>
>>>>>>> def add_request_to_backend(obj, request):
>>>>>>>> obj.request = request
>>>>>>>> DjangoObjectBuilder.add_custom_initializer(lambda obj:
>>>>>>>> isinstance(obj, openstack_auth.Backend), add_request_to_backend)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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,
>>>>>>> send an email to [email protected].
>>>>>>> To post to this group, send email to [email protected].
>>>>>>> Visit this group at
>>>>>>> https://groups.google.com/group/django-developers.
>>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com
>>>>>>>
>>>>>>> <https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>> .
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>> --
>>>>> 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, send
>>>>> an email to [email protected].
>>>>> To post to this group, send email to [email protected].
>>>>> Visit this group at https://groups.google.com/group/django-developers.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/django-developers/9ae497ad-3c48-4cb9-9122-1b67c5186066%40googlegroups.com
>>>>>
>>>>> <https://groups.google.com/d/msgid/django-developers/9ae497ad-3c48-4cb9-9122-1b67c5186066%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>> --
>>> 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, send
>>> an email to [email protected].
>>> To post to this group, send email to [email protected].
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/889705e4-7247-4860-97bd-ee7f0bcbdbc5%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/django-developers/889705e4-7247-4860-97bd-ee7f0bcbdbc5%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
--
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, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/2564202c-8b2d-4bbb-ad53-b4edcac91d18%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
