JwtTranscoderInterface exposes too many implementation details

Created on 27 November 2024, 8 months ago

Problem/Motivation

I see that a new major branch 3.x is in progress, to bring Drupal 11 support.
I wonder if this would be the time to also simplify some of the architecture.
Or maybe this should be done in a 4.x branch, to not delay the Drupal 11 support.

I notice that:
- The JwtTranscoderInterface exposes lots of getters and setters that I would consider implementation details.
- The JwtTranscoder is quite stateful, and also has invalid states where it won't work (if configuration is empty or incomplete, or if it is not initialized yet).

Steps to reproduce

Proposed resolution

An interface describes what the consumer code can expect from an object that is passed in as a dependency.
The smaller the interface, the easier the service / object is to replace or decorate.

I think there are two relevant methods, encode() and decode().
The rest can be kept out of the interface.

To avoid the statefulness, we could have a transcoder class that receives everything it needs in the constructor.
Then we can have other code that prepares these values from config.

This transcoder itself could be a service, or the service could be some kind of wrapper that takes care of the initialization.

All of this is TBD, for now I just want to open up the topic.

Remaining tasks

User interface changes

API changes

This would impact modules that directly interact with the other methods in JwtTranscoderInterface.

Data model changes

🌱 Plan
Status

Active

Version

3.0

Component

Code

Created by

🇩🇪Germany donquixote

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

Comments & Activities

Production build 0.71.5 2024