Instance parsing laravel cross-domain function opening method

For security reasons, the browser restricts cross-domain requests in Script. Since XMLHttpRequest follows the same-origin policy, all applications that use XMLHttpRequest to construct HTTP requests can only access their own domain names, and if cross-domain requests need to be constructed, developers need to work with the browser to make cross-domain configurations.

This article mainly introduces about Laravel how to open the cross-domain function of the relevant information, the text through the sample code introduced in very detailed, to everyone's study or work has a certain reference learning value, hope to help everyone.

The WEB Application Workgroup recommends a mechanism for cross-resource sharing, which enables the application server to support cross-site access control, making it possible to secure cross-site data transfer, which extends the original schema in several ways:

• The header of the response should be appended with access-control-allow-orign to indicate which request source is allowed access to the resource content

• The browser matches the values in the request source and response to verify

• For cross-domain requests, the browser pre-sends a non-trivial request to determine whether a given resource is ready to accept cross-domain resource access

• The server application determines whether the request crosses the domain by checking the orign of the request header.

Cross-origin resource sharing standard

The cross-origin resource sharing standard provides a new set of HTTP headers that allow the server to declare which sources can access resources on the server through a browser. In addition, the standard strongly requires that the browser must first send a pre-request in the options request (in particular, HTTP methods other than GET, or with some MIME-type POST requests) for any HTTP request methods that would cause a devastating response to the server data (preflight r Equest) to obtain the HTTP method supported by the server side for cross-origin requests. Sends that real request in the actual HTTP request method when the server is confirmed to allow cross-origin requests. The server side can also notify the client whether it is necessary to send credit information (including Cookies and HTTP authentication related data) along with the request.

Cross-source sharing standards require the browser and the server to work together to complete, the browser vendor has already been able to automatically complete the request, so the focus of cross-source resource access is still on the servers side.

The following lists some of the available response headers and request headers in the standard.

Response Header

• Access-control-allow-origin: Indicates which request source is allowed to access 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 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 the pre-request can be stored in the pre-request cache.

• Access-control-allow-methods: For a pre-request, which request method can be used for the actual request.

• Access-control-allow-headers: For a pre-request, indicates which header information can be used in the actual request.

• Origin: Indicates the origin of a pre-request or cross-domain request.

• Access-control-request-method: For a pre-request, indicate which requests in the pre-request method 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 sending request or pre-request.

• Access-control-request-method: With the request header when sending a pre-request, indicating how the actual request will be used.

• Access-control-request-headers: With the request header when sending a pre-request, indicates that the actual request will carry the request header.

Middleware

To allow cross-domain requests in Laravel, we can build an append-response middleware to add a response header that specifically handles cross-domain requests:

<?php namespace App\http\middleware;use closure;use response;class enablecrossrequestmiddleware {/** * Handle an Inco Ming request. * * @param \illuminate\http\request $request * @param \closure $next * @return Mixed * * Public function handle ($request, C Losure $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 things to keep in mind:

• For requests that cross-domain access and require accompanying authentication information, you need to specify Withcredentials as true in the XMLHttpRequest instance.

• This middleware you can build according to your own 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.

• When specifying access-control-allow-credentials to true in the response, Access-control-allow-origin cannot be specified as *

• The back-end middleware is appended with the response header only when the response is normal, and if an exception occurs, the response is not middleware-oriented.