Oke check, then just replace the assertion to the interface. Can you please provide a MR for this?
TY for the patch.
bojan_dev → made their first commit to this issue’s fork.
Is this a custom decorator? If it's the decorator of the RoleStorage, I would assume that it implements the RoleStorageInterface
, it would then suffice todo the assertion base on the interface instead.
@justafish thank you for reporting and the MR.
Alright in that case, if the community can do the heavy lifting, I'm willing to review/merge D11 support for 5.2. Please make a MR available.
Unfortunately it will be more work to maintain two versions with different architectures, also the other maintainers are no longer active. I rather not introduces any new features to 5.2.x or add D11 support, which would mean support will be extended.
Perhaps you can explain your issue with Next.js, maybe I can help.
Thank you @dunjincan for reporting and providing a patch, I have updated the associated unit tests, because there were breaking due to this change.
bojan_dev → made their first commit to this issue’s fork.
Thanks all for the work on this! @bojan_dev Any preference for type of test/where? I believe just test coverage that saving AccountInterface or ConsumerInterface triggers the token deletion right, but the idea that a service can be overridden would not need testing, is that your expectation?
There is a new service introduced TokenExpiryTriggerHandler
, all the methods need to have test coverage, checking if they are triggered on specific events and have the right parameters. For example: handleConsumerUpdate()
is triggered on consumer update and provides the associated consumer object.
Thank you coffeemakr for reporting and and making a fork available. I have compared the logic with dynamic scopes and I can confirm that this is inconsistent behaviour with static scopes. I have updated fork to still leverage the getInstances method, due the fact it has logic when not providing ids. Could you please make a MR available next time, it was not clear for me if there was a fix available.
bojan_dev → made their first commit to this issue’s fork.
I tested how Basic Auth does this, and a non existing URL will get 404 even if the credentials are incorrect, so I think it's a valid point. Please review the MR !185, it does not apply OAuth2 anymore if the URL is not valid.
bojan_dev → made their first commit to this issue’s fork.
Could you please make a MR or patch?
The feature request makes sense, also the MR looks good to me, nice work tstoeckler!
bojan_dev → made their first commit to this issue’s fork.
I agree with coffeemkr, this is the original issue so lets keep it, also the MR in the cloned issue has more phpcs issues.
TY for contributing.
You could use the /oauth/debug
endpoint to retrieve the roles from the authenticated user based on the token.
Patch from coffeemakr looks good, the MR has many file changes also the MR description is from a different issue. I think your fork is outdated.
Created issue on solarium repo: https://github.com/solariumphp/solarium/issues/1156
Looks good to me, TY!
Hi Taras,
Nice work! Looks good to me, the tests that fail are indeed unrelated.
Perhaps we should remove the simple_oauth_update_8604
, like I said before it's a migration from old scopes (roles) to the new scope entity, which perhaps doesn't cover all different cases. A manual migration/configuration is the safest way to upgrade from 5.2 to 6.0.
Hi Bram,
Thanks for the clear explanation of the feature request.
I agree that this would be a valuable feature for the community, also the suggested opt-out mechanism would not introduce any BC and its implementation is pretty straightforward.
So I would say go for it and I would be happy to review any contribution on this feature.
Oke this is my take on this long discussion:
The goal of this issue is to have the ability to revoke tokens in specific cases. The only 2 options that I see that could potentially land to resolve the issue are MR138 and MR164. Both MR’s are comparable; the only difference is that 164 introduces a config layer which makes it easier for the community to configure the obvious cases mentioned in this issue (without having to write code) and optionally can of course enrich it by themselves. I don’t see the maintenance burden as mentioned, as it’s not a complex implementation.
I'm pretty much up for both MR’s, the only thing that is holding me back to merge MR138: it’s missing test coverage.
I find it not clear how to reproduce your issue, so it's hard for me to figure this one out. The hook_update: simple_oauth_update_8604
tries to migrate existing (old) scope settings from your consumers to the new dynamic scopes, so if this didn't work you could always just manually configure your dynamic scopes and consumers.
The password grant is no longer supported in simple_oauth 6.0, due the following reasons: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#s...
But you could checkout this module: https://www.drupal.org/project/simple_oauth_password_grant →
I think we should add some extra checks in that hook:
- If role is not NULL.
- If scope already exists.
- If scopes are already referenced on the associated consumer.
This way we can rerun the hook_update.
Could you please check on which line the id()
is giving null
?
@grasmash did you run drush updb
? If the config setting invalidate_tokens
is giving NULL back, it probably did not run the simple_oauth_update_10001
hook_update.
We could filter those unchecked values (on submit), to make the array cleaner when retrieving values from the invalidate_tokens
.
It appears the following change in thephpleague/oauth2-server is the reason for the BC: https://github.com/thephpleague/oauth2-server/pull/1094.
finalizeScopes
is now being called in the RefreshTokenGrant, which does not set the $userIdentifier
, this means that no scopes are being returned. This has impact on all grant types that support refresh tokens. Sorry that I missed this, also I have read your comments @m.stenta on
🌱
Move to thephpleague/oauth2-server 9.0
Active
, those are valid points I will definitely make a major version release next time.
Merging MR !176 and will roll out a new stable release.
I was assuming you were only using the grant types that are provided by simple_oauth, based on that assumption that would mean that only the Authorization code grant type supports refresh tokens. But I see you are using the Password grant, which is not supported by simple_oauth: 6.0 due to the following reason: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#s...
You could take a look in 5.2 which still supports the password grant.
@skyejohnson no, the community can review it as well, so if you have the time please take a look.
@drunken monkey thank you for you input and you have some valid points, I could just create a custom plugin extend the "search_api_solr_suggester" and make those adjustment like you said. But trimming by default spaces in the "search_api_solr_suggester" plugin feels to me like the query is specific for some Solr lookup implementations, vs just allowing spaces and having the query to the Solr suggester raw as possible.
If you still find this an edge case, we can close both issue's and I will do a project specific implementation for it.
bojan_dev → created an issue.
bojan_dev → created an issue.
Do you mean it's missing from /oauth/userinfo
route/endpoint?
Did you try to update to beta10?
Take a look on the following KernelTest, which illustrates how to retrieve user info from a token: https://git.drupalcode.org/project/simple_oauth/-/blob/6.0.0-beta10/test...
Closing issue because simple_oauth 8.x-4.x is EOL.
I can't reproduce this, it's not possible to refresh the token for any grant type, it is only applicable for the "Authorization Code".
Can you please provide more info about the configured consumer, scope and authorize request?
By the way: please don't set the issue status to reviewed, a peer review should not be done on your own work.
I agree with e0ipso this hook_alter comes from anonymous_login and makes no sense for people that don't use the anonymous_login module. That hook should be documented in the anonymous_login, for people that use both simple_oauth + anonymous_login modules.
Issue is outdated, if error is still occurring feel free to reopen.
Logging has been improved in: 📌 Reduce logging severity/don't log expired tokens/401s Needs review
In 6.0 we migrate some tests to Kernel tests, but some are still needed in browser, e.g: when dealing with Authorization Code Grant there is a case where a grant form is presented in the authorization flow.
No activity for a long period, closing issue for now.
Logging has been improved in: 📌 Reduce logging severity/don't log expired tokens/401s Needs review
Closing issue due the fact 8.x-4.x is EOL.
No activity for a long period on this issue, closing it for now.
There is for a long period no activity on this feature request, closing it for now.
Closing issue: task is pretty old and no patch was provided.
Closing issue due the fact that D7 is EOL.
@skyejohnson I made a new release for this composer fix 6.0.0-beta10
, so you should be able to do a regular update (without patching), "drupal/simple_oauth": "^6.0"
should be set as requirement in your project composer.json.
I wonder if we really need that dependency specified, because it's already a dependency in: steverhoades/oauth2-openid-connect-server, see: https://github.com/steverhoades/oauth2-openid-connect-server/blob/v3.0.1....
composer update drupal/simple_oauth -W
should do the trick or am I missing something?
You need to update simple_oauth with dependencies, thephpleague/oauth2-server needs to be 9.2, for more info see: 🌱 Move to thephpleague/oauth2-server 9.0 Active and https://git.drupalcode.org/project/simple_oauth/-/jobs/4456948.
How did you verify that the tokens are invalided for those specific entity updates?
In hook simple_oauth_entity_update
the tokens get deleted if the consumer or user entity get's updated. In
📌
Auth revoke on profile update
Needs work
we are trying to improve this logic with configurations.
Thanks for reviewing/testing @tstoeckler!
bojan_dev → created an issue.
bojan_dev → created an issue. See original summary → .
Looks good, merged!
TY, merged!
Nice work!
bojan_dev → created an issue.
This can only occur if the config "simple_oauth.settings" or the setting inside "token_cron_batch_size" isn't available. I wouldn't make the limit argument nullable, I rather see it addressed in the if statement on simple_oauth.module:30
.
Yea had the fix also embedded in #3495325, but having a separate issue/commit is better.
If this still is occuring on the latest version, feel free to reopen the issue, closing it for now.
Could please give more info about the steps how to reproduce this.
Still missing test coverage for this specific case.
Nice work! Merged!
Thanks for sharing this @chfoidl, I dropped some comments and I wonder if it's even possible to have test coverage for this.
To be in line with the OAuth2 spec: https://datatracker.ietf.org/doc/html/rfc6749#section-3.3
I have made the token endpoint require the token scope parameter when there is no default scopes available on the client/consumer when dealing with the client_credentials.
Could you please review my last commit?
bojan_dev → created an issue.