Consider making the scope granularity pluggable

Created on 6 March 2024, 10 months ago

Problem/Motivation

Currently you can set the granularity of a scope to either Permission or Role. It would be nice to have more flexibility for this. Once 📌 Implement the new access policy API Needs work lands in core it will become easier to provide custom access control schemes. If this "granularity" were pluggable it would be possible to then properly connect a custom access policy with external consumers. Even now it's conceivable to want to have scopes that, for example, relate to a specific Group . This is currently quite difficult to implement, and would be much easier with this.

Proposed resolution

Turn the two hardcoded "granularities" into a a plugin system. Not sure if it makes sense to stick to the term "granularity" then or if something like "scope access plugin" is more appropriate then. For the functionality of the actual plugins would be to implement something like hasPermission() for Oauth2ScopeProvider::scopeHasPermission() to call.

Remaining tasks

Decide if this is worth pursuing.

User interface changes

?

API changes

?

Data model changes

?

Feature request
Status

Active

Version

6.0

Component

Code

Created by

🇩🇪Germany tstoeckler Essen, Germany

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @tstoeckler
  • 🇩🇪Germany tstoeckler Essen, Germany

    I would be willing to try to implement this, but wanted to check first, whether this is something that's considered desirable since it may serve somewhat of a niche use-case. On the other hand this does get rid of a couple if-else constructs in favor of a (what I would consider "proper") plugin system, but while I think that's a good trade-off in its own right, it's not my decision to make. So would love some thoughts on this, thanks!

  • 🇳🇱Netherlands bojan_dev

    I do believe it would be an improvement to make the granularity pluggable, I can imagine simple_oauth would be able to serve more use cases this way. The naming (granularity) is also a valid point. I would go for it.

    Unit tests would be a must for this to land.

  • 🇩🇪Germany tstoeckler Essen, Germany

    Awesome, thanks for the endorsement, will try to cook something up. Yeah makes sense with the test coverage 👍

  • Pipeline finished with Failed
    8 days ago
    Total: 243s
    #364156
  • 🇩🇪Germany tstoeckler Essen, Germany

    Alrighty, took a bit longer than I hoped to get back to this, but here we go. I went ahead and implemented this as described in the issue summary.

    First off, I want to shout out the great test coverage of this module. I had tested that everything works locally already, but the tests caught a bunch of errors and edge cases that were broken. Really nice work!

    The MR is "finished" in the sense that it works, tests pass and I converted all code to the new structure. I did not yet add a specific test of the new plugin functionality. I.e. my thinking is to create a test module with a test granularity plugin and then test that Oauth2ScopeProvider::scopeHasPermission() returns the correct things. But I thought it makes sense to start discussing the actual implementation first at this point. I tried to make the code feel "at home" in the current codebase as much as possible, but there are bunch of things that are arguable, I will do a self-review on Gitlab to maybe kick off some discussion points. But of course input on any parts of the MR is much appreciated.

  • Pipeline finished with Success
    8 days ago
    Total: 226s
    #364347
  • Pipeline finished with Success
    8 days ago
    Total: 386s
    #364359
  • 🇩🇪Germany tstoeckler Essen, Germany

    Speaking of excellent test coverage... I had forgotten to run the simple_oauth_static_scope tests locally. That actually revealed a couple of nice bugs, as well, as I had only tested it with dynamic scopes locally 👍

    Also fixed PHPCS and PHPStan violations. As I had opted to change the configuration structure for static scopes, as well, and add a deprecation for the now-legacy format, that required me to write a draft change notice so I did that for now. All of this is of course up to debate, worst case we can delete the change notice without publishing it I guess.

    As far as I can tell the "cspell" and the "phpunit (next minor)" failures are not related to this MR, so ignoring those for now.

    ...and now actually did the self-review as promised.

  • 🇩🇪Germany tstoeckler Essen, Germany

    Added a kernel test that tests the scope granularity permission handling and a functional test (which has to be a Javascript test because of the Ajax stuff) for the scope granularity form. Let me know if there's anything else you would like to see tested in particular.

  • Pipeline finished with Success
    7 days ago
    Total: 315s
    #365539
  • 🇳🇱Netherlands bojan_dev

    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.

  • 🇩🇪Germany tstoeckler Essen, Germany

    Thanks for the kind words, that's really nice to hear. No worries, that's how it goes, as you saw it also took me quite a while to get back to this.

  • Pipeline finished with Success
    6 days ago
    Total: 228s
    #366541
  • Pipeline finished with Success
    2 days ago
    Total: 308s
    #369825
Production build 0.71.5 2024