Exemple de Laravel permettant des fonctionnalités inter-domaines

Cet article vous présente principalement les informations pertinentes sur la façon d'activer les fonctions inter-domaines dans Laravel. L'article le présente en détail à travers un exemple de code. Il a une certaine valeur d'apprentissage de référence pour les études ou le travail de tous les amis qui en ont besoin. peut suivre ci-dessous. Apprenons ensemble.

Avant-propos

Cet article vous présente principalement le contenu pertinent sur Laravel activant les fonctions inter-domaines, et le partage pour votre référence et votre étude . Les mots suivants Pas grand chose à dire, jetons un œil à l’introduction détaillée.

Requêtes inter-domaines

Pour des raisons de sécurité, les navigateurs limiteront les requêtes inter-domaines dans Script. Étant donné que XMLHttpRequest suit la politique de même origine, toutes les applications qui utilisent XMLHttpRequest pour construire des requêtes HTTP ne peuvent accéder qu'à leurs propres noms de domaine. Si elles doivent créer des requêtes inter-domaines, les développeurs doivent coopérer avec le navigateur pour effectuer certaines configurations autorisant le cross-domain. -demandes de domaine.

Le groupe de travail sur les applications du W3C a recommandé un mécanisme de partage entre ressources qui permet aux serveurs d'applications Web de prendre en charge le contrôle d'accès entre sites, permettant ainsi de sécuriser la transmission de données entre sites. Ce mécanisme utilise plusieurs extensions. le mode d'origine :

• L'en-tête de réponse doit être ajouté avec Access-Control-Allow-Orign pour indiquer quelles sources de requête sont autorisées à accéder au contenu de la ressource

• Le navigateur vérifiera la correspondance entre la source de la requête et la valeur dans la réponse

• Pour les requêtes inter-domaines, le navigateur pré-enverra une méthode non simple pour déterminer si une ressource donnée est prête à accepter l'accès aux ressources inter-domaines

• L'application serveur détermine si la requête est inter-domaine en vérifiant l'Orign dans l'en-tête de la requête.

Norme de partage de ressources d'origine croisée

La norme de partage de ressources d'origine croisée permet au serveur de peut déclarer lequel les sources peuvent accéder aux ressources sur le serveur via le navigateur. De plus, pour les méthodes de requête HTTP qui provoqueront des réponses destructrices sur les données du serveur (notamment les méthodes HTTP autres que GET, ou les requêtes POST avec certains types MIME), la norme exige fortement que le navigateur envoie au préalable une requête prédéfinie dans la méthode de requête OPTIONS. . requête (requête de contrôle en amont) pour obtenir les méthodes HTTP prises en charge par le serveur pour les requêtes d'origine croisée. Après avoir confirmé que le serveur autorise les requêtes d'origine croisée, envoyez la vraie requête avec la méthode de requête HTTP réelle. Le serveur peut également informer le client si des informations de crédit (y compris les cookies et les données liées à l'authentification HTTP) doivent être envoyées avec la demande.

La norme de partage d'origines croisées nécessite la coopération du navigateur et du serveur pour être complétée. Actuellement, les fabricants de navigateurs peuvent compléter automatiquement la partie demande, de sorte que l'accès aux ressources d'origines croisées est toujours axé sur l'accès aux ressources d'origines croisées. le côté serveur.

Vous trouverez ci-dessous quelques en-têtes de réponse et en-têtes de requête disponibles dans la norme.

En-tête de réponse

• Access-Control-Allow-Origin : Indique quelles sources de requête sont autorisées à accéder aux ressources, la valeur peut être "* ", "null" ou une adresse source unique.

• Access-Control-Allow-Credentials : indique si la réponse est exposée lorsque l'identifiant des informations d'identification est omis de la demande. Pour les pré-demandes, cela indique que les informations d'identification de l'utilisateur peuvent être incluses dans la demande réelle.

• Access-Control-Expose-Headers : indique quelles informations d'en-tête peuvent être exposées en toute sécurité à l'API de la spécification API CORS.

• Access-Control-Max-Age : Spécifie la durée pendant laquelle les pré-requêtes peuvent être stockées dans le cache de pré-requête.

• Access-Control-Allow-Methods : pour les pré-requêtes, quelles méthodes de requête peuvent être utilisées pour les requêtes réelles.

• Access-Control-Allow-Headers : pour les pré-demandes, indique quelles informations d'en-tête peuvent être utilisées dans la demande réelle.

• Origine : Indique la source de la pré-demande ou de la demande cross-domain.

• Access-Control-Request-Method : Pour les pré-requêtes, indiquez quelles méthodes de requête dans les pré-requêtes peuvent être utilisées dans les requêtes réelles.

• Access-Control-Request-Headers : indique quelles informations d'en-tête dans la pré-requête peuvent être utilisées dans la demande réelle.

En-tête de demande

• Origine : Indique la source de la demande ou de la pré-demande.

• Access-Control-Request-Method : Apportez cet en-tête de requête lors de l'envoi de la pré-requête, en indiquant la méthode de requête qui sera utilisée dans la requête réelle.

• Access-Control-Request-Headers : Cet en-tête de requête est inclus lors de l'envoi de la pré-requête, indiquant les en-têtes de requête que la requête réelle portera.

Middleware

Pour autoriser les requêtes inter-domaines dans Laravel, nous pouvons créer un middleware qui ajoute des réponses pour ajouter un traitement spécialisé pour les requêtes inter-domaines request. En-tête de réponse de la demande de domaine :

<?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(&#39;Access-Control-Allow-Origin&#39;, config(&#39;app.allow&#39;));
  $response->header(&#39;Access-Control-Allow-Headers&#39;, &#39;Origin, Content-Type, Cookie, Accept&#39;);
  $response->header(&#39;Access-Control-Allow-Methods&#39;, &#39;GET, POST, PATCH, PUT, OPTIONS&#39;);
  $response->header(&#39;Access-Control-Allow-Credentials&#39;, &#39;true&#39;);
  return $response;
 }

}

Il y a les éléments suivants à noter :

• Pour les demandes d'accès inter-domaines qui doivent être accompagnées d'informations d'authentification, vous devez spécifier withCredentials comme true dans l'instance XMLHttpRequest.

• Vous pouvez créer ce middleware en fonction de vos propres besoins. Si vous devez inclure des informations d'authentification (y compris le cookie, la session) dans la demande, vous devez alors spécifier Access-Control-Allow-Credentials comme. true, Car pour les pré-requêtes, si vous ne précisez pas l'en-tête de réponse, le navigateur ignorera directement la réponse.

• Lorsque Access-Control-Allow-Credentials est spécifié comme vrai dans la réponse, Access-Control-Allow-Origin ne peut pas être spécifié comme *

• Le post-middleware n'ajoutera des en-têtes de réponse que lorsqu'il répond normalement, et si une exception se produit, la réponse ne passera pas par le middleware.

Résumé

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!