WebsiteBaker Support (2.13.x) > Hilfe & Support (deutsch)

WebsiteBaker auf IIS 10

(1/1)

deb01:
Hallo zusammen,

hat jemand aktuellere Informationen wie sich ein WebsiteBaker 2.13.6 r237 auf MS IIS 10 verhält?
Ich musste ein Backup auf ein derartiges Hosting zurückspielen, das Frontend funktioniert perfekt, Adminlogin ins Backend scheitert aktuell. Nach Eingabe des Passworts erscheint wieder das Login.

Nächster Schritt wäre den Vertrag gegen einen anderen zu tauschen, in der Anleitung steht ja ein Apache Webserver sei das Mittel der Wahl.

Der Umstieg ist aber etwas Aufwand, es wäre die Frage, sieht den scheiternden Login sonst noch jemand mit IIS oder ist das womöglich unabhängig?

Passwort für den Admin wurde bereits neu gesetzt, gemäß FAQ:

--- Code: ---UPDATE `{TABLE_PREFIX}users` SET `password`=MD5('{NEW_PASSWORD}') WHERE `user_id`=1
--- End code ---

Auch interessant:
SELECT login_when FROM `users` where username = "admin"  zeigt den aktuellen Zeitstempel, laut Datenbank hat der Login geklappt.

PHP Version 8.3.15

Danke und Gruß
Bernd

sternchen8875:

--- Quote ---es wäre die Frage, sieht den scheiternden Login sonst noch jemand mit IIS oder ist das womöglich unabhängig?
--- End quote ---

In der Vergangenheit wurden solche Anfragen mit dem Hinweis auf die Requirements beantwortet.
Ich versuch es mal ausführlicher. Hauptproblem ist (eigentlich schon immer) die "Übersetzung" von Zeichen innerhalb von PHP. Dabei geht es nicht um Sonderzeichen wie ä, ö oder ü, sondern eher um \ oder / oder auch nur einen Punkt. Das Gleiche gilt dann auch für MySql, z.b. mit einem Bindestrich im Tabellennamen.
Für den Code würde es bedeuten, das man praktisch zweigleisig fahren müßte, um beiden Systemen gerecht werden zu können.

Wo dein Login scheitert, kann man nur raten. Das Grundprinzip ist dabei recht einfach:

* Sende die Login-Daten, das sind mal mehr, mal weniger Daten, je nachdem, wo du dich einloggst, Front- oder Backend, mit oder ohne Captcha usw.
* Prüfe diese Daten, z.b. auf erlaubte Zeichen für Passwort und Username oder die Korrektheit des Captchas, wenn gesendet
* Prüfe, bin ich im Front- oder Backend
* Prüfe, ob es diesen User in der Datenbank gibt
* Wenn JA, lese seine Daten und aktualisiere sie (umfangreich von Zeitzone bis Gruppenrechte), ist alles ok, erstelle eine Session für diesen User, setze den Authenticated-Status
* Gibt es auf diesem Weg irgendwo ein NEIN, leite ihn zurück zum Login
Nun könnte man Schritt für Schritt nachgehen, wo es hakt. Meine Vermutung ist das Auslesen der Userdaten aus der DB und das Setzen des Authenticated-Status. Dieser wirkt praktisch wie ein Schalter, der den User als Legalen Nutzer im Backend freigibt, ein Schalter, der sich durch das komplette Backend zieht und auch im Frontend wirkt, wenn es dort um geschützte Bereiche geht.
Es gibt aber im gesamten Backend kaum eine einzelne PHP-Datei, die ohne eine Datenbank-Abfrage auskommt und es ist gut möglich, das dein gescheiterter Login nur der Auftakt für noch viel mehr solcher Probleme ist.
Wir haben weder das Personal, noch die technischen Möglichkeiten, WebsiteBaker für beide Server-Systeme funktionssicher zu programmieren und deshalb war die Empfehlung auf Apache seit Beginn Bestandteil von WB. Grundsätzlich denke ich, das es in Zukunft eher noch schwieriger wird, eine Anwendung für beide Server-Typen kompatibel zu halten. Schreibweisen und Deklarationen werden immer stricter, ein simpler Backslash ("\") hat unter Windows Server immernoch eine andere Bedeutung, oft als Escape-Zeichen benutzt bei Eingaben oder zur Kennzeichen von Literalwerten, in WB aber hundert- oder tausendfach als Teil von Namespaces verwendet. Das ließe sich jetzt eine Weile fortführen....

Ich weiß nicht, was ich dir nun empfehlen soll - na klar, der Verweis auf die Mindestanforderunge n. Sagt sich aber leicht, wenn man nicht in der Verantwortung steht. Auch, wenn ein Experte ein WebsiteBaker-System auch ohne Adminbereich pflegen könnte, ist das ja nicht der Sinn eines CMS.
Von außen aus gesehen, sollte ein Servertausch nach Vertragsänderung nicht mehr Aufwand bedeuten als ein Umzug zu einem anderen Provider, d.h. Backup der gesamten Dateien, Backup der Datenbank, beides auf neuem Server wieder einspielen, ggf ein paar Daten anpassen in der config.php
Aber es fehlt mir da jegliche Erfahrung, verzeih bitte, wenn ich da etwas übersehe oder falsch deute.

Abraten würde ich davon, nun durch Codeanpassungen zu versuchen, das Ganze wieder zum Laufen zu bekommen. Das ist oft nur eine kurzfristige Angelegenheit. Im Gegensatz zu früher sind die Provider nun schon bemüht, jede neue PHP-Version schnellstmöglich auch zugänglich zu machen und nicht jeder hat es selbst in der Hand, die auch auszuwählen.

Laß bitte von dir hören, wie es weitergeht

Navigation

[0] Message Index