Feature configurable grant types #88
Conversation
|
EndpointHelper is not a general class for all endpoints so I think we should name it TokenEndpointHelper . |
Correct, I changed it. |
|
Should I also change token_coop module and class name to Token and replace the existing one? Or leave it for the future? |
|
I think you should. |
Previously the token endpoint was named AccessToken instead of Token, which is the correct name now. I guess we should try to keep AccessToken (maybe as an alias) for backwards compatibility? |
|
I don't know. It is the token endpoint not the access token endpoint. |
peppelinux
left a comment
peppelinux
left a comment
There was a problem hiding this comment.
LGTM
@angelakis is it time to merge it?
I wanted to rename to Token and create an alias for AccessToken but haven't found the time yet. We can merge once I make the changes @nsklikas pointed today, the renaming can be done on a separate pr. |
The user can now set the usual grant types to have a default configuration and class, without the need to set the oidcendpoint class path. This can be done by setting a value of "default" or None (no value in yaml dict).
Removed "default" value for grant types and added True instead. So now None or True enables the grant_type with the default class, while False disables it and of course a dict with a custom class uses that instead.
angelakis
force-pushed
the
feature-configurable-grant-types
branch
from
c90e418 to
ec006ad
Compare
|
I believe this can be merged now. |
|
@rohe do we have to merge the new storage model before merge this or we can procede as It Is? |
|
This looks ready for merge. My fingers are on the merge Button, Is there any doubts? Can we proceed? |
|
Go ahead! |
4 participants
As discussed in #59 (comment), I split up the configurable grant types feature (originally by-grant-types) from the token exchange specific changes to make review easier.
This branch refactors token_coop module to allow configuring different handlers for each grant type configured.