yeah man, i just completed your Key-Cloak course using Spring Boot 3. Just for this!

Thanks for your comment, the update of the tutorial is already planned, I already updated the Github code sometime back with the latest changes, so that people are not lost, I added a pinned comment to make this point clear.

Maybe one day you could make a "production-ready" back-end behind a paywall, I would pay big dollars for that!

i have the same question, Anyone could explain this? thanks

@@hoangang6586 I have the same problem, did you fix it?

the same problem did you fix it?

the same problem here

you have to use eureka.client.service-url.defaultZone instead of eureka.client.service-url.default-zone

Hi ! To resolve the deprecation warnings in your Spring Boot application for CSRF and JWT configurations, you can update your bean as follows: Replace .csrf().disable() with .csrf(ServerHttpSecurity.CsrfSpec::disable) for the CSRF configuration. Replace .oauth2ResourceServer(ServerHttpSecurity.OAuth2ResourceServerSpec::jwt) with .oauth2ResourceServer(oauth2ResourceServer -> oauth2ResourceServer.jwt(jwt -> {})) for the JWT configuration.

I already have tutorials on how to do this, check out my keycloak tutorial and KZfaq clone tutorial

@@ProgrammingTechie thanks a lot, but I mean for all the microservices project, not only the key lock part

I could access without any token.

Yes, the discovery service doesn't need any extra authentication to be set up. It can be accessed just by adding permit all feature to URI "/eureka/**" in gateway service as shown in mid section of the video. Thanks a lot to the creator of the video. It helped me to understand the MS concept well with latest spring boot versions

Seems like in api-gateway he allowed '/eureka/** ' (which resulted in free access to this resource), but then inside the discovery-server he protected it with httpBasic - which resulted in turn that in order for other microservices to be registered to this discovery-server, they had to provide username:password credentials.

Hi, I am getting the same error, have you resolved it?

same question, probably shouldn't be bypassing discovery server

same question, probably shouldn't be bypassing discovery server

for me , its bypassing successfully. I didn't get error with latest boot 3 and spring 6 configuration when try to load localhost:8080/eureka/web

Some of the the functions of the api-gateway includes parameter validation, allow/deny list, authentication and authorization, rate-limiting, dynamic routing and so on. From a typical architectural diagram indicating how a request flows in an api-gateway shows why it is favorable to implement security in this layer

I faced the same means no error at all. Discovery loads perfectly, and also it should not be authenticated as per config code. So its working fine :D

Same here. Many methods in this part are deprecated...

you missed spring cloud dependency in the client module

Unfortunately at this stage you have to recreate the realm, client, etc. You can run a docker container of keycloak, export the realm and mount that realm while running the docker container, that's what I did in the dockerize video (part -9)

Yes you can use API Gateway to maintain the Thymeleaf code. Then the API Gateway should be configured as an OAuth2 Clinet instead of Resource Server

Hi I don't understand, if you don't use GUI then you won't do any registration as the user will use the client I'd and client secret to get the token

​@@ProgrammingTechie Sorry, let me explain better. When you made the playlist on keycloak, if I have not misunderstood you have created a new user via the Keycloak admin interface. So the question is, how can an external user do a registration? For example in the project "Reddit clone" a new user called "api/signup" to register. (Sorry for any grammar errors, I don't speak English)

@@toto_frs620 You can enable the user registration option in keycloak, by going to your Realm settings -> Login -> User Registration and enable that checkbox, then when you try to access login page it will show you a login screen with option to register.

@@ProgrammingTechie User registration and login via own REST api would be a neat solution. In that case, the application can store client id and secret privately, and we don't rely on keycloak login/registration user interface.

@@RexpecT_ Exactly

Ideally yes but I didn't get into that detail in this tutorial

@@ProgrammingTechie Thanks for time and answer. But how would you protect these original ports in that case?

​@@arek9430I covered this in my previous Microservices tutorial - kzfaq.info/get/bejne/pK2Tid1zstCpd5s.html Basically, we secure the other services as resource servers and pass the token from API Gateway to the microservices, this is called as Token Relay.

video đầu tiên có nói kìa cha, coi tua à

just check spring security 6 documentation

.oauth2ResourceServer(oauth2 -> oauth2.jwt(Customizer.withDefaults())); I did this. its working fine for me.

Hi I will post the video this Saturday

@@ProgrammingTechie looking forward to)

@@ProgrammingTechie Bro .. Saturday was yesterday :p . . eagerly waiting for the next one.

@@AwonerMayank The video is almost ready I am adding some additional information, I will release by EOD today :)

@@ProgrammingTechie Thanks a lot bro :)

Hi, I am planning to use Kubernetes for this.

@@ProgrammingTechie May I know if you are working on the next video of this series or has it been put on hold? Thanks !

same issue, my error was I created the config package outside in the wrong place, I just moved it and works

@@felipev5607 Did u have also problem with cors? Because trying to create a front-end application that call a microservices I'm stuck. It work when I use postman not if api is called from angular app. According to doc to enable cors is enough to put those properties into api-gateway application.properties spring.cloud.gateway.globalcors.add-to-simple-url-handler-mapping=true spring.cloud.gateway.globalcors.corsConfigurations.[/**].allowedOrigins=* spring.cloud.gateway.globalcors.corsConfigurations.[/**].allowedHeaders=* spring.cloud.gateway.globalcors.corsConfigurations.[/**].allowedMethods=* the (*) symbol is not showed...but is after any configuration option. No luck! any ideas?

you have to use eureka.client.service-url.defaultZone instead of eureka.client.service-url.default-zone

Spring Cloud Gateway is built on top of Spring Webflux instead of Spring MVC. EnableWebSecurity - used when working with Spring MVC. EnableWebFluxSecurity - used when working with Spring Web Flux

Check the GitHub code, it's updated

Hi, can you tell me which keycloak version you are using ?I suspect it may be a change with the new version

@@ProgrammingTechie I'm using 19.0.2 version

@@ProgrammingTechie can you resolve and help me

did u manage to solve it?

@marekstarzycki4131 No, but I was doing different stuff. I need to get back to it this weekend. Wanna have a look, maybe?

I did this serverHttpSecurity.csrf(csrf -> csrf.disable()) .authorizeExchange(exchange -> exchange .pathMatchers("/eureka/**") .permitAll() .anyExchange() .authenticated()) .oauth2ResourceServer(oauth2 -> oauth2.jwt(Customizer.withDefaults()));

@@SdwHoussamEddine Thank you, that worked! :) Could you also help me out with the deprecated functions here? (withDefaultPasswordEncoder and authorizeRequests seem to be deprecated and are not working as desired) public class SecurityConfig { @Bean public InMemoryUserDetailsManager userDetailsService() { UserDetails user = User.withDefaultPasswordEncoder() .username("eureka") .password("password") .roles("USER") .authorities("USER") .build(); return new InMemoryUserDetailsManager(user); } @Bean public SecurityFilterChain securityFilterChain(HttpSecurity httpSecurity) throws Exception { httpSecurity.csrf(Customizer.withDefaults()) .authorizeRequests() .anyRequest() .authenticated() .and() .httpBasic(Customizer.withDefaults()); return httpSecurity.build(); } }

@@pradhidas have you fixed the deprecated issue?

I have the same problem :/ any solution

@@marwenghannem2193 Greetings, Actually for me the issue was soemthing else. Later on I realised that the security config package that I had created wasn't under the root package due to which request were not going through.

Oh wow. Got the same problem and solved by what @Sudip Rana found. Move the config file to the correct place.

@@viettran1813 Great to hear 😇

@@sudiprana800 You're a life saver man! Thanks. Great observation. But I can't understand that why this solution worked for us. Is there any one explain us to logic of the solution?