Cross-Domain requests
For security reasons, the browser restricts cross-domain requests in Script. Because XMLHttpRequest follows the homology policy, all applications that use XMLHttpRequest to construct HTTP requests can only access their domain names, and if a cross-domain request needs to be constructed, the developer needs to make some configuration with the browser that allows Cross-domain.
The Consortium recommends a mechanism for sharing across resources, a mechanism that enables WEB application servers to support Cross station access control, making it possible to secure cross station data transmission, which extends the existing schema in several ways:
The head of the response should be appended access-control-allow-orign to indicate which request sources are allowed to access the resource content
The browser matches the value in the request source and the response to verify
For Cross-domain requests, the browser will advance a request that is not simple to determine whether a given resource is ready to receive Cross-domain resource access
The server application determines whether the request is cross-domain by checking the orign of the request header.
Cross-source resource sharing standards
Cross-source resource sharing standards by adding a series of HTTP headers, the server is able to declare which sources can access resources on that server through the browser. In addition, for HTTP request methods that can cause a damaging response to server data (in particular, HTTP methods other than get, or with some MIME-type POST requests), the standard strongly requires that the browser must first send a pre request as an option request (Preflight R Equest) to obtain a known server-side HTTP method that supports cross source requests. When confirming that the server allows a cross source request, send that real request in the actual HTTP request method. The server side can also notify the client that it is necessary to send credit information along with the request (including Cookies and HTTP authentication related data).
Cross-source sharing standards need the browser and the server to work together to complete, at present, browser vendors can be the request part of the automatic completion, so the focus of the cross source resource access is the servers side.
The following lists the response headers and request headers available in some standards.
Response Header
Access-control-allow-origin: Indicates which request sources are allowed access to the resource, the value can be "*", "null", or a single source address.
Access-control-allow-credentials: Indicates whether the response is exposed when the creadentials identity is omitted from the request. For a pre-request, it indicates that the actual request can contain the user credentials.
Access-control-expose-headers: Indicates which header information can be safely exposed to the API of the CORS API specification.
Access-control-max-age: Indicates how long a pre request can be stored in the prefetch cache.
Access-control-allow-methods: For the pre-request, which request methods can be used for the actual request.
Access-control-allow-headers: For the pre-request, it indicates which header information can be used in the actual request.
Origin: Indicates the source of a pre-request or Cross-domain request.
Access-control-request-method: For a pre-request, indicate which requests in the request form can be used in the actual request.
Access-control-request-headers: Indicates which header information in the pre-request can be used in the actual request.
Request Header
Origin: Indicates the source of the send request or the pre request.
Access-control-request-method: With the request header when the request is sent, indicates how the actual request will be used.
Access-control-request-headers: With the request header when the request is sent, indicates the request header that the actual request will carry.
Middleware
To allow Cross-domain requests in laravel, we can build an additional response middleware to add a response header that specifically deals with requests across domains:
<?php namespace App\http\middleware;
Use Closure;
Use Response;
Class Enablecrossrequestmiddleware {
/**
* Handle an incoming request.
*
* @param \illuminate\http\request $request
* @param \closure $next
* @return Mixed
*/
Public function handle ($request, Closure $next)
{
$response = $next ($request);
$response->header (' access-control-allow-origin ', config (' app.allow '));
$response->header (' access-control-allow-headers ', ' Origin, Content-type, Cookie, Accept ');
$response->header (' access-control-allow-methods ', ' Get, POST, PATCH, put, OPTIONS ');
$response->header (' access-control-allow-credentials ', ' true ');
return $response;
}
}
Here are some of the following areas to note:
For Cross-domain access and a request to accompany authentication information, you need to specify Withcredentials as true in the XMLHttpRequest instance.
This middleware you can build according to your needs, if you need to accompany the authentication information (including cookie,session) in the request then you need to specify Access-control-allow-credentials as true, Because if you do not specify the response header for a pre-request, the browser ignores the response directly.
Access-control-allow-origin cannot be specified as * When specified access-control-allow-credentials is true in the response
The post middleware will only be appended to the response header in a normal response, and if there is an exception, then the response will not pass through the middleware.