[SOLVED] backend login unter IPv6 geht nicht

[gent]

hallo,

ich habe 2 Server,... mit Server A kann nur per IPv4 gesprochen werden, Server B kann IPv4 und auch IPv6.
Beide Server sprechen https per letsencrypt.

Jetzt habe ich ein phpwcms von Server A auf Server B kopiert. Im DNS habe ich die Domain der Seite zusätzlich zu den geänderten IPv4 -Adressen auch mit den AAAA-Records des IPv6 bestückt. Das phpwcms ist also sowohl über IPv4 als auch per IPv6 des Server B erreichbar.

Ich habe 2 Clients auf die Seite geschickt. Einen per IPv4 und den anderen per IPv6. Die Webseite wird auf beiden Rechnern geladen. Nur,.. mit dem IPv6 kann ich mich nicht im Backend anmelden. Nach Eingabe des Passwortes wird die Startseite der Webseite geladen. Wenn ich im DNS die AAAA-Records lösche, das CMS also nur noch per IPv4 erreichbar ist, dann klappt der login, weil mein IPv6-client auf IPv4 umschaltet.

Die clients sind Macs und IOS-Geräte. Ich glaube nicht, das es an den Clients liegt. Ich habe die Vermutung, das ich irgendwas in der Server-Config übersehen habe. Ich weiß nur nicht was :/

Im Error.log des Webservers erscheint keine fehlermeldung.

Ich meine aber auch, das ich hier im Forum schon einmal dieses Startseite-laden bei fehlerhaftem Backend-Login gelesen habe. Aber auch diesen Beitrag finde ich nicht mehr.

Hat jemand einen tip, oder kann sich an diesen fehler von früher erinnern?

[Oliver Georgi]

Habe lokal getestet, bei mir läuft das Login über IPv6

[gent]

Ich habe jetzt einen clean Install des phpwcms-1.8.4 probiert.
Im Schritt "6. Superuser settings", gebe ich meinen gewünschten Login ein, es erscheint der Button "Continue", aber wenn ich in die mysql-Tabelle phpwcms_user sehe, wurde der Datensatz nicht angelegt.

Der virtualhost test.domain.com ist nur per IPv4 erreichbar, um erstmal eine Basis für die Fehlersuche zu bekommen.

im httpderror.log steht folgendes:

Code: Select all

[Fri Sep 30 09:52:45.589869 2016] [:error] [pid 18902] [client xxx:62093] PHP Warning:  require_once(/usr/local/www/htdocs/test.domain.com/include/config/conf.inc.php): failed to open stream: No such file or directory in /usr/local/www/htdocs/test.domain.com/login.php on line 39, referer: https://test.domain.com/setup/setup.php?step=1
[Fri Sep 30 09:52:45.589956 2016] [:error] [pid 18902] [client xxx:62093] PHP Fatal error:  require_once(): Failed opening required '/usr/local/www/htdocs/test.domain.com/include/config/conf.inc.php' (include_path='.:/usr/local/share/pear') in /usr/local/www/htdocs/test.domain.com/login.php on line 39, referer: https://test.domain.com/setup/setup.php?step=1
[Fri Sep 30 09:52:49.938342 2016] [:error] [pid 18902] [client xxx:62097] PHP Warning:  require_once(/usr/local/www/htdocs/test.domain.com/include/config/conf.inc.php): failed to open stream: No such file or directory in /usr/local/www/htdocs/test.domain.com/login.php on line 39
[Fri Sep 30 09:52:49.938392 2016] [:error] [pid 18902] [client xxx:62097] PHP Fatal error:  require_once(): Failed opening required '/usr/local/www/htdocs/test.domain.com/include/config/conf.inc.php' (include_path='.:/usr/local/share/pear') in /usr/local/www/htdocs/test.domain.com/login.php on line 39

[Oliver Georgi]

Pfade scheinen falsch konfiguriert zu sein. Unter Umständen auch eine Fehlkonfiguration in Verbindung mit PHP-FPM. Rechte.

Liegt aber nicht an phpwcms, wage ich mal ganz kess zu behaupten.

[gent]

Ich suche weiterhin verzweifelt nach der Ursache für das Problem, bin jedoch noch nicht weiter gekommen.
Heute habe ich etwas anderes rausgefunden. Ich habe ein laufendes phpwcms 1.7.6 von dem v4-Server auf den v6-Server kopiert, dabei habe ich um besser vergleichen zu können folgendes eingestellt:

