Stop auto-creation of AccessGrant when a matching token is found if custom access token attributes are used #1660
Conversation
|
@nbulaj if you could review when you have time please 🙏 |
|
@nbulaj I've done some refactoring. Let me know what you think. |
|
@PhilippeChab sorry for the slow response - I've had a look at the changes you're suggesting and the issue you logged and I can try to make some changes. I just can't promise when I'll be able to get to it though, my hands are a bit full at the moment. |
There was a problem hiding this comment.
@PhilippeChab I've pushed some changes which I think should handle the scenario you mentioned. Let me know what you think.
cc @nbulaj
| @@ -65,6 +67,13 @@ def form_post_response? | |||
| response_mode == "form_post" | |||
| end | |||
|
|
|||
| def load_custom_attributes_from_token(matching_token) | |||
There was a problem hiding this comment.
Why do we override the custom attributes sent in the request by the ones in the token?
There was a problem hiding this comment.
See my response here.
Also, I think it would be incorrect usage to send that custom attributes in the params here (like you mentioned). This only gets called from AuthorizationsController#new, and since I've changed can_authorize_response? to always return false if custom attributes are used, this will always either render errors, or :new. In other words, if we did find a matching token (regardless of whether we matched the custom attributes or not), this would still only render :new and never do anything with that token - so there isn't any risk of a token being auto-created with another token's custom attributes.
There was a problem hiding this comment.
I think the link is not pointing to the correct reference, but as I said in the other thread, I think this is something that you should handle on your end and not in doorkeeper directly.
|
Hey @JeremyC-za . What is the state of this PR? Do we need to do more work on it? |
|
Hey @nbulaj, it's almost ready. There are a couple things I want to look into (which may not end up needing code changes), I just haven't been able to find the time lately. I intend on getting to it by the end of next week though. |
There was a problem hiding this comment.
@PhilippeChab I've responded to your comments, let me know what you think.
@nbulaj In my opinion this is ready to be reviewed and hopefully merged. Thanks.
| @@ -65,6 +67,13 @@ def form_post_response? | |||
| response_mode == "form_post" | |||
| end | |||
|
|
|||
| def load_custom_attributes_from_token(matching_token) | |||
There was a problem hiding this comment.
See my response here.
Also, I think it would be incorrect usage to send that custom attributes in the params here (like you mentioned). This only gets called from AuthorizationsController#new, and since I've changed can_authorize_response? to always return false if custom attributes are used, this will always either render errors, or :new. In other words, if we did find a matching token (regardless of whether we matched the custom attributes or not), this would still only render :new and never do anything with that token - so there isn't any risk of a token being auto-created with another token's custom attributes.
|
@nbulaj would it be possible for you to review this? |
|
@nbulaj @PhilippeChab Apologies for the radio silence. I've pushed a change so the custom attributes are no longer copied into the access grant automatically when a matching token is found (as per this conversation). I think that was all that was todo, but let me know if I've missed something. A recap of what this PR includes at this point in time:
|
|
@JeremyC-za can I ask you please to squash the commits and add a changelog entry? 🙏 Thanks! |
fixes doorkeeper-gem#1665), and introduces `revoke_previous_client_credentials_token` config option.
JeremyC-za
force-pushed
the
custom_attributes_multitenancy_patch
branch
from
42d9489
to
58f68b4
Compare
|
@nbulaj done 👍🏻 |
|
Thanks a lot @JeremyC-za @PhilippeChab |
Summary
There are two changes in this PR, discussed in more detail below:
custom_access_token_attributesare used.revoke_previous_authorization_code_tokento mirrorrevoke_previous_client_credentials_token.Change 1:
What happens currently is that when you authorize an application, and you already have a valid access token (not expired or revoked) for that application, then a new access grant is created immediately. This happens in
AuthorizationsController#render_success, which checks formatching_token?and then callsauthorize_response, which creates the new grant.This is a problem if
custom_access_token_attributesare used, since those attributes from the existing token aren't copied into the new grant. In my case, I need to display the custom attributes (tenant ids) from the existing token so I can allow the user to edit them if necessary before the new access grant is created. I did this by loading the custom attributes from the existing token into the@pre_authobject, which is the accessible in the view, and can be used as needed.I also needed the existing token to be revoked once a token is generated from the new access grant, which leads to the next change.
Change 2:
We already have a config option
revoke_previous_client_credentials_token. That's only available for theclient_credentialsgrant type though. I need the same behaviour for theauthorization_codegrant type, so I've added another config option for it.There is a TODO to make
revoke_previous_client_credentials_tokenmore generic for the other flows, but I don't really understand the other ones and I just need this grant type, so I opted add a new config option rather than refactor the existing one.