Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Improve BackendApplicationClient class #603

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
DiegoQueiroz opened this issue Oct 18, 2018 · 4 comments
Closed

Improve BackendApplicationClient class #603

DiegoQueiroz opened this issue Oct 18, 2018 · 4 comments
Labels
Bug OAuth2-Client This impact the client part of OAuth2.
Milestone

Comments

@DiegoQueiroz
Copy link

Describe the feature

In BackendApplicationClient class, the client_id, scope, and **kwargs parameters passed to the constructor are useless. Notice that even client_id being mandatory, it is not used at all (it is only stored). The **kwargs parameter, on the other hand, is completely ignored.

The prepare_request_body method overrides scope and ignores the one passed to the constructor. The same happens to **kwargs. This forces me to pass client_id/scope/**kwargs twice (actually, only once, since I can pass anything to the constructor, the result will be the same).

Additional context

My suggestion is to override the constructor in the BackendApplicationClient subclass with this code (or something similar):

from __future__ import absolute_import, unicode_literals

from ..parameters import parse_token_response, prepare_token_request
from oauthlib.common import generate_token
from .base import Client, AUTH_HEADER

class BackendApplicationClient(Client):
    def __init__(self, client_id,
                 default_token_placement=AUTH_HEADER,
                 token_type='Bearer',
                 access_token=None,
                 refresh_token=None,
                 mac_key=None,
                 mac_algorithm=None,
                 token=None,
                 scope=None,
                 state=None,
                 redirect_url=None,
                 state_generator=generate_token,
                 **kwargs):
        # forward parameters to super class
        super(BackendApplicationClient, self).__init__(client_id,
                 default_token_placement,
                 token_type,
                 access_token,
                 refresh_token,
                 mac_key,
                 mac_algorithm,
                 token,
                 scope,
                 state,
                 redirect_url,
                 state_generator,
                 **kwargs)
        # store kwargs (client_id and scope are already stored by super class method)
        # better still would be to add this piece of code directly in the `Client` superclass
        self.kwargs = kwargs

    def prepare_request_body(self, body='', scope=None, **kwargs):
        if scope is None:
            # no new scope provided, use the class scope
            scope = self.scope
        if not kwargs:
            # empty kwargs, use class kwargs
            kwargs = self.kwargs
        if self.client_id and 'client_id' not in kwargs:
            # kwargs does not contains client_id but the class has one, add it
            kwargs['client_id'] = self.client_id
        return prepare_token_request('client_credentials', body=body,
                                     scope=scope, **kwargs)

This way, the parameters passed to the constructor are used for something, while we keep compatibility with existing code.

@JonathanHuot
Copy link
Member

JonathanHuot commented Oct 18, 2018

Hi! Yes you're right, kwargs in constructor is not used. However the way client_id is handled has a bit changed recently (see #593).

Had you got a chance to look at master and see if it fits your needs ?

PS: I am in favor of cleaning those parts and the way kwargs / object args are used, because as you mentionned, that's counter-intuitive and not identical for all Client parent classes.

@DiegoQueiroz
Copy link
Author

DiegoQueiroz commented Oct 18, 2018

You were right, I hadn't look at master. My fault.

I found the recent changes and they address in some way my concerns, but they still have problems, particularly in BackendApplicationClient.

In other classes client_id was deprecated (eg. WebApplicationClient). This is good, but inconsistent with other classes (eg. BackendApplicationClient). Also, include_client_id is ignored.

I don't know if there is a rational behind this, but it seems that BackendApplicationClient may follow WebApplicationClient behavior. Maybe the real intention was that BackendApplicationClient be a subclass of WebApplicationClient?

In addition, the same treatment given to code in WebApplicationClient could be given to scope in BackendApplicationClient (I mean scope = scope or self.scope).

**kwargs is less problematic, but I feel it could be forwarded as well (maybe with include_kwargs parameter, or something).

@JonathanHuot
Copy link
Member

Hi @DiegoQueiroz, thanks for the research! a PR increasing the consistency between classes would be greatly appreciated !

Adding a new arg/parameter (e.g. include_kwargs) seems too overkill/or unnecessary, though.

@JonathanHuot
Copy link
Member

I think the immediate concern was fixed in #682 and the handling of kwargs is left. However the kwargs applies to other part of the code, not only BackendApplicationClient.

If someone would like to start a PR/issue with an API changes proposal regarding the kwargs, please do so ! :)

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug OAuth2-Client This impact the client part of OAuth2.
Projects
None yet
Development

No branches or pull requests

2 participants