Test v1.1 beta

[shadowcat]

Der IE11 zeigt bei mir die Seite sowohl über http als auch über https (nach Wegklicken der Warnungen) sauber an, mitsamt aller Bilder. Die erste Warnung ist bezüglich des Zertifikats, die zweite wegen gemischtem Inhalts. ("Nur sicherer Inhalt wird angezeigt" -> auf [Gesamten Inhalt anzeigen] klicken) Das betrifft dann aber das CSS, nicht die Bilder.

[Friedemann]

Mit der Pfadeintragung in cat_class_secure, der Änderung der config.php plus der neuen ajax_check_ssl.php ist Anmelden in meinem "Hauptserver" (mit SSL, aber für anderen Host) möglich - kein Weiterleitungsversuch nach https. Also wie Du Dir wohl vorgestellt hattest: "{"success":false}".

Nur der Vollständigkeit halber :
- Mit einer früheren Version der ajax_check_ssl.php oder "true" in der config.php bei bestehendem DB-Eintrag erfolgt wie gehabt die Weiterleitung http --> https --> 404.
- Mit der aktuellen ajax_check_ssl.php (10.11.14, 12.54) und DB-Eintrag ist der Eintrag in der config.php nicht notwendig; es wird trotzdem nicht nach https umgeleitet.
- Mit der ajax_check_ssl.php, aber ohne DB-Eintrag und ohne config-Eintrag kommt die Anmeldung normal, Firebug liefert aber:

Code: Alles auswählen

POST http://bc11/backend/login/ajax_check_ssl.php	403 Forbidden		jquery....min.js (Zeile 4)
<p><strong style="color:#f00;">ACCESS DENIED!</strong> - Invalid call of <i>/backend/login/ajax_check_ssl.php</i></p>
"NetworkError: 403 Forbidden - http://bc11/backend/login/ajax_check_ssl.php"		ajax_c...ssl.php

- Das gleiche mit config-Eintrag false, mit neuer ajax_check_ssl.php, aber ohne DB-Eintrag.

Nachfrage: Gibt es eigentlich irgendeine Datei oder sonstige Stelle, aus der die jeweilige Build-Nr. / Rev.-Nr. hervorgeht? Der DB-Eintrag in cat_settings -> cat_build ist bei mir leer - ist das (noch) normal? Hat sich - außer dem hier beschriebenen - seit der Version vom 30.10. etwas geändert, dass eine komplette Neuinstallation sinnvoll wäre? Oder einfach die aktuelle ziehen, drüber kopieren, gut ist?
Letztens: gibt es hier irgendeine Stelle, wo bekanntgegeben wird, dass auf Github etwas Neues ist?

Aus der Wiki-Seite zu SSL:

BlackCat versucht, nach einer positiven Antwort aus den Serverdaten eine SSL-Verbindung herzustellen. In Umgebungen mit vhosts (virtuellen Hosts, einer Konfiguration des Webservers) kann je nach Konfiguration ein falsches Ergebnis vorkommen.

Hattest Du Deine Tests immer in einer Server-Umgebung, wo die derzeitige Entwicklungsversion der einzige Host war, also keine vhosts eingerichtet waren, um mehr als eine Version / ein System auf einem Server laufen lassen zu können? Ich dachte, die vhost-Lösung (namensbasiert) wäre die übliche Variante, um sich langweilende Server bei IP-Knappheit auszunutzen - oder nicht allzu viele virtuelle Maschinen zu brauchen.
Ich bezweifle, dass das Ganze an der Konstruktion "vhost" hängt, sondern eher daran, dass dabei wohl nur für einen Host SSL sich scharf schalten lässt, (es sei denn, man nimmt IP-basierte vhosts - wohl eher unüblich). Keine Ahnung, wie das die großen Hoster machen, die hunderte Hosts auf einer Maschine / einer IP laufen lassen und trotzdem allen SSL anbieten.
Ich werd' mir mal in einer weiteren virtuellen Maschine noch einen XAMPP einrichten, wo dann nur BC1.1 läuft, mit standardmäßiger SSL-Einrichtung ohne weitere Verrenkungen (sprich ausdrückliche Aktivierung): dann müssten beide Prüfungen positiv ausfallen und das BE mit SSL und das FE ohne laufen. Mal sehen...

[shadowcat]

Nachfrage: Gibt es eigentlich irgendeine Datei oder sonstige Stelle, aus der die jeweilige Build-Nr. / Rev.-Nr. hervorgeht?

Nur in der Datenbank. Im ZIP liegt im Verzeichnis install eine Datei tag.txt, die die Informationen beinhaltet. Da das Verzeichnis nach der Installation (beim ersten Login) automatisch gelöscht wird, kannst Du da hinterher nicht mehr nachschauen. Wenn Du das ZIP noch hast, kannst Du natürlich dort nachsehen. Für händisch nachgefuddelte Dateien gibt's natürlich keine Buildnummern.

Streng genommen gibt es bei Git-Repositories sowieso keine Buildnummern. Fortlaufende Nummerierungen gibt es nur bei SVN und Co. Wir verwenden daher den Tag, den Git intern vergibt - er ergibt sich aus dem Tag selbst (einfach eine Zeichenkette, wie "1.1Beta"), der Anzahl der Commits seit dem Setzen des Tags und der ID des letzten Commits, jeweils durch Bindestriche getrennt. Eigentlich ist diese "Buildnummer" für uns völlig irrelevant, wir befriedigen da eher ein Bedürfnis der Benutzer, die das von WB und anderswo kennen.

Hat sich - außer dem hier beschriebenen - seit der Version vom 30.10. etwas geändert, dass eine komplette Neuinstallation sinnvoll wäre? Oder einfach die aktuelle ziehen, drüber kopieren, gut ist?

Seit der Beta gab es drei Commits, zwei davon betreffen den Installer. So gesehen mag sich eine Neuinstallation mit dem aktuellen GitHub Master lohnen, allerdings nicht für dieses Thema hier. Der Installer macht halt jetzt das selbe wie die ajax_check_ssl.php und fragt zusätzlich ab, ob SSL aktiviert werden soll. (Nur wenn das Prüfergebnis positiv ist, ansonsten macht das eh keinen Sinn.) Das Ergebnis landet in dem beschriebenen Eintrag in der config.php und kann dann notfalls nachträglich geändert werden. Oder z.B. auch, wenn SSL hinzugebucht wird und später zur Verfügung steht.

Letztens: gibt es hier irgendeine Stelle, wo bekanntgegeben wird, dass auf Github etwas Neues ist?

Hier im Forum, sofern es mir relevant erscheint, ansonsten nur bei GitHub selbst. GitHub ist üblicherweise nur die Quelle für Tester, freigegebe Versionen stellen wir ja auf die Homepage. Üblicherweise interessieren ja nur die Releases (da schließe ich Alpha- und Beta-Versionen mit ein), nicht die alltäglichen Commits. Wer die auch haben will, klont das Repository und macht täglich einen Pull. Das ist aber IMHO eher was für Entwickler.

Hattest Du Deine Tests immer in einer Server-Umgebung, wo die derzeitige Entwicklungsversion der einzige Host war, also keine vhosts eingerichtet waren, um mehr als eine Version / ein System auf einem Server laufen lassen zu können?

In meiner lokalen Umgebung gibt es keine vhosts. Wozu auch? Ich kann auch auf einem einzigen Host beliebig viele Installationen und Versionen parallel laufen lassen. Ich habe z.B. jeweils zwei 1.0.x und 1.1 parallel (je eine für Entwicklung und eine für Installationstests), sowie etliche 1.1 Installationen, die Entwicklungsumgebungen für Produktivseiten sind. (kitFramework, mein neues Addons-Repository, usw.)

Keine Ahnung, wie das die großen Hoster machen, die hunderte Hosts auf einer Maschine / einer IP laufen lassen und trotzdem allen SSL anbieten.

Naja, eigentlich ist das ganz einfach: Der Webserver selber - also Apache - kann SSL. Das heißt aber nicht, daß es auch aktiviert ist. Nun kann man für Kunden, die SSL bezahlen, in deren Konfiguration SSL einschalten und das entsprechende Zertifikat eintragen. Und bei allen anderen eben nicht. Daher ist es auch so schwer, herauszufinden, ob denn nun https verfügbar ist oder nicht.

Die einfachste und naheliegendste Idee wäre ja, per AJAX zu versuchen, die lokale URL mit https aufzurufen. Entweder das klappt, oder es klappt nicht. Leider klappt das aber nie - aus Sicherheitsgründen. https://de.wikipedia.org/wiki/Same-Origin-Policy

[Friedemann]

Build-Nr. / Rev.-Nr.:

Nur in der Datenbank.

Wo denn da? In der Tabelle cat_settings gibt es die Einträge cat_version (ist auch in 1.1 gefüllt) und cat_build (ist auch in 1.0.4 leer, wie auch in 1.1). Eine andere Stelle habe ich nicht gefunden.

Wenn Du das ZIP noch hast, kannst Du natürlich dort nachsehen.

Hebe ich immer auf, ergänzt mit dem Datum. Wer weiß, wozu das mal gut ist: vergleichen, zurückdrehen, ...

Eventuelle Github-Bekanntgaben vermute ich dann mal im News-Bereich?

vhosts:

In meiner lokalen Umgebung gibt es keine vhosts. Wozu auch? Ich kann auch auf einem einzigen Host beliebig viele Installationen und Versionen parallel laufen lassen.

Na gut, wenn man mit Unterverzeichnissen für die verschiedenen Installationen arbeitet.
Irgendwann wollte ich mal etwas mehr Ordnung reinbringen und bin dann auf die vhost-Lösung gestoßen. Seitdem richte ich für jede neue Installation fix einen neuen vhost ein mit einem sprechenden Namen (die httpd-vhosts.conf muss ich nicht mehr lange suchen), mache einen Eintrag in meinem lokalen DNS-Server und kann dann von allen virtuellen und echten Rechnern aus zufassen.
Ich halte damit die Adresse so kurz, wie es im echten "Leben" auch wäre. Außerdem sollte es dann keine Nebeneffekte geben können durch Browsercache o.ä., weil ja eine andere Adresse aufgerufen wird - erschien mir als insgesamt sauberste Lösung.

Ich werde auch mal testen, wie sich die SSL-Geschichte in einem Unterverzeichnis meines SSL-vhost verhält.

Keine Ahnung, wie das die großen Hoster machen, die hunderte Hosts auf einer Maschine / einer IP laufen lassen und trotzdem allen SSL anbieten.

Naja, eigentlich ist das ganz einfach: Der Webserver selber - also Apache - kann SSL. Das heißt aber nicht, daß es auch aktiviert ist. Nun kann man für Kunden, die SSL bezahlen, in deren Konfiguration SSL einschalten und das entsprechende Zertifikat eintragen. Und bei allen anderen eben nicht.

So hatte ich mir das schon gedacht, aber: die werden doch mit vhosts arbeiten, und hatte damals gelesen, dass SSL nur für einen der vhosts möglich sei.
Ich habe bisher nicht herausgefunden, wie ich beliebig viele vhosts unter einer IP / einem Server mit SSL versorgen kann.

Leider klappt das aber nie - aus Sicherheitsgründen. https://de.wikipedia.org/wiki/Same-Origin-Policy

Danach dürfte doch auf keiner meiner BC1.1-Installationen (die allesamt nicht unter SSL laufen) und in keinem Browser die Willkommensseite mit den von "https://raw.github.com/webbird/LEPTON_2 ... reenshots/" eingebundenen Bildern komplett dargestellt werden - das ist in jedem Fall ein anderer Host und ein anderes Protokoll.
???

Herzliche Grüße, Friedemann

[shadowcat]

Build-Nr. / Rev.-Nr.:

Nur in der Datenbank.

Wo denn da? In der Tabelle cat_settings gibt es die Einträge cat_version (ist auch in 1.1 gefüllt) und cat_build (ist auch in 1.0.4 leer, wie auch in 1.1). Eine andere Stelle habe ich nicht gefunden.

Eben da.

Eventuelle Github-Bekanntgaben vermute ich dann mal im News-Bereich?

Meistens, oder im Thread, wenn es einen gibt. Wie gesagt, ist eher selten und betrifft dann auch nur einen sehr kleinen Benutzerkreis.

Ich habe bisher nicht herausgefunden, wie ich beliebig viele vhosts unter einer IP / einem Server mit SSL versorgen kann.

Global aktivieren. Das Problem sind eher die Zertifikate, die müssen pro Domain generiert werden. Provider haben dafür ihre Umgebung.

Danach dürfte doch auf keiner meiner BC1.1-Installationen (die allesamt nicht unter SSL laufen) und in keinem Browser die Willkommensseite mit den von "https://raw.github.com/webbird/LEPTON_2 ... reenshots/" eingebundenen Bildern komplett dargestellt werden - das ist in jedem Fall ein anderer Host und ein anderes Protokoll.

Das wiederum hängt vom Browser und seiner Konfiguration ab. Ist halt kein einfaches Thema.

[Friedemann]

Schneller Test mit der Version vom 18.11. (http://blackcat-cms.org/media/download/ ... .1Beta.zip):

Scheint soweit zu laufen (vhost unter XAMPP, ohne SSL), Anmeldung nach Änderung der config.php (SSL=false) geht.
- CKE läßt sich installieren, Bilderauswahl funktioniert mit der angepaßten config.php von hier . Allerdings werden - ohne erkennbaren Grund - einige Bilder nicht als Bild erkannt, nur die Dateigröße wird angezeigt. In der Medienverwaltung werden alle Bilder gefunden. Bei den nicht erkannten Bildern endet der Pfad mit "/media/".
- Schön, dass das Widget zum Wartungsmodus drin ist, auch, dass man nun auch mit schmaleren Bildschirmen arbeiten und sich ausloggen kann.
- Das hier unter 6. beschriebene Verhalten, dass der "Webseite-Kopf" (Einstellungen > Frontend Einstellungen > Webseite Kopf) im Content-Bereich statt in der Kopfzeile auftaucht, besteht noch. Weil wir das letztens nicht weiter geklärt hatten, hier mal ein paar Bilder:

So sieht es im FE aus:

BC11-Kopf_FE.PNG (64.88 KiB) 4686 mal betrachtet

Das ist ein Stück aus der Einstellungsseite:

BC11-Kopf_BE_Einstellungen.PNG (3.87 KiB) 4686 mal betrachtet

und so im Editor:

BC11-Kopf_BE.PNG (9.84 KiB) 4686 mal betrachtet

Der Vergleich mit der entsprechenden Stelle aus BC 1.0.4 geht erst in einem nächsten Beitrag; mehr als drei Anhänge sind wohl nicht möglich.

Im Dashboard wird eine Warnung ausgegeben "Keine Mailbibiliotheken installiert!", obwohl PHP mail verfügbar und in den Einstellungen konfigurierbar ist. Funktioniert auf diesem XAMPP mit anderen vhosts auch, allerdings nicht in BC. Dem muss ich noch gründlicher nachgehen.

Weitere Tests, auch mit anderen Servern, folgen auch noch.
Herzliche Grüße, Friedemann

[Friedemann]

Hier noch das versprochene Bild vom Webseite-Kopf aus BC 1.0.4:

BC104-Kopf_FE.PNG (58.98 KiB) 4685 mal betrachtet

Gute Nacht für heute.

[shadowcat]

Das ist schon komisch, weil das nämlich Mojito aus 1.0.4 _ist_.

Zu den Mailbibliotheken: Du mußt entweder PHPMailer oder Swift installieren, damit die Meldung weg geht. Die Einstellungen haben ohne installierte Mailerbibliothek keine Auswirkungen.

[Friedemann]

Moin,

Das ist schon komisch, weil das nämlich Mojito aus 1.0.4 _ist_.

Finde ich ja auch komisch, auch wenn ich nicht wusste, dass das das alte unveränderte ist. - Dann muss wohl irgendwas anderes faul sein.
Mailen geht inzwischen; ist nur irritierend, wenn es grundsätzlich am Server geht.

Inzwischen habe ich weitere Installationen versucht und bin dort auf einen viel hässlicheren Fehler gestoßen: wenn der Server grundsätzlich kein SSL kann, lässt sich die letzte beta-Version _nicht installieren_!

Probiert zunächst auf dem virtuellen Debian; weil ich da noch immer nicht ganz sicher bin, ob ich nicht ein Konfigurations- oder Rechteproblem habe, danach auf dem XAMPP 1.8.3 unter Win7_x86. In beiden Fällen wird (korrekt) "SSL (optional)" als nicht verfügbar erkannt, alle anderen Voraussetzungen inkl. Schreibberechtigungen als richtig erkannt, aber dann gibt es (noch in Schritt 1 - Checks) die Fehlermeldung "Sorry, we encountered some issue(s) that will inhibit the installation. Please check the results above and fix the issue(s) listed there."
Einzige Auswahlmöglichkeit ist der Zurück-Button.
Screenshot ist identisch aus beiden Systemen:

BC11-Install_XAMPP1.PNG (361.43 KiB) 4668 mal betrachtet

Tut mir ja leid, wenn ich die Vorfreude dämpfen muss, aber eine _optionale_ und sicher sehr wünschenswerte Möglichkeit bei Nicht-Gegebensein als absolutes Installationshindernis kann ich mir nicht als gewollt vorstellen... :?

Auch wenn ich mod_ssl und die /conf/extra/httpd-ssl.conf wieder mit laden lasse, ändert sich unter XAMPP nichts. (Das Abschalten hatte ja bei den früheren Tests geholfen.)

XAMPP-phpinfo.PNG (36.55 KiB) 4668 mal betrachtet

Komischerweise ging es auf meinem "Haupt-XAMPP", wo SSL läuft und auch (für einen anderen vhost) aktiv ist; es wird also auf Port 443 gelauscht.

Herzliche Grüße, Friedemann

PS: Hat sonst noch jemand die Installation dieser Version probiert - und kann evtl. meine Beobachtung bestätigen?

[shadowcat]

Halb so wild, einfach den SSL-Check aus der precheck.php löschen.