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.
If there are no scopes requested and no scopes are set on the consumer with the client credentials, in 5.2 it will fallback on the default user (set on the consumer), with 6.0 you won't have any access. We definitely need to address this in 6.0, I think we should grant all scopes that support client credentials if no scopes are set on the request and consumer.
Regarding the tiny module, it would be interesting to have some testing/debug submodule available that does this. I would be open to add this to the module.
bojan_dev → made their first commit to this issue’s fork.
Can somebody please review MR164?
The password credentials grant is no longer supported in 6.0, see:
https://www.drupal.org/node/3315400 →
Did you mean simple_oauth 5.2?
I like the simplistic implementation from @kingdutch, so I have used that as base and made it configurable.
The MR 164 covers the following:
- Invalidate tokens by specific actions (multiple can be selected) via settings.
- Available actions can be altered by swapping out/decorating ```TokenExpiryTriggerHandler` service``` + ```Oauth2TokenSettingsForm```.
- Default actions are set so we don't introduce BC.
Todo: add test coverage.
TY!
bojan_dev → made their first commit to this issue’s fork.
Nice work idebr! I merged the one which fixes the cspell job.
I went ahead and made the default scopes limit the allowed scopes per consumer. Can somebody please review?
I have no feedback, the implementation looks great, you have thought well about the upgrade path, merged ;)
Yea it's still a milestone of 9 (https://github.com/thephpleague/oauth2-server/milestone/9), postponing the issue for now.
Please address the phpcs issues on the MR.
This is a valid point, we should definitely reintroduce this feature. The question is how? We could add an extra responsibility on the default scopes, so it limits the scopes per consumer or we can introduce an additional field where we can specify allowed scopes. I’m open for suggestions.
Looks good, thanks!
bojan_dev → made their first commit to this issue’s fork.
Nice work @dieterholvoet!
TY!
Looks good, TY!
I had a quick peek and let me first say that it is great work what you did here @tstoeckler. Unfortunately I jammed with work, so an extensive review I can't give in the short term. Any dev's that what to speed up the process, feel free to review.
Looks good!
I agree with @kingdutch points, we shouldn't change the default behavior for invalidating the tokens and I rather not introduce a new major version on the 5.x. For 6.0.x on the other hand we are still in beta release and there is more active development, we could introduce a new token invalidation behavior there. The question is if this (token invalidation) change benefits a larger target group, I believe it does, so I would propose making the token invalidation configurable via config settings per case (password change, account blocked, roles change).
I guess in the README.md.
Closing due to lack of activity.
Closing due to lack of activity.
Closing due to lack of activity.
Closing due to lack of activity.
Nice catch!
Could be related to:
🐛
"Reference" must be defined in MODULE_NAME.field_type_categories.yml in assert() (line 183 of /var/www/html/web/core/lib/Drupal/Core/Field/FieldTypePluginManager.php)
Needs review
.
In any case if you can't reproduce it on 6.0.x, there is nothing to fix.
Looks good to me, TY!
bojan_dev → changed the visibility of the branch 3484623-the-autocomplete-routeendpoint to hidden.
bojan_dev → created an issue.
Nice work!
TY!
Great work @manojsaha! TY for contributing.
bojan_dev → made their first commit to this issue’s fork.
Authenticated request are by default not cachable (coupled or decoupled). You could try enabling "Dynamic Page Cache" module, it caches pages minus the personalized parts (both anonymous & authenticated). If you want to leverage a reverse-proxy you could take a look on https://www.drupal.org/project/adv_varnish → .
TY for contributing,
TY!
Done
Remaining task (for 5.2.x): copy the Kernel tests from MR !66 to !64.
Looks good, TY!
Looks good, TY @idebr!
See comments from bradjones1: #6, #8 and #23.
I'm pretty jammed with work, so anyone able to write tests will be welcome.
I'm happy to merge it, but the MR's are still missing test coverage, so feel free to contribute.
bojan_dev → created an issue.
bojan_dev → created an issue.
The project page and README.md does mention that it uses the PHP library "OAuth 2.0 Server". Also installing modules via composer is the recommended way, the following quote covers it:
The recommended way of adding a module is with Composer, especially for modules that have dependencies. Several modules will just not work if you only add the zip / tar.gz file.
Source: https://www.drupal.org/docs/extending-drupal/installing-modules#s-severa... →
https://git.drupalcode.org/project/simple_oauth/-/merge_requests/99.diff applies on 6.0.x.
Added setting/kill switch as suggested, please review.
bojan_dev → made their first commit to this issue’s fork.
Found related issue:
✨
Allow to index empty fields
Active
I will try to build the kill switch and contribute in the other issue.
I think to properly check whether the row might have the property in question, you will always need to load the entity
I rather find a solution to not load entities, this makes even more sense when using Search API Solr, where you actually want to only use Solr instead of DB queries.
I also don’t quite understand your use case, to be honest. If your view only lists that single field, why include nodes that don’t have it at all? Why not add a “associated reference field: not empty” filter to the view?
For example imagine a specific CT that has tags or a category and you want to display the taxonomy label it in the search results. I don't want to add that filter because that would mean I won't get other CT's in the search. You need to see it as search results that for one or more CT's has more info to show.
bojan_dev → created an issue.
This was already resolved in 6.0.x, thanks for the MR.
This will be resolved in 📌 Auth revoke on profile update Needs work