x)- [x] bug report -> please search for issues before submitting
- [ ] feature request
keycloak-angular 6.0.0
Angular 7.2.2
Keycloak version unknown, only have keycloak-angular as dependency.
Default implementation with the following settings:
const keycloak = injector.get(KeycloakService)
return keycloak.init({
config: bootstrapConfig,
initOptions: {
onLoad: 'login-required'
},
enableBearerInterceptor: true,
bearerPrefix: 'Bearer'
We run a ng build --prod command. In the resulting AOT build, we still see bearer instead of Bearer at some points. This results in issues where the backend is CaSe SeNsItIvE about the Bearer.
We have pinpointed the issue to be part of the keycloak.js dependency in these files/lines:
https://github.com/keycloak/keycloak/blob/master/adapters/oidc/js/src/main/resources/keycloak.js#L377
https://github.com/keycloak/keycloak/blob/master/adapters/oidc/js/src/main/resources/keycloak.js#L402
Where they are still hardcoded. We are also creating an issue for these on the respective repository.
None, just 401 returned by the server, which is server implementation.
Would prefer to have the hardcoded bearer be replaced by the variable bearerPrefix. I'm not to familiar with the underlying keycloak.js dependency, but maybe there's some configuration there as well that could benefit from using the variable.
Hmmmm may not be an issue at all.
@Bjeaurn, so we have two scenarios here:
The first one, the keycloak.js lib will request the user info to the keycloak server instance. The keycloak server instance should accept the bearer as it handles bearer <token>. The interceptor from keycloak-angular doesn't adds the bearer here because it is outside of the angular HttpClient scope, so that is okay.
Then in the second scenario the keycloak-angular will add bearerPrefix dynamically, if any value is provided, to the HttpClient requests, however this is targeting your resource server - backend. This should follow the value you just informed in your keycloak initialization.
Are you having issues in this second scenario?
I appreciate you taking the time to check this out, but we've figured out our actual issue.
The part that triggered us was that there are hardcoded bearer tokens in keycloak.js, which is relevant to the issue we saw.
Our problem turned out to be build related, which we fixed. Haven't seen issues since. You may consider this problem closed.
If you want to pursue a possible bug with keycloak.js, please do reply; I will be happy to help you track down any issues.
As of now, it seems that keycloak-angular does exactly what we want.
Thanks for your feedback and support @Bjeaurn.
All the best! 馃槂
Most helpful comment
Hmmmm may not be an issue at all.