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
Question
How can we mock the authentication state of a test user?
In our project, we configure the library using 2 JSON files that are merged at runtime:
config.base.json which contains the environment invariant configuration
config.overrides.json which is different in each environment (dev, qua, prd)
The authentication section (property) in the JSON can be either a test user (given name, family name, and username) or the actual configuration of our IdP server.
The scenario where the authentication section is the IdP configuration works perfectly but I'm wondering how can configure the library to allow the test (static) user scenario where there is not IdP.
I thought about a couple of possible solutions but both turned out to be very difficult to implement (at least to me):
Using a custom storage implementation which would return a "static" object when the configuration points to a test user and use the session storage when the configuration points to an IdP configuration. I'm not sure what the static object should contains to make the library still work.
Using a HTTP interceptor to intercept the HTTP calls to the well-known endpoints but it wouldn't intercept the eventual redirects during login.
Since both the above solutions seem to difficult to implement, we actually use a façade around the OidcSecurityService where we check for the configuration and either forward to the actual OidcSecurityService service or return fake data instead.
What do you think about this scenario? Do you have any advice? I hope my explanation make sense to you.
Here is a fragment of code representing the configuration object:
What Version of the library are you using?
14.1.4
Question
How can we mock the authentication state of a test user?
In our project, we configure the library using 2 JSON files that are merged at runtime:
The authentication section (property) in the JSON can be either a test user (given name, family name, and username) or the actual configuration of our IdP server.
The scenario where the authentication section is the IdP configuration works perfectly but I'm wondering how can configure the library to allow the test (static) user scenario where there is not IdP.
I thought about a couple of possible solutions but both turned out to be very difficult to implement (at least to me):
Since both the above solutions seem to difficult to implement, we actually use a façade around the
OidcSecurityService
where we check for the configuration and either forward to the actualOidcSecurityService
service or return fake data instead.What do you think about this scenario? Do you have any advice? I hope my explanation make sense to you.
Here is a fragment of code representing the configuration object:
The text was updated successfully, but these errors were encountered: