Spring Boot: como resolver problemas de cross-domain

Tags relacionadas：1. O que é resolução de domínio e como funciona
2. Alibaba Cloud DNS

Introdução aos problemas de cross-domain no Spring Boot

Motivo do problema de cross-domain: o navegador restringe o acesso a recursos que considera externos por motivos de segurança.

Problemas de cross-domain no Spring Boot. Fenômeno do problema de cross-domain

bloqueado pela política CORS: o cabeçalho 'Access-Control-Allow-Origin' não está presente no recurso solicitado
O acima significa que você está acessando um recurso cujo endereço foi bloqueado pelo protocolo CORS e o parâmetro Access-Control-Allow-Origin não foi encontrado no cabeçalho.

Análise do problema de cross-domain

Motivo do problema de cross-domain: o navegador restringe o acesso a recursos que considera externos por motivos de segurança.
Por exemplo, se você tem um site em 127.0.0.1:8080/ e uma página está hospedada nele, nessa página você não terá restrições para acessar os recursos desse mesmo site. Mas, se tentar acessar outros sites, como recursos em 127.0.0.1:8081, o acesso será limitado.
Observação: por enquanto, considere que protocolo, nome de domínio e porta iguais constituem o mesmo site.

Problemas de cross-domain no Spring Boot. No entanto, tags com atributo src não possuem essa restrição, como img, script, entre outras.
Historicamente, o front-end e o back-end dos programas anteriores não eram separados; a página e a interface de solicitação estavam sob o mesmo nome de domínio e a mesma porta. Todos os navegadores consideravam que a página originária do mesmo site solicitava a interface do mesmo site, e isso era permitido durante muito tempo.

Problemas de cross-domain no Spring Boot. Por exemplo, 127.0.0.1:8080/index.html solicitar a interface 127.0.0.1:8080/a/b/c/userList — isso é possível.
Atualmente, o front-end e o back-end são separados, e a página e a interface geralmente não fazem parte do mesmo programa, portanto isso não é permitido e essa exceção será lançada.

Problemas de cross-domain no Spring Boot. O que é origem e cross-domain

A origem é composta pelo protocolo, nome de domínio e número da porta.

Uma URL consiste em protocolo, nome de domínio, porta e caminho. Se o protocolo, o nome de domínio e a porta de duas URLs forem idênticos, elas são da mesma origem. Caso contrário, desde que o protocolo, o nome de domínio ou a porta sejam diferentes em qualquer um deles, trata-se de cross-domain.
Comparação de cross-domain para https://www.baidu.com/index.html:

O que é a Política de mesma origem?
A Política de mesma origem é uma convenção. É a função de segurança mais básica e central do navegador. Sem a Política de mesma origem, as funções normais do navegador podem ser afetadas. Pode-se dizer que a web é construída com base na Política de mesma origem, e o navegador é apenas uma implementação dessa política.
A Política de mesma origem divide-se nos seguintes dois tipos:
1.Política de mesma origem do DOM: é proibido operar no DOM de páginas de origens diferentes. O principal cenário aqui é o caso de cross-domain com iframe — iframes de nomes de domínio diferentes têm acesso restrito entre si.
2.Política de mesma origem do XMLHttpRequest: é proibido usar objetos XHR para iniciar solicitações HTTP para endereços de servidor de origens diferentes.
Spring Boot: Resolução de problemas de cross-domain

1. Problemas de cross-domain no Spring Boot. Criar um filtro para resolver cross-domain

Os componentes do projeto são implantados separadamente, portanto os problemas de cross-domain precisam ser resolvidos. Usamos cookies para armazenar informações de login do usuário e controlamos permissões no interceptador do Spring. Quando as permissões não correspondem, retornamos diretamente um resultado JSON fixo ao usuário. Quando o usuário faz login, tudo funciona normalmente; quando o usuário faz logout ou o token expira, ocorre o fenômeno de cross-domain devido à ordem de execução do interceptador e do cross-domain. Sabemos que uma solicitação HTTP passa primeiro pelo filtro e depois o interceptador é processado após chegar ao servlet. Se colocarmos o CORS no filtro, ele poderá ser executado com prioridade sobre o interceptador de permissões.
@Configuration

public class CorsConfig {
@Bean
public CorsFilter corsFilter() {
CorsConfiguration corsConfiguration = new CorsConfiguration();
corsConfiguration.addAllowedOrigin("*");
corsConfiguration.addAllowedHeader("*");
corsConfiguration.addAllowedMethod("*");
corsConfiguration.setAllowCredentials(true);

UrlBasedCorsConfigurationSource urlBasedCorsConfigurationSource = new UrlBasedCorsConfigurationSource();
urlBasedCorsConfigurationSource.registerCorsConfiguration("/**", corsConfiguration);
return new CorsFilter(urlBasedCorsConfigurationSource);
}
}

2. Cross-domain com CORS baseado na configuração WebMvcConfigurerAdapter

O cross-domain pode ser resolvido com JSONP no front-end, mas o JSONP só pode enviar solicitações GET e não consegue enviar outros tipos de solicitações, o que é muito limitado em aplicações de estilo RESTful. Portanto, recomendamos o uso de CORS (Cross-Origin Resource Sharing) no back-end para resolver problemas de cross-domain. Essa solução não é exclusiva do Spring Boot. No framework SSM tradicional, o CORS também pode ser usado para resolver problemas de cross-domain, mas costumávamos configurar o CORS em arquivos XML. Agora podemos implementar a interface WebMvcConfigurer e sobrescrever o método addCorsMappings para resolver problemas de cross-domain.
@Configuration
public class CorsConfig implements WebMvcConfigurer {
@Override
public void addCorsMappings(CorsRegistry registry) {
registry.addMapping("/**")
.allowedOrigins("*")
.allowCredentials(true)
.allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
.maxAge(3600);
}
}
3. Configuração de CORS no controller
Para configurar CORS no método do controller, você pode adicionar a anotação @CrossOrigin ao método handler anotado com @RequestMapping para habilitar o CORS (por padrão, @CrossOrigin permite todas as origens e métodos HTTP especificados na anotação @RequestMapping):
@RestController _
@RequestMapping ( "/account" )
public class AccountController {
@CrossOrigin _
@GetMapping ( "/{id}" )
public Account retrieve ( @PathVariable Long id )
// ...
A
@DeleteMapping ( "/{id}" )
public void remove ( @PathVariable _ Long id ) {
// ...
}
}

onde os parâmetros em @CrossOrigin:
@CrossOrigin indica que todas as URLs podem acessar este recurso. @CrossOrigin(origins = "http://127.0.0.1:8080") // Indica que apenas esta URL tem permissão para acessar este controller via cross-domain. Descrição do código: a anotação @CrossOrigin é muito prática — pode ser usada em métodos e também em classes. Se você não definir o atributo value ou origins, o padrão é permitir o acesso de todas as URLs/domínios.
1.O atributo value pode definir múltiplas URLs.
2.O atributo origins também pode definir múltiplas URLs.
3.O atributo maxAge especifica o tempo máximo de cache antes de preparar uma resposta. É o período de validade da solicitação de verificação.
4.O atributo allowCredentials indica se o usuário pode enviar e receber cookies. O padrão é false.
5.O atributo allowedHeaders indica quais cabeçalhos de solicitação são permitidos.
6.O atributo methods indica os métodos permitidos para a solicitação; o padrão é get, post, head.
Motivos pelos quais @CrossOrigin não funciona
1. A versão do Spring MVC deve ser 4.2 ou superior para suportar @CrossOrigin.

2. O @CrossOrigin não resolveu o problema de solicitação cross-domain, mas uma solicitação incorreta resultou na impossibilidade de obter a resposta esperada, fazendo com que o navegador exibisse o aviso de cross-domain.
Com a anotação @CrossOrigin acima da anotação do Controller, o problema de cross-domain ainda ocorre. Uma das soluções é:
Os métodos Get e Post não foram especificados na anotação @RequestMapping. Após especificá-los, o problema foi resolvido.
Código semelhante é o seguinte:
@CrossOrigin _
@RestController _
public class person {

@RequestMapping ( method _ = RequestMethod.GET ) _ _
public String add ( ) {
// some code
}
}