Error creating bean with name ‘jwtAuthenticationFilter’ defined in file [\jwt_auth\build\classes\kotlin\main\com\codersee\jwtauth\config\JwtAuthenticationFilter.class]:
Unsatisfied dependency expressed through constructor parameter 1:
Error creating bean with name ‘tokenService’ defined in file
[\jwt_auth\build\classes\kotlin\main\com\codersee\jwtauth\service\TokenService.class]:
Failed to instantiate [com.codersee.jwtauth.service.TokenService]: Constructor threw exception
at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray
(ConstructorResolver.java:801)

Any idea why this might be happening?

thanks
Mick

If I create user I didn’t see any role that We can define.

There are some routes that need ADMIN ROLE to access it.

Thanks

Hey Laura! 🙂

There are multiple ways we can achieve that, for example:

1. 1st can be simple- we can add @Profile annotation to our security beans and specify environments for which we can them to be instantiated. Or, alternatively add some boolean flag and combine with @Conditional (and set this flag in application.properties)
2. @AutoConfigureMockMvc(addFilters = false) (may depend on how you’re testing)

Let me know if this helped 🙂

Hey Thomas!

I totally agree with your point, “rule 1 of auth is don’t write your own auth”. And all the points and examples you specified are really fair points.

I’ve seen a few debates on this topic and usually it all comes to how much control you would like to have over the process. On one side we have those who always prefer to delegate this to external tools/services, which takes a lot of responsibility of your shoulders, but also costs $$. On the other side, we have those who choose for some reason to have more control over the process, which also costs $$, but in their time.

I wouldn’t say there’s always a clear winner here, but oftentimes relying on Okta/OAuth0 may be a good choice.

Also, I’d add Keycloak to the list, which may be a cheaper alternative to Okta.