Get the App
SLTechnology News&Howtos  ›  Internet Technology  › 

What are the pitfalls encountered by the SpringCloud consul microservice SpringSecurityOAuth2 authorization_code mode?

Shulou Source: shulou.com Published: 2022-06-02 02:26:59 09月29日 Update

This article shows you what are the pitfalls encountered in the SpringCloud consul microservice SpringSecurityOAuth2 authorization_code model. The content is concise and easy to understand. It will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

At present, the project has found an abnormal problem when using consul for service registration and discovery and authorization_code mode for SpringSecurityOAuth3 authority authentication.

This is the start of the service registration code block bootstrap.yml:

Spring: cloud: consul: port: 8500 host: localhost discovery: serviceName: auth locator: lower-case-service-id: true enabled: true register: true

This is the health check after registration.

He will register your host address. It may not be a problem to use it normally, but when you authenticate the authorization_code mode of OAuth3, a cross-domain exception occurs as follows:

This is the request path:

Http://localhost:8001/auth/oauth/authorize?response_type=code&client_id=client_name&redirect_uri=http://localhost:8001/auth/callback&scope=auth

After access, jump to the default login interface:

Do not have permission to return 401. The problem is that jumping back to the hostname leads to cross-domain problems.

The solution to this problem is to modify the initial bootstrap.yml file:

Spring: cloud: consul: port: 8500 host: localhost discovery: serviceName: auth locator: lower-case-service-id: true enabled: true register: true prefer-ip-address: true # this must be matched with tags: version=1.0 instance-id: ${spring.application.name}: ${spring.cloud.client.ip-address} HealthCheckInterval: 15s health-check-url: http://${spring.cloud.client.ip-address}:${server.port}/actuator/health

Consul registration adds mandatory restrictions on the way prefer-ip-address:true forces access to ip to register to consul.

2019.07.09

Because there is no configuration

Spring.cloud.consul.discovery.prefer-ip-address=true

The microservice will register the hostname of the host / container in which it is registered with consul. However, we will find that sometimes the hostname of registering IP to consul is obtained by calling Java API, and sometimes Java API cannot get the hostname, so it will send the IP address to consul + as long as you configure the environment variable HOST_NAME, you can register the environment variable you configured.

Spring.cloud.gateway.discovery.instance.hostname=$ {HOST_NAME}

Get the code related to the hostname:

Https://github.com/spring-cloud/spring-cloud-commons/blob/master/spring-cloud-commons/src/main/java/org/springframework/cloud/commons/util/InetUtils.java

Jumping back to the hostname from ip results in a cross-domain permission exception.

The above is the pit encountered by the SpringCloud consul microservice SpringSecurityOAuth2 authorization_code model. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Tags: Hosts services problems patterns permissions this is configuration code content variables addresses that is skills time environment knowledge enforcement authentication simplicity health Apple Docker Huawei Linux macOS MariaDB Microsoft MySQL NVidia OPPO Reno Shulou Tech Info Microsoft Huawei Shulou Technology Redmi