You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The library is great and easy to integrate. However, when another microservice has added the dependency and added the annotations, the users microservice MUST be running for it to work (otherwise, it won't even boot because fetching the public key will fail and throw a fatal exception).
It would be very useful to have a configurable property to specify in which "mode" the library works. I can think of 3 modes:
enabled (enforces the security and passes the auth information, as today)
disabled (does not do anything)
mock (passes a "mocked" authentication information)
In the "mock" mode, the library does not try to get data from the json web token. Instead, it passes information configured via other properties in the application.properties file (e.g. io.pestakit.users.mock.username, .userid, etc.).
One could even think of a 4th mode that extracts data from the json web token passed in the header, but does NOT validate the signature of this token. I have mixed feelings: it is useful for testing purposes (I can write tests with different users), but it is also a bit dangerous (it MUST NOT leak to production).
The text was updated successfully, but these errors were encountered:
The library is great and easy to integrate. However, when another microservice has added the dependency and added the annotations, the users microservice MUST be running for it to work (otherwise, it won't even boot because fetching the public key will fail and throw a fatal exception).
It would be very useful to have a configurable property to specify in which "mode" the library works. I can think of 3 modes:
In the "mock" mode, the library does not try to get data from the json web token. Instead, it passes information configured via other properties in the application.properties file (e.g. io.pestakit.users.mock.username, .userid, etc.).
One could even think of a 4th mode that extracts data from the json web token passed in the header, but does NOT validate the signature of this token. I have mixed feelings: it is useful for testing purposes (I can write tests with different users), but it is also a bit dangerous (it MUST NOT leak to production).
The text was updated successfully, but these errors were encountered: