This is supported by the League server library yet we need to make clients configurable to utilize this option. I have done most of the work on my end with a client project and will update here with a patch shortly.
| Comment | File | Size | Author |
|---|---|---|---|
| #27 | interdiff-25-27.txt | 3.67 KB | olafkarsten |
| #27 | 3027432-27-pkce.patch | 14.42 KB | olafkarsten |
| #25 | interdiff-24-25.txt | 799 bytes | olafkarsten |
| #25 | 3027432-25-pkce.patch | 11.22 KB | olafkarsten |
| #24 | 3027432-24-pkce.patch | 11.43 KB | olafkarsten |
Comments
Comment #2
bradjones1See attached.
I ended up changing the signature of
Oauth2GrantManager::getAuthorizationServer()to take the Consumer entity, as well, however it can take a NULL in an effort to not break BC on any customized integrations. I'm open to thoughts on how this could be avoided, especially since this means the PKCE-related changes bleed from the extras submodule into the main module, however it does not create a dependency on extras.In 2 of the 3 calls to
::getAuthorizationServer()the client is already loaded, and I don't believe adding it to the token controller adds any notable overhead or complexity.This also requires 7.x of the league library, a patch for which is at #2977127: Update league/oauth2-server to 7.1.x to incorporate the PKCE-related items released in 7.0.0.
Comment #3
e0ipsoThanks for the patch! I left some considerations, please let me know what you think.
Why are we losing this?
Is there any other benefit to introduce the entity storage service? We can already do this with the currently injected dependencies. If there is no additional benefit, I'd rather keep the original code.
As I understand, this is the main goal of the change in this file. Would your patch work if we only had this change in this file?
Let's use the entity manager to get the storage to load entities by UUID. This way we can avoid the additional dependency on the
entity.repositoryservice.Comment #4
e0ipsoComment #5
bradjones1Updated per above.
I backed out the addition of the entity repository; agreed it's not really a substantive change.
I removed the try/catch on loading the entity storage handler for the consumer since we can be confident it exists due to our dependency on consumers module in the main module, and it seems like that's an unlikely failure point on which we need to specifically react. The actual failure condition is that of not having a valid client ID specified/client loaded, which is what we're now targeting with error handling.
Also see updated patch on the upstream library bump issue, linked above.
Comment #6
bradjones1Not triggering a test since it depends on the other patch so we know it will fail.
Comment #7
bradjones1Comment #8
bradjones1Cleaning up some unused references.
Comment #9
bradjones1Comment #10
e0ipsoWhy did you drop the error handling here? This was useful for static code analysis and in case some nasty overwrite was in place.
Comment #11
e0ipsoLet's extract some booleans before hand so we can make the
ifstatement more readable.Comment #12
e0ipsoWe probably want that awkward error handling here as well.
This patch is pretty impressive! Thanks for the work. As far as I can tell we are only missing 2 things before merging:
simple_oauth.installfile should have examples of this.Again, I'm so grateful to get patches with such great quality work.
Comment #13
bradjones1Thanks for the review. I'll make some changes this week.
Regarding the question regarding the error handling on getting the entity storage, I'll just point to my note on the original patch... I haven't found it common practice to put this kind of thing in a try-catch if your dependency is sufficient to require the existence of the entity type. E.g., Commerce loads entities from other modules all the time and doesn't wrap these in a try-catch. If someone has overridden their codebase in such a way that the consumer entity storage doesn't load, this exception will still bubble up and is probably more meaningful in that context than being wrapped. Let me know if it needs to stay, regardless.
If you are concerned about the uncaught exception notice in static code analysis, we can wrap those lines in an exception maybe.
Agreed on adding tests, will be easier given the commit we just made on the library version bump... thanks for including the updates to the tests, there.
Comment #14
bradjones1Getting current tests to pass; then I'll tackle new tests.
Comment #15
e0ipsoGreat job! Current tests are green now.
Comment #16
e0ipso@bradjones1 is there any chance I can motivate you to contribute the tests for last leg of this issue?
Comment #17
bradjones1This issue is still on my radar, I am just lacking bandwidth with the day job at the moment. This is an important part of our infrastructure though so I'd like to get it committed. No ETA but I do intend to see this through.
Comment #18
bradjones1Tagging for DrupalCamp Colorado 2019 sprint day.
Comment #19
bradjones1This needs an entity update performed as entity schema updates are no longer automatically done per https://www.drupal.org/project/drupal/issues/2976035
Comment #20
e0ipsoI recently merged Simple OAuth Extras into Simple OAuth. This means that the patch no longer applies. However, this will make things easier in the future.
Comment #21
rpayanmComment #22
ajitsTaking the tag off as the patch was rerolled.
Comment #23
ajitsOr maybe not, as the patch uploaded failed to apply ;)
Comment #24
olafkarsten commentedRerolled #14. Interdiff isn't much of a help, cause of the simple_oauth_extras merge. It's a straight reroll plus the hook_update for updating the consumer entity (adding the pkce basefield). Lets see what the testbot has to say.
Comment #25
olafkarsten commentedThe changed catch clause in Oauth2GrantManager::getAuthorizationServer caused the failures. Lets try this one.
Comment #26
olafkarsten commentedOkay, seems somebody can code the tests now :)
Comment #27
olafkarsten commented- Adding tests
- Addressing #11
Comment #28
olafkarsten commentedready for review
Comment #29
e0ipsoThis is a great patch! Thanks for all the effort you put into this.
Comment #31
e0ipsoI granted some additional commit credit because this was tricky!