- beide Seiten werden nur per IPv4 aufgerufen
- beide Seiten benutzen ein letsencrypt-zert
- der alte Server antwortet auf http://WWW.domain.de während der neue nur auf domain.de (ohne www) reagiert

Im alten Server kann ich mich im Backend anmelden, ohne Probleme - wie schon immer.
Beim neuen Server klappt das nicht. Ich werde nach dem Anmeldeversuch auf die Startseite der Webseite umgeleitet.
Ich habe das mit Mac Safari und mit google Chrome probiert, es dürfte nicht am browser liegen, sondern eher am Server.

Merkwürdig finde ich:
Bei google Chrome kann ich beim Klick auf das SSL-Schloß in der Adresszeile Informationen abfragen, u.a. auch über die Cookies.
Bei beiden Seiten steht, das 2 Cookies für die jeweilige Seite installiert wurden, jedoch wird auf dem alten Server nur ein Cookie angezeigt. "PHPSESSID" auf die domain: http://www.domain.de
Auf dem neuen Server (wo die Anmeldung nicht klappt) werden zwei Cookies angezeigt:
- das PHPSESSID auf die Domain "domain.de" und außerdem ein
- phpwcmsBELang auf die Domain ".domain.de"

Ich habe die Vermutung, das etwas mit diesen Cookies nicht stimmt. Aber keine Ahnung was und wo ich suchen muss.

Das verhalten, das ich nach login auf die Startseite der Webseite umgeleitet werde, ist identisch mit gemachten Beobachtung unter IPv6.

Hat jemand eine Idee, wo ich suchen muss?

Ach, wichtig ist noch zu erwähnen, das ich mehrere andere phpwcms-Installationen problemlos vom v4- auf den v6-Server bewegen konnte und dort auch der Login im Backend klappt. Allerdings immer nur unter v4, nicht unter v6.

[Oliver Georgi]

Solange Du nicht im Backend angemeldet bist, wird auch der Cookie phpwcmsBELang nicht angelegt. Das ist also OK.

Session-Cookie ist Systemstandard.

Schau einfach, ob die Konfiguration der Domain/URL $phpwcms['site'] zur htaccess passt, zum Protokoll (http/https) usw. Die Subdomain www.example.com ist NICHT identisch mit example.com.

Kann sein, dass der neue Server schlicht eine Weiterleitung forciert (z.B. Plesk Host Konfiguration), das aber in der config Deine phpwcms nicht korrekt behandelt wird, und so das Weiterleiten nach Login am Backend wieder zu einem Redirect führt, was die Login-Session zusammenbrechen lässt.

[gent]

ich habe jetzt folgendes probiert:

Auf dem neuen Server habe ich 2x phpwcms, beide sind vom alten Server kopiert worden, beide sind Version 1.7.6.
Bei dem einen funktioniert der Login im Backend bei dem andern nicht.

Ich habe in der config des funktionierenden phpwcms die mysql-daten des fehlerhaften phpwcms eingegeben - der login klappte jetzt nicht mehr, nachdem ich wieder die original-mysql-daten eingegeben habe, kann ich mich im backend wieder anmelden. Ich glaube das zeigt mir, das es nicht an der httpd.config liegt, auch nicht am mod_rewrite oder sonst einer webserver-config. Oder irre ich hier?

dann habe ch folgendes getestet:
Ich habe in der httpd.conf einfach den DocumentRoot von dem funktionierenden auf den defekten zeigen lassen, auch hier funktionierte der Login nicht mehr.

Ich glaube das Problem liegt irgendwo innerhalb der mysql-tabellen. Eventuell habe ich bei dem defekten phpwcms in der Vergangenheit ein Versionsupdate nicht ordentlich hinbekommen?

[Oliver Georgi]

Lies doch mal bitte was ich geschrieben habe. Prüfe, ob Du nicht irgendwo eine unglückliche Weiterleitung systemseitig benutzt! Verbiege www nach nicht-www oder umgekehrt aber eine hart codierte URL in $phpwcms['site'] hinterlegt hast. Stimmt das erwartete Protokoll? Das Frontend ist mit der Einstellung toleranter, das Backend in keiner Weise, da nach Login zur definierten URL hart weitergeleitet wird.

Das Login müsste selbst mit schiefer Datenbank laufen, da hier seit ewigen Zeiten keinerlei Design-Änderungen stattgefunden haben. Oder Deine Datenbank ist komplett kaputt.

Hast Du eine .htaccess mit ReWrite? Funktioniert das Frontend?

[top]

Wenn ich OG richtig verstehe, geht es um diese Zeilen in der conf.inc.php:

Code: Select all

...

// site values
$phpwcms['site']                = ''; // leave empty to auto configure or try 'http://'.$_SERVER['SERVER_NAME'].'/';
$phpwcms['site_ssl_mode']       = 0; // turns the SSL Support of WCMS on (1) or off (0), default value 0
$phpwcms['site_ssl_url']        = ''; // URL assigned to the SSL Certificate. Recommend 'https://'.$_SERVER['SERVER_NAME'].'/'
$phpwcms['site_ssl_port']       = 443; // The Port on which your SSL Service serve the secure Sites, default SSL port is 443

...

[Oliver Georgi]

Achtung, er benutzt 1.7.x – dort MUSS $phpwcms['site'] einen Wert haben, ist nicht selbstkonfigurierend. Am besten:

Code: Select all

$phpwcms['site'] = 'http://'.$_SERVER['SERVER_NAME'].'/';
$phpwcms['site_ssl_mode'] = 0; // turns the SSL Support of WCMS on (1) or off (0), default value 0
$phpwcms['site_ssl_url'] =  'https://'.$_SERVER['SERVER_NAME'].'/';
 

Wenn SSL erzwungen, dann am besten so:

Code: Select all

$phpwcms['site'] = 'https://'.$_SERVER['SERVER_NAME'].'/';
$phpwcms['site_ssl_mode'] = 1; // turns the SSL Support of WCMS on (1) or off (0), default value 0
$phpwcms['site_ssl_url'] =  'https://'.$_SERVER['SERVER_NAME'].'/';
 

[gent]

die conf.inc.php sieht bei mir normalerweise so aus:

Code: Select all

$phpwcms['site']              = 'http://'.$_SERVER['SERVER_NAME'].'/';
$phpwcms['site_ssl_mode']     = 1; 
$phpwcms['site_ssl_url']      = 'https://'.$_SERVER['SERVER_NAME'].'/'; 
$phpwcms['site_ssl_port']     = 443; 

in der .htaccess schreibe ich normalerweise nichts rein, die ist standard vom phpwcms übernommen

in der virtualhost config vom apache schreib ich eine umleitung von port 80 auf 443 rein, das sieht so aus:

Code: Select all

#<IfModule mod_rewrite.c>
#	RewriteCond %{HTTPS} !=on
#	RewriteRule ^/?(.*) https://%{HTTP_HOST}/$1 [R,L]
#</IfModule>

ich hab es jetzt auch wie folgt probiert,
- SSL im virtualhost abgestellt,
- im apache das mod_rewrite abgestellt (auskommentiert), sodass kein rewrite mehr von 80 auf 443 gemacht wird
- die .htaccess umbenannt in _.htacess

. dann habe ich die conf.inc.php wie folgt geändert:

Code: Select all

$phpwcms['site']              = 'http://'.$_SERVER['SERVER_NAME'].'/';
$phpwcms['site_ssl_mode']     = 0; 
$phpwcms['site_ssl_url']      = ''; 
$phpwcms['site_ssl_port']     = 443; 

$phpwcms['rewrite_url']       = 0;

ich meine so sieht die conf.inc.php auch bei einem clean-install aus.

es bleibt dabei, der login klappt nicht, ich glaube es liegt an irgendeiner umleitung die das anlegen des 2. cookies blockiert. dieses phpwcmsBElang, dieses cookie bekomm ich auf dem alten server nicht gesetzt, obwohl ich mich mit dem gleichen cms, der gleichen conf.inc.php, der gleichen apache-config anmelde.

und ich meine, weil meine conf.inc.php keine domain-angaben hat, also nirgends domain.de steht, sondern immer nur $_SERVER['SERVER_NAME'], und ich durch austauschen der mysql-daten in der conf.inc.php direkt mit einem anderen cms verbinden kann und dann der login klappt. ...

deswegen denke ich, das ich irgendwo in der mysql-datenbank ein problem habe.
komisch nur, das die gleiche mysql-db auf dem alten server läuft.

ich kann mich im alten server im backend anmelden und werde dort jeden einzelnen menupunkt checken und mit einer anderen installation (die auch auf dem neuen server läuft) vergleichen. oder .. mir ist auch schon in den sinn gekommen, einen clean-install zu machen und dort aus dem mysql-dump nur die tabellen einzuspielen, die ich benötige.

allerdings werde ich den gedanken nicht los, das es einzig und allein an einer profil-einstellung des benutzers ist, der sich einlogen möchte, irgendeine sprach-einstellung des admin-accounts die zum anlegen des 2. cookies führt .. wo sich das ganze dann aufhängt. vielleicht kann php irgendeine language-DE-wasweißich nicht laden. vielleicht kopier ich mir die user-zeile eines admins aus einem anderen cms und dann gehts wieder ?

falls ihr ideen habt, wär ich wie immer dankbar
wenn ich etwas aus meiner config posten soll, bitte ansagen, mach ich gern.

[Oliver Georgi]

Prüfe mal, ob Du noch ein nginx zwischengeschaltet hast.

Wenn Du eh SSL erzwingst, kannst Du auch nur das setzen,

Code: Select all

$phpwcms['site'] = 'https://'.$_SERVER['SERVER_NAME'].'/';
$phpwcms['site_ssl_mode'] = 0; 
$phpwcms['site_ssl_url'] = ''; 

Sonst hilft nur die Fehlerlogs zu prüfen, denn irgendwas muss Fehler schmeißen, wenn es nicht geht.

[gent]

Ich hab kein nginx, ich hab ein FreeBSD mit Apache24 und php5.6.27.

Ich hab in der php.ini error.log angemacht:

Code: Select all

error_log = /var/log/php-error.log
display_errors = Off
log_errors = On
error_reporting = E_ALL

Da kommen auch eine menge PHP Deprecated Meldungen aus einem anderen phpwcms. Aber wenn ich mich erfolglos im Backend nicht-anmelden kann, kommt keine error-Meldung im php-error.log.

Dann habe ich die php.ini im system umbenannt, dadurch werden die Fehler direkt auf der Webseite angezeigt, da kam dann folgendes:

Code: Select all

Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /usr/local/www/htdocs/domain.de/include/inc_lib/default.inc.php on line 439

Warning: Cannot modify header information - headers already sent by (output started at /usr/local/www/htdocs/domain.de/include/inc_lib/default.inc.php:439) in /usr/local/www/htdocs/domain.de/include/inc_lib/backend.functions.inc.php on line 585

Warning: Cannot modify header information - headers already sent by (output started at /usr/local/www/htdocs/domain.de/include/inc_lib/default.inc.php:439) in /usr/local/www/htdocs/domain.de/include/inc_lib/backend.functions.inc.php on line 585

Warning: Cannot modify header information - headers already sent by (output started at /usr/local/www/htdocs/domain.de/include/inc_lib/default.inc.php:439) in /usr/local/www/htdocs/domain.de/include/inc_lib/default.inc.php on line 693

Der erste is klar, weil keine timezone gesetzt ist. Aber bei den folgenden muss ich passen. Ich hab keine Ahnung was da passiert.

Außer den Fehlermeldungen steht nichts auf der ansonsten weißen Seite.

[Oliver Georgi]

Schwer zu beantworten, setze die Zeitzone. Dann durchhangeln.

[gent]

Ich habe eine php.ini mit nur einer Zeile gesetzt, der timezone, beim login-versuch wurden keine Fehler mehr angezeigt, der login klappte aber wieder nicht.

Ich glaub langsam auch nicht, das es was mit meiner Server-konfiguration zu tun hat.

Ich habe 2 gleiche Versionen (1.7.6) des phpwcms auf der gleichen Maschine laufen.
Mit dem einen kann ich mich anmelden, mit dem anderen nicht.
Jetzt gehe ich zu dem cms wo ich mich nicht anmelden kann, öffne die conf.inc.php und geb dort die mysql-Zugangsdaten des andreren cms an. Und schon kann ich mich mit den entsprechenden Zugangsdaten anmelden.
Es muß etwas in der mysql-datenbank stecken, das den login verhindert. Die Server-Konfiguration habe ich ja nicht verändert.

Ich habe die Tabelle _user gelöscht und aus dem funktionierenden cms die tabelle _user importiert. Das war es nicht, der login klappte wieder nicht.
Beim Vergleichen der beiden Datenbanken ist mir aufgefallen, das die funktionierende db einige andere Tabellen besitzt. so zum bsp _ads_campaign. ich vermute sehr stark, das ich bei einem Upgrade irgendwann mal ein mysql-Update falsch gemacht (einen Schritt vergessen) habe.

Ich hab jetzt zwei Ideen, wie ich weiter suchen werde.
1) ich kopier mir noch einmal den setup-ordner in den webroot und führe einfach alle mysql updates nochmal aus
oder
2) ich leere nacheinander den Inhalt aller mysql-Tabellen und prüfe nach jedem Leeren ob der Login klappt.