Posts by wanwolf

Auf der Vereinshomepage gibt es Bereiche für alle und auch für spezielle Gruppen. Mit den Feldern in der Kundenverwaltung und dem Navigationsmenü super gelöst.

Auf der Homepage kann jeder eingeloggte Benutzer seine Daten sehen und ändern. Per Mail ist ja auch eine Neuanmeldung über's Frontend möglich. Auch als Administrator kann ich keine anderen Daten ändern/löschen - nur per Listview sehen. Nur wenn ich im Backend/Programm drin bin, kann ich über die Kundenverwaltung alles sehen, ändern, löschen. Ich bin über das Tag <we:customer> gestolpert und dachte, ich könnte das damit lösen - natürlich nur wenn ich die Rechte dazu habe.

Manchmal komme ich in xx/webEdition/index.php nicht rein - Code "500" - aber in xx/index.php. Wenn ich mich dort ein- und auslogge geht's dann wieder...

In einem früheren Programm wurde dies immer (sehr aufwendig) selbst gemacht - aus Komfort- und Sicherheitsgründen ist die Standardlösung besser. Aber schwer zu verstehen.
Die komplette Verwaltung in Frontend wäre schön - aber geht's oder ist's sinnvoll? Neuanmeldung, Rechtevergabe und Initialpasswort in Admin-Seite

Im Listview zu sehen, wer war wann drin ist sehr gut - aber das mit dem OnlineMonitor habe ich auch noch nicht kapiert und hingekriegt. webEdition ist gut, mächtig - aber auch mächtig komplex.

Hallo Sascha,

Danke für die Tipps. Am Schluss habe ich noch meinen eigenen Harakiri entdeckt:

<we:if_registered..> <we:session_logout> ... force="TRUE" sorgt ja für einen sofortigen Logout. Kaum draußen funktioniert's.

Es war mur ein JS-Fehler "win nicht definiert" in rebuild2.js/Zeile 144 und eine Depreciate von curl_close. Jetzt kommt nur - aber es geht...

Error message:

[msg] => Uncaught ReferenceError: win is not defined
[url] => /webEdition/index.php?we_cmd[0]=startWE
[App] => Netscape
[Ver] => 5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36 Edg/147.0.0.0
[UA] => Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36 Edg/147.0.0.0

Liebe Comunity,

ich habe 2 Web-Sites, eine mit zwingendem Login und mit Login für spezielle Bearbeiter. Es hat ein bisschen gedauert, bis ich die Funktion kapiert und zum Laufen gebracht habe - aber die eingebauten Systeme zu verwenden ist in Punkto Sicherheit State-of-the-Art.

Die erste funktioniert - der WE-Tag wird sinnvoll für Username und Password im Browser-Inspektionsfenster dargestellt. Beim Nichtfunktionierenden sind m.E. zu wenig Befehle beim Username dabei. Klar, ohne Username - nur mit Password - kann das System keinen User erkennen. Aber auf Falscheingaben reagiert er richtig mit der LoginFailed-Fehlermeldung.

Ich hatte beim Provider Hetzner zuerst mehrfach die alte Konfiguration "Level 1/4/9" (funktioniert noch, aber hat/braucht ältere PHP) - jetzt "Web S/M/L" und mehrere URLs. WebEdition ist im htdocs/name1 mit Start in htdocs/name1. SSL ist auch ordentlich drin. Die Seiten sind alle dynamisch generiert.

Die nicht funktionierende Webseite verwendet - im Gegensatz zur anderen - fast nur internes WE-HTML/PHP. Die WE-Fehlermeldungen helfen viel weiter. Die andere hatte auch viel externes PHP und Java-Script dazu - da war es auch nötig, PHP-Fehlermeldungen am Bildschirm zu haben.

Jetzt wo ich PHP 8.5 und WE10.1 verwende, komme ich alleine nicht weiter und bin für Hinweise dankbar

mfg
Wolfgang Gruner

Vielen Dank für die Hinweise. Ich habe inzwischen mit der we:Login-Funktion geschafft.

- Der Aufruf muss dynamisch generiert sein und scheinbar zwingend "index.php" heißen
- natürlich mit we:session
- Bei we:Logout muss die ID der index.php dabei sein.

Vieles habe ich auch mit XAMPP gemacht. Die Fehlermeldung "Dear customer, our service is currently not available. Please try again later. Thank you. Sehr geehrter Kunde, aus Sicherheitsgründen ist ein Login derzeit nicht möglich! Bitte probieren Sie es später noch ein mal. Vielen Dank" kommt vom Provider oder von WebEdition? Die Anzahl der Fehlversuche war immer 0/4 in 1h in der Kundenverwaltung angezeigt.

Super dass Sicherheit eingebaut ist - aber ich wüsste gerne wo und wer. 4 Fehlversuche und danach 1h Wartezeit?

Anstatt selbst zu programmieren bieten die WE-Tags oder Providerfunktionen automatisch den "State-of-the-Art".

Danke für die guten Tipps. Das mit den Konstanten hat gut funktioniert. Jetzt stelle ich MySQL auf MySQLi um. Ist etwas Aufwand - aber überhaupt ein Weg.

Die alte Version 6.3.9. ist jetzt nicht mehr updatebar - Der Versuch vor langer Zeit führte in den Totalabsturz. Ich weiß jetzt warum die WE-Login-Funktion und der Selbstbau abstürzen - die globale Variable $GLOBALS['PHP_SELF'] ist bei diesem System (wieder) leer. Submit auf SELF geht damit nicht.

Diesen Effekt habe ich beim Windows-XAMP und einem modernen Linux-System. Bei IONOS und PHP5.6-Support geht dies (noch?). Ist das normal - soll der Login immer in einer Extra-Seite sein?

Die Struktur stelle ich auch gleich von Header- und Footer-Teil-Includes auf Mastertemplate um, damit verstehe ich's (und jeder andere Nachfolger) auch besser

Liebes Forum,

Ich habe ein altes Thema "geerbt" - nach ein paar Tagen/Monaten/... ist endlich der Groschen gefallen - ich habe webEdition kapiert. Danke an Dets-Media. Ich gehe es doch an, von 6.3.9 auf aktuell durch Source-Code-Kopieren umzustellen Das erfordert viel "Handarbeit", vor allem weil My_SQL auf My_SQLi-Befehle umzustellen sind. Die brauchen aber jetzt den Datenbank-Namen, blos wo bekomme ich den her? Bei der Installation wird er ja festgelegt und geöffnet. Im Original war er nicht nötig. Ich habe keinen Hinweis gefunden.

Der Erblasser war ein guter Programmierer - hat viele Tricks drauf. In der Zwischenzeit gibt's aber bessere Möglichkeiten und Strategien.

IONOS unterstützt zwar jetzt noch PHP5.6 - aber wie lange noch....

Mein Provider (IONOS) unterstützt(e) (noch) PHP 5.6 und MySQL5.5. Das schon lange geplante Upgrade wE6.3.4 -> wE6.3.9 -> wE.... -> wE.... bin ich endlich angegangen. Um die Schmierzeichen nach dem Update zu beseitigen, habe ich die DB-Kollision vereinheitlicht und MySQL5.7 verwendet - aber jetzt geht's Update nur auf wE6.3.9. Dies setzt scheinbar PHP7 voraus - auf alle Fälle treten Error-logs von alten mySQL-Aufrufen auf. Neue MySQL5.5 kann ich nicht mehr erstellen

Gibt's noch eine Chance auf Eventuell-Rettung (mit Aufwand), Tricks mit lokalen Systemen (und Update-Server) oder anderen Einstellungen.

Wurde am Update-Server auch geändert? Wer zu spät dran ist, den bestraft das Leben Ich habe mich schon längere Zeit mit wE beschäftigt und mir jetzt das Thema wieder vorgenommen. Ich finde schon die Ursachen im PHP-Log - aber weEdition und den eigenen Code zu bearbeiten trau' ich mir doch nicht ganz zu.