ease patching Django object behavior in another django packages

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

ease patching Django object behavior in another django packages

Sergey Glazyrin
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 [hidden email].
To post to this group, send email to [hidden email].
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.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ease patching Django object behavior in another django packages

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 ([hidden email]) wrote:

Hello guys!
I faced a situation when auth backend needs access to request object inside of get_user auth backend function


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 [hidden email].
To post to this group, send email to [hidden email].
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.
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFNZOJM6JqGC6CgxfdJDpMp2GutC8h%3DuCoWXiAb6xZ0f9om04g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ease patching Django object behavior in another django packages

Sergey Glazyrin
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.py#L66

In case of default django function get_user shouldn't have an access to request because it uses django model to get a user but in case of openstack it's totally different

And unfortunately I see one way - patch django get_user method because we need it for django-websocket-redis uwsgi process

https://github.com/jrief/django-websocket-redis/blob/master/ws4redis/wsgi_server.py#L69

Right now the problem is in django-websocket-redis uwsgi process the user is always Anonymous because openstack auth is not able to recognize user due to the request absence in openstackauthbackend.

About my solution, well, I am happy to accept any ideas, my solution uses one of design patterns to solve a problem. Well, the problem is simple: we have few different packages which uses one class, but for some specific case this class should have an access to another object, for such purposes, there's a pattern Builder

https://sourcemaking.com/design_patterns/builder

As I said, I am happy to accept any comments, ideas how to solve it more properly

Thank you again for your time.

середа, 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?

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/f84a929a-eead-48ae-a6ce-114a3a635320%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ease patching Django object behavior in another django packages

Sergey Glazyrin
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 improve design of django to simplify it in future.
But again, I respect django developers opinion and it's up to you :)

середа, 10 січня 2018 р. 19:00:56 UTC+1 користувач Sergey Glazyrin написав:
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
<a href="https://github.com/openstack/horizon/blob/master/openstack_auth/backend.py#L66" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fopenstack%2Fhorizon%2Fblob%2Fmaster%2Fopenstack_auth%2Fbackend.py%23L66\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEpW_7CHfLw0tSVlz8_vaNRtor5Gw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fopenstack%2Fhorizon%2Fblob%2Fmaster%2Fopenstack_auth%2Fbackend.py%23L66\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEpW_7CHfLw0tSVlz8_vaNRtor5Gw&#39;;return true;">https://github.com/openstack/horizon/blob/master/openstack_auth/backend.py#L66

In case of default django function get_user shouldn't have an access to request because it uses django model to get a user but in case of openstack it's totally different

And unfortunately I see one way - patch django get_user method because we need it for django-websocket-redis uwsgi process

<a href="https://github.com/jrief/django-websocket-redis/blob/master/ws4redis/wsgi_server.py#L69" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjrief%2Fdjango-websocket-redis%2Fblob%2Fmaster%2Fws4redis%2Fwsgi_server.py%23L69\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFWI5OehW5iEiS2b1KvH1FDnWU9wA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjrief%2Fdjango-websocket-redis%2Fblob%2Fmaster%2Fws4redis%2Fwsgi_server.py%23L69\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFWI5OehW5iEiS2b1KvH1FDnWU9wA&#39;;return true;">https://github.com/jrief/django-websocket-redis/blob/master/ws4redis/wsgi_server.py#L69

Right now the problem is in django-websocket-redis uwsgi process the user is always Anonymous because openstack auth is not able to recognize user due to the request absence in openstackauthbackend.

About my solution, well, I am happy to accept any ideas, my solution uses one of design patterns to solve a problem. Well, the problem is simple: we have few different packages which uses one class, but for some specific case this class should have an access to another object, for such purposes, there's a pattern Builder

<a href="https://sourcemaking.com/design_patterns/builder" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fsourcemaking.com%2Fdesign_patterns%2Fbuilder\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFbBAqHf5fVyAv7OTBteKuj4ZHqBw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fsourcemaking.com%2Fdesign_patterns%2Fbuilder\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFbBAqHf5fVyAv7OTBteKuj4ZHqBw&#39;;return true;">https://sourcemaking.com/design_patterns/builder

As I said, I am happy to accept any comments, ideas how to solve it more properly

Thank you again for your time.

середа, 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?

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/5d053a62-1758-4fa2-9766-1eb1c6e6089b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ease patching Django object behavior in another django packages

Sergey Glazyrin
In reply to this post by Tom Forbes
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 (<a href="javascript:" target="_blank" gdf-obfuscated-mailto="TNFh99HGEQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">sergey.gl...@...) wrote:

Hello guys!
I faced a situation when auth backend needs access to request object inside of get_user auth backend function

<a href="https://code.djangoproject.com/ticket/29005" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F29005\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8xJuDV-iA9Bp1bxxifUfmfTq3JQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F29005\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8xJuDV-iA9Bp1bxxifUfmfTq3JQ&#39;;return true;">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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="TNFh99HGEQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-develop...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="TNFh99HGEQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;"> https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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/66604e89-236e-4bb2-935b-41b5ab8cc508%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ease patching Django object behavior in another django packages

Tim Graham-2
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 ([hidden email]) wrote:

Hello guys!
I faced a situation when auth backend needs access to request object inside of get_user auth backend function

<a href="https://code.djangoproject.com/ticket/29005" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F29005\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8xJuDV-iA9Bp1bxxifUfmfTq3JQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F29005\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8xJuDV-iA9Bp1bxxifUfmfTq3JQ&#39;;return true;">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 django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;"> https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ease patching Django object behavior in another django packages

Sergey Glazyrin
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+1 користувач Tim Graham написав:
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] <a href="https://code.djangoproject.com/ticket/25187" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F25187\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEaYBP7z8n24s6B2EdZJU3KaOmQFA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F25187\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEaYBP7z8n24s6B2EdZJU3KaOmQFA&#39;;return true;">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 ([hidden email]) wrote:

Hello guys!
I faced a situation when auth backend needs access to request object inside of get_user auth backend function

<a href="https://code.djangoproject.com/ticket/29005" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F29005\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8xJuDV-iA9Bp1bxxifUfmfTq3JQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F29005\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8xJuDV-iA9Bp1bxxifUfmfTq3JQ&#39;;return true;">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 django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;"> https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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/36c02bfb-fea7-4f29-aef4-546bffc064fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ease patching Django object behavior in another django packages

Sergey Glazyrin
In reply to this post by Tim Graham-2
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 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] <a href="https://code.djangoproject.com/ticket/25187" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F25187\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEaYBP7z8n24s6B2EdZJU3KaOmQFA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F25187\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEaYBP7z8n24s6B2EdZJU3KaOmQFA&#39;;return true;">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 ([hidden email]) wrote:

Hello guys!
I faced a situation when auth backend needs access to request object inside of get_user auth backend function

<a href="https://code.djangoproject.com/ticket/29005" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F29005\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8xJuDV-iA9Bp1bxxifUfmfTq3JQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F29005\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8xJuDV-iA9Bp1bxxifUfmfTq3JQ&#39;;return true;">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 django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;"> https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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/0330b444-af4c-419b-92d1-351bd28d6ffd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ease patching Django object behavior in another django packages

Tom Forbes
In reply to this post by Tim Graham-2
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" <[hidden email]> 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.


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 ([hidden email]) wrote:

Hello guys!
I faced a situation when auth backend needs access to request object inside of get_user auth backend function


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 django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
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.
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 [hidden email].
To post to this group, send email to [hidden email].
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.
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFNZOJNcFuaZqhCdw%2BgywQVSTCKqtStXePDxoPrL4N7ZGrM7mg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ease patching Django object behavior in another django packages

Sergey Glazyrin
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" <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="guLAlA_ZEQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">timog...@...> 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] <a href="https://code.djangoproject.com/ticket/25187" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F25187\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEaYBP7z8n24s6B2EdZJU3KaOmQFA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F25187\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEaYBP7z8n24s6B2EdZJU3KaOmQFA&#39;;return true;">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 ([hidden email]) wrote:

Hello guys!
I faced a situation when auth backend needs access to request object inside of get_user auth backend function

<a href="https://code.djangoproject.com/ticket/29005" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F29005\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8xJuDV-iA9Bp1bxxifUfmfTq3JQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F29005\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8xJuDV-iA9Bp1bxxifUfmfTq3JQ&#39;;return true;">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 django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;"> https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="guLAlA_ZEQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-develop...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="guLAlA_ZEQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/9ae497ad-3c48-4cb9-9122-1b67c5186066%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/9ae497ad-3c48-4cb9-9122-1b67c5186066%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/9ae497ad-3c48-4cb9-9122-1b67c5186066%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/9ae497ad-3c48-4cb9-9122-1b67c5186066%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ease patching Django object behavior in another django packages

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" <[hidden email]> 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" <[hidden email]> 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.


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 ([hidden email]) wrote:

Hello guys!
I faced a situation when auth backend needs access to request object inside of get_user auth backend function


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 django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
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.
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 django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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.

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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFNZOJNnK40z5uqi6bBZvud0JXpZgNN4uZOn-Fx7fyQA4Omr6w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ease patching Django object behavior in another django packages

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" <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="wk-ydBTaEQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">sergey.gl...@...> 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" <[hidden email]> 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] <a href="https://code.djangoproject.com/ticket/25187" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F25187\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEaYBP7z8n24s6B2EdZJU3KaOmQFA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F25187\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEaYBP7z8n24s6B2EdZJU3KaOmQFA&#39;;return true;">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 ([hidden email]) wrote:

Hello guys!
I faced a situation when auth backend needs access to request object inside of get_user auth backend function

<a href="https://code.djangoproject.com/ticket/29005" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F29005\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8xJuDV-iA9Bp1bxxifUfmfTq3JQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F29005\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8xJuDV-iA9Bp1bxxifUfmfTq3JQ&#39;;return true;">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 django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;"> https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/9ae497ad-3c48-4cb9-9122-1b67c5186066%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/9ae497ad-3c48-4cb9-9122-1b67c5186066%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/9ae497ad-3c48-4cb9-9122-1b67c5186066%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/9ae497ad-3c48-4cb9-9122-1b67c5186066%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="wk-ydBTaEQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-develop...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="wk-ydBTaEQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/889705e4-7247-4860-97bd-ee7f0bcbdbc5%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/889705e4-7247-4860-97bd-ee7f0bcbdbc5%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/889705e4-7247-4860-97bd-ee7f0bcbdbc5%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/889705e4-7247-4860-97bd-ee7f0bcbdbc5%40googlegroups.com.

For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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/2d724f4a-438b-4439-ac2c-d2f31e9039bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ease patching Django object behavior in another django packages

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" <[hidden email]> 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" <[hidden email]> 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] <a href="https://code.djangoproject.com/ticket/25187" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F25187\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEaYBP7z8n24s6B2EdZJU3KaOmQFA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F25187\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEaYBP7z8n24s6B2EdZJU3KaOmQFA&#39;;return true;">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 ([hidden email]) wrote:

Hello guys!
I faced a situation when auth backend needs access to request object inside of get_user auth backend function

<a href="https://code.djangoproject.com/ticket/29005" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F29005\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8xJuDV-iA9Bp1bxxifUfmfTq3JQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F29005\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8xJuDV-iA9Bp1bxxifUfmfTq3JQ&#39;;return true;">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 django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;"> https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/9ae497ad-3c48-4cb9-9122-1b67c5186066%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/9ae497ad-3c48-4cb9-9122-1b67c5186066%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/9ae497ad-3c48-4cb9-9122-1b67c5186066%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/9ae497ad-3c48-4cb9-9122-1b67c5186066%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/889705e4-7247-4860-97bd-ee7f0bcbdbc5%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/889705e4-7247-4860-97bd-ee7f0bcbdbc5%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/889705e4-7247-4860-97bd-ee7f0bcbdbc5%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/889705e4-7247-4860-97bd-ee7f0bcbdbc5%40googlegroups.com.

For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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/4c33075d-ecdb-48df-b00c-c53935e1aa48%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: ease patching Django object behavior in another django packages

Sergey Glazyrin
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" <[hidden email]> 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" <[hidden email]> 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] <a href="https://code.djangoproject.com/ticket/25187" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F25187\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEaYBP7z8n24s6B2EdZJU3KaOmQFA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F25187\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEaYBP7z8n24s6B2EdZJU3KaOmQFA&#39;;return true;">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 ([hidden email]) wrote:

Hello guys!
I faced a situation when auth backend needs access to request object inside of get_user auth backend function

<a href="https://code.djangoproject.com/ticket/29005" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F29005\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8xJuDV-iA9Bp1bxxifUfmfTq3JQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F29005\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8xJuDV-iA9Bp1bxxifUfmfTq3JQ&#39;;return true;">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 django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;"> https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/9ae497ad-3c48-4cb9-9122-1b67c5186066%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/9ae497ad-3c48-4cb9-9122-1b67c5186066%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/9ae497ad-3c48-4cb9-9122-1b67c5186066%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/9ae497ad-3c48-4cb9-9122-1b67c5186066%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/889705e4-7247-4860-97bd-ee7f0bcbdbc5%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/889705e4-7247-4860-97bd-ee7f0bcbdbc5%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/889705e4-7247-4860-97bd-ee7f0bcbdbc5%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/889705e4-7247-4860-97bd-ee7f0bcbdbc5%40googlegroups.com.

For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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.