Thank you for pointing this out. As you already guessed, the problem is upstream in the simple_oauth module and has just been fixed.
General compatibility with the new oauth2-server is available since v2.1.0 of this module.
By also updating to the latest version of simple_oauth the scopes should be properly set on refreshed access tokens.
chfoidl → made their first commit to this issue’s fork.
Thank you for your contribution!
Compatibility is is ensured in v2.1.0.
Fixed in 2.1.0-rc7
That's a good point. The reason I did not implement it directly was because I was not 100% certain if the AccessCheck is never cached, because if it is, the access check would return false results.
If you can assure that the AccessCheck is never cached, the logic can be moved to the AccessCheck.
Fixed in 1.0.2
Thank you @bojan_dev for looking into this and for pointing out various improvements.
The MR was updated accordingly.
In regards to testing it is indeed very difficult because this issue only happens when simultaneous requests are handled by different PHP threads, as is the case when using e.g. PHP-FPM.
Unfortunately the built-in PHP web server seems to handle requests sequentially, therefore this issue never happens.
However passing all existing tests show that the changes do not break existing behavior.
What I have done is manually apply the changes to a local Drupal installation using DDEV and running the script from the issue description to make sure the locking works as intended.
Added in 1.1.0
Fixed in 1.1.0
Fixed in 1.0.4
Fixed in 2.0.0
Fixed in 1.0.6
Fixed in 1.1.1
Fixed in 2.0.0-rc4
Thanks for pointing this out.
Removing the use of the AutoconfigureTag Attribute fixes the issue.
Fixed in 1.0.2
The issue is fixed in 2.0.0-rc5
Thank you for pointing this out!
I was under the false impression that we can safely use the #[AutoconfigureTag] attribute from symfony, but unfortunately this is not the case. Use of this tag requires the symfony/config dependency.
The fix is to manually specify the service tag in the yaml file.
Fixed in 1.0.1
chfoidl → created an issue. See original summary → .
Fixed in 1.1.0
Thank you for pointing out this issue.
The intl extension is now optional and if it is not loaded the validations requiring it are not loaded.
All changes are implemented in version 1.0.3
In case anyone needs this for the current 6.0.0-beta8, attached is a patch file with the backported merge request changes.
Thank you all for your contributions!
I did create version 2 that adds support for Drupal11 and PHP 8.4, but also drops support for Drupal 9.
Feel free to upgrade to version 2.0.0 to get Drupal 11 support!
chfoidl → changed the visibility of the branch 3498190-refresh-token-grant to hidden.
@p-neyens Thank you for your contribution!
The issue is fixed in version 1.0.2!
Better formatted issue
Fixed in 2.x
@bramdriesen Thank you for reviewing this issue and pointing out the problems.
Yeah it seems like this is AI-generated and the contribution isn't at all related to the issue.
However, the activity on this issue motivated me to quickly fix it myself ;-)
Support for Verification API 2.x has been added in the 2.x branch!
Hi @grasmash!
Thank you for your contribution.
I made some additional tweaks to your code:
- Added unique error code for each flood block response.
- Updated tests
I just tried removing jooplan as a maintainer from the project, but the page displays the user status as locked
The `AdvancedUserRegistrationResource` now supports a custom HTTP Header to disable E-Mail notifications.
See https://git.drupalcode.org/project/user_api/-/commit/3ea71fd23a26aeb8dc4...
@anybody The flood_control contrib module provides just the UI portion for the Drupal Core flood module's functionality.
Configuration of attempt count and expiry window is already part of Drupal Core, but there is no native UI for configuring those parameters.
The flood_control contrib module does not need change anything to support any other module using the flood system. The unblock form supports any event registered via the core flood service, so it naturally works with the magic_code module as well.
Right now there is no UI to configure the attempt count and expiry window specific to the magic_code module. If you want to configure it right now, you have to set those parameters in settings.php, but it would definetly make sense to expand on the flood_control configuration form to allow configuration of this module's flood settings.