Lösen Sie das domänenübergreifende Sitzungsproblem in thinkphp

Bei lokaler Verwendung ist alles normal. Sowohl das Back-End-Projekt als auch das Front-End-Projekt werden auf dem Server bereitgestellt, und nach dem Back-End-Projekt ist alles normal Auf dem Server bereitgestellt und der domänenübergreifende Zugriff so eingestellt, dass der domänenübergreifende Zugriff möglich ist. Bei der Verwendung der Back-End-Projektschnittstelle auf dem Server tritt ein Problem auf:

Zuerst verwenden Der Postbote testet die Schnittstelle zum Erhalten des Bildverifizierungscodes und die Schnittstelle zum Verifizieren des Bildverifizierungscodes.

Verwenden Sie dann die Schnittstelle zum Abrufen des Bildverifizierungscodes in HTML, es funktioniert schließlich einwandfrei. Verwenden Sie schließlich die Schnittstelle zum Verifizierungsbildverifizierungscode in JS, es geht schief! ! !

Analyse

Anhand der Problembeschreibung können wir erkennen, dass das Problem domänenübergreifend auftritt. Es gibt also zwei Möglichkeiten: Zum einen sind die domänenübergreifenden Einstellungen falsch, zum anderen liegt ein Problem mit thinkphp selbst vor.

Bei Verwendung einer anderen domänenübergreifenden Konfiguration besteht das Problem weiterhin. Das ist ein Problem mit thinkphp selbst. Nach der Suche nach Informationen liegt das Problem in der domänenübergreifenden Sitzung von thinkphp.

Subdomänenübergreifende Lösung

Tatsächlich muss session.cookie_domain festgelegt werden, wenn sitzungsübergreifende domänenübergreifende Probleme gelöst werden sollen, unabhängig davon, ob es sich um ThinkPHP oder PHP selbst handelt.
Die Hauptlösungen für das Problem der domänenübergreifenden Sitzung sind wie folgt:

Der erste Fall: Wenn sich keine .htaccess-Datei im Verzeichnis befindet, d. h. wenn die URL nicht pseudostatisch ist , dann fügen Sie:

ini_set('session.cookie_domain',".domain.com");//跨域访问Session

zur ersten Zeile von conf/config.php hinzu. Wenn Sie das Debuggen aktivieren, wird es funktionieren! Aber wenn das Debuggen ausgeschaltet ist, funktioniert es nicht!

Zweiter Fall: Wenn sich in Ihrem Verzeichnis eine .htaccess-Datei befindet, fügen Sie im Stammverzeichnis die erste Zeile von index.php hinzu:

Diese Methode spielt keine Rolle, ob es aktiviert ist oder nicht. Es funktioniert zum Debuggen!

Unser Problem ist jedoch kein Cross-Subdomain-Problem, sondern ein vollständig Domain-übergreifendes Problem, sodass die obige Methode nicht funktioniert.

Komplette domänenübergreifende Lösung

Anfrage zum Bildverifizierungscode erhalten

Anfrageinformationen zum Erhalten des Bildverifizierungscodes anzeigen, Anforderungsheader sind:

Accept:image/webp,image/*,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:zh-CN,zh;q=0.8,en-US;q=0.6,en;q=0.4
Connection:keep-alive
Cookie:pma_lang=zh_CN; pma_collation_connection=utf8_unicode_ci; pma_iv-1=wnpO4gv0eQRW1AMHmGr2ww%3D%3D; pmaUser-1=weZPqS0%2BW7nzFUVHRdqcfA%3D%3D
Host:api.voidking.com
Referer:http://localhost/ajax/ajax.html
User-Agent:Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36

Antwort-Header sind:

Access-Control-Allow-Origin:*
Cache-Control:post-check=0, pre-check=0
Cache-Control:private, max-age=0, no-store, no-cache, must-revalidate
Connection:keep-alive
Content-Type:image/png
Date:Sun, 27 Nov 2016 12:10:44 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Pragma:no-cache
Server:nginx
Set-Cookie:PHPSESSID=721t4sqanvsii550m1dk8gq1o3; path=/; domain=.voidking.com
Transfer-Encoding:chunked

Verification Verification Code Request

Anfrageinformationen für Verifizierungs-Verifizierungscode anzeigen, Request Header sind:

Accept:application/json, text/javascript, */*; q=0.01
Accept-Encoding:gzip, deflate
Accept-Language:zh-CN,zh;q=0.8,en-US;q=0.6,en;q=0.4
Connection:keep-alive
Content-Length:9
Content-Type:application/x-www-form-urlencoded; charset=UTF-8
Host:api.voidking.com
Origin:http://localhost
Referer:http://localhost/ajax/ajax.html
User-Agent:Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36

Antwort-Header lauten:

Access-Control-Allow-Origin:*
Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection:keep-alive
Content-Encoding:gzip
Content-Type:text/html; charset=UTF-8
Date:Sun, 27 Nov 2016 12:13:21 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Pragma:no-cache
Server:nginx
Set-Cookie:PHPSESSID=149t0hhs2icqaaemvp39onkgp4; path=/; domain=.voidking.com
Transfer-Encoding:chunked
Vary:Accept-Encoding

Bildbestätigungscode erneut anfordern

Anfrage-Header lauten:

Accept:image/webp,image/*,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:zh-CN,zh;q=0.8,en-US;q=0.6,en;q=0.4
Cache-Control:max-age=0
Connection:keep-alive
Cookie:pma_lang=zh_CN; pma_collation_connection=utf8_unicode_ci; pma_iv-1=wnpO4gv0eQRW1AMHmGr2ww%3D%3D; pmaUser-1=weZPqS0%2BW7nzFUVHRdqcfA%3D%3D; PHPSESSID=721t4sqanvsii550m1dk8gq1o3
Host:api.voidking.com
Referer:http://localhost/ajax/ajax.html
User-Agent:Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36

Antwort-Header lauten:

Access-Control-Allow-Origin:*
Cache-Control:private, max-age=0, no-store, no-cache, must-revalidate
Cache-Control:post-check=0, pre-check=0
Connection:keep-alive
Content-Type:image/png
Date:Sun, 27 Nov 2016 13:26:21 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Pragma:no-cache
Server:nginx
Transfer-Encoding:chunked

Vergleich von drei Anfragen

Für die erste Anfrage zum Erhalten des Bildbestätigungscodes gibt es keine PHPSESSID im Cookie, also Set- In den Rücksendeinformationen ist ein Cookie enthalten. Bei der zweiten Anfrage zum Abrufen des Bildverifizierungscodes enthält das Cookie PHPSESSID, sodass Set-Cookie nicht in den Rückgabeinformationen enthalten ist.

Und die PHPSESSID im Informations-Set-Cookie, das von der ersten Anfrage zurückgegeben wird, ist dieselbe wie die PHPSESSID im Anfrageinformations-Cookie der zweiten Anfrage.

Die Ajax-Anfrage zur Überprüfung des Bildbestätigungscodes enthält kein Cookie und natürlich keine PHPSESSID, sodass die Rückgabeinformationen auch Set-Cookie enthalten.

Es ist ersichtlich, dass wir am Frontend einige Änderungen vornehmen müssen, um die Anfrage mit Cookie zu senden.

Front-End-JQuery-Einstellungen

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <title>jquery</title>
</head>
<body>
    <p>
        <img src="/static/imghw/default1.png"  data-src="http://api.voidking.com/owner-bd/index.php/Home/CheckCode/getPicCode"  class="lazy"   alt="">
        <input type="text" id="picCode">
        <input type="button" id="send" value="验证">
    </p>
<script src="http://apps.bdimg.com/libs/jquery/2.1.4/jquery.min.js"></script>
<script>
    $(function(){
        $(&#39;#send&#39;).click(function(){
            //console.log(document.cookie);
            $.ajax({
                url: &#39;http://api.voidking.com/owner-bd/index.php/Home/CheckCode/checkPicCode&#39;,
                type: &#39;POST&#39;,
                crossDomain: true,
                xhrFields: {
                    withCredentials: true
                },
                dataType: &#39;json&#39;,
                data: {code: $(&#39;#picCode&#39;).val()},
                success: function(data){
                    console.log(data);
                },
                error: function(xhr){
                    console.log(xhr);
                }
            });
        });
    });
</script>
</body>
</html>

Der bei der Anfrage gemeldete Fehler lautet wie folgt:

A wildcard '*' cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true. Origin 'http://localhost' is therefore not allowed access. The credentials mode of an XMLHttpRequest is controlled by the withCredentials attribute.

Ein domänenübergreifender Fehler ist aufgetreten Ich habe gesehen, dass auch das Backend einige Änderungen vornehmen muss, damit es domänenübergreifende Cookies empfangen kann.

Backend-Nginx-Einstellungen

add_header Access-Control-Allow-Origin http://localhost;
add_header Access-Control-Allow-Credentials true;

Hinweis:
Wenn der serverseitige Access-Control-Allow-Credentials-Parameter wahr ist, ist der Access-Control-Allow- Ursprungsparameter Der Wert darf nicht * sein.

Nachdem das Backend-Nginx eingerichtet ist, ist die Ajax-Anfrage von jquery normal und Cookies können übertragen werden. Das Backend empfängt Daten normal und gibt sie zurück.

Da sich die Ajax-Anfrage von Angular von der JQuery unterscheidet, müssen wir auch untersuchen, wie Angular domänenübergreifende Anfragen mit Cookies sendet.

Frontend-Winkeleinstellungen

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>angular</title>
    <script src="http://cdn.static.runoob.com/libs/angular.js/1.4.6/angular.min.js"></script>
</head>
<body ng-app="myApp" >
    <p ng-controller="myCtrl">
        <img src="/static/imghw/default1.png"  data-src="http://api.voidking.com/owner-bd/index.php/Home/CheckCode/getPicCode"  class="lazy"   alt="">
        <input type="text" id="picCode" ng-model="picCode">
        <input type="button" ng-click="send()"  value="验证">
    </p>
<script>
    var app = angular.module(&#39;myApp&#39;, []);
    app.controller(&#39;myCtrl&#39;, function($scope, $http, $httpParamSerializer) {
        $scope.send = function(){
            $http({
                method:&#39;POST&#39;,
                url:&#39;http://api.voidking.com/owner-bd/index.php/Home/CheckCode/checkPicCode&#39;,
                headers:{
                    &#39;Content-Type&#39;:&#39;application/x-www-form-urlencoded&#39;
                },
                withCredentials: true,
                dataType: &#39;json&#39;,
                data: $httpParamSerializer({code: $scope.picCode})
            }).then(function successCallback(response) {
                console.log(response.data);
                $scope.username = response.data.username;
            }, function errorCallback(response) {
                console.log(response.data);
            });
        }
    });
</script>

</body>
</html>

Empfohlenes Tutorial: „TP5“

Das obige ist der detaillierte Inhalt vonLösen Sie das domänenübergreifende Sitzungsproblem in thinkphp. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!