Skip to content
New issue

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

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

Already on GitHub? # to your account

fix(authorization): authorization url encoding #3062

Merged
merged 3 commits into from
Nov 27, 2024

Conversation

hassan254-prog
Copy link
Contributor

Describe the problem and your solution

Turns out some of the providers don't like it when we encode some of the url parts, i.e scopes, base_url when we are interpolating with connectionConfigs. To help with this, the PR introduces a way we can handle this within the various parts. Currently we can skip authorization_url encoding within the scopes, or when interpolating the base_url with connectionConfig.

Testing instructions

When creating a new connection for Pennylane, the scopes aren't encoded customer_invoices+supplier_invoices+ledger+accounting

Copy link

linear bot commented Nov 26, 2024

@hassan254-prog hassan254-prog changed the title fix(authorization): encoding for scopes fix(authorization): authorization url encoding Nov 26, 2024
@hassan254-prog hassan254-prog self-assigned this Nov 26, 2024
@hassan254-prog hassan254-prog requested a review from a team November 26, 2024 09:41
Copy link
Collaborator

@bodinsamuel bodinsamuel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👌🏻

let authorizationUri = simpleOAuthClient.authorizeURL({
redirect_uri: callbackUrl,
scope: providerConfig.oauth_scopes ? providerConfig.oauth_scopes.split(',').join(provider.scope_separator || ' ') : '',
scope: scopes,
state: session.id,
...allAuthParams
});
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be easier at some point to not use authorizeURL and just iterate over the query params

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Directly manipulating query parameters provides for a more controlled approach.

Copy link
Collaborator

@TBonnin TBonnin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have the feeling that continuing to add more and more parameters to providers.yaml is going to haunt us at some point but this PR solves an immediate problem so go for it

newQuery = newQuery ? `${newQuery}&scope=${scopes}` : `scope=${scopes}`;
}
url.search = newQuery;
authorizationUri = url.toString();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can this be simplified like this?

    const url = new URL(authorizationUri);
    url.searchParams.delete('scope');
    if (scopes) {
        url.searchParams.set('scope', scopes);
    }
    authorizationUri = url.toString();

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the simplification works functionally, but it will still URL-encode the scopes value.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤦 nvm then

@@ -4469,6 +4470,8 @@ pennylane:
grant_type: authorization_code
refresh_params:
grant_type: refresh_token
authorization_url_skip_encode:
- scopes
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would personally prefer to bundle it with the authorization_url or token_url attributes. Something like:

authorization_url: 
   url: https://app.pennylane.com/oauth/authorize
   skip_encode: scopes

but it would require changing the type of an existing attributes 😓

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. I'm not sure, but to me, this might be the best time to clean up and bundle all related fields together for both authorization_url and token_url. Currently, we have loosely grouped fields for authorization_url, such as:

authorization_url_replacements
authorization_url_fragment

Bundling them together would make the providers.yaml file cleaner. @TBonnin what do you think?

Copy link
Collaborator

@TBonnin TBonnin Nov 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

grouping them together would make sense. Not in this PR of course. Maybe adding an

authorization:
    url: ...
    url_replacements:...
    ...

and same thing with token. We would need to ensure backward compatibilities though. 😓

@hassan254-prog hassan254-prog enabled auto-merge (squash) November 27, 2024 05:52
@hassan254-prog hassan254-prog merged commit 57bac9a into master Nov 27, 2024
20 checks passed
@hassan254-prog hassan254-prog deleted the kelvinwari/ext-258-investigate-on-pennylane branch November 27, 2024 05:57
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants