Fehlermeldung UpDate

[knollsen]

Im Grunde genommen ist es doch egal, wo die nfo liegt. Wenn man die nfo mit dem Browser öffnen kann, z.Bsp. den Updatececker selbst. Dann liegt es am Plugin. Deswegen hatte ich gesagt, das wir das mal überdenken sollten. Da es Bestandteil vom CMS ist, kann ich da auch nicht Wildcard mäßig rum fummeln. Funktionieren muss es - egal welcher Browser, Server oder Versionen an PHP etc.

[knollsen]

Prüfung CMSimple_XH (www.cmsimple-xh.org)
Also es liegt wahrscheinlich an der openSSL Version
Bei der localen Prüfung fande ich heraus das bei

Code: Select all

$fp = fsockopen($scheme . $host, $port, $errno, $errstr, $timeout);

in der 2. Instanz nach Status 301 keine Rückgabe mehr erfolgt. D.h. ssl://www.cmsimple-xh.org schlägt fehl somit kann keine Abfrage mehr erfolgen, wobei das bei einer neueren Version von openssl nach dem Status 301 mit ssl ein Status 302 erzeugt wird und die Abfrage erneut ausgeführt wird.
1. Abfrage ist immer der http mit port 80 -> schlägt fehl -> ssl mit Port 443 -> Wenns hier habert mit fsockopen dann kann nicht weiter geprüft werden. Und da kann man auch nix machen außer auf curl zu setzen, was wiederum in php auch aktiviert sein sollte. Das Rad dreht sich ...

[cmb]

1. Abfrage ist immer der http mit port 80 -> schlägt fehl -> ssl mit Port 443

Keine Lösung, aber mal einen Versuch wert: ändere doch die URL in CMSimple_XH mal zu https://

[knollsen]

Das brauch ich nicht testen, da es ja fehl schlägt.
Ich habe sogar $scheme . $host, $port manuell gesetzt. Bei neuer openssl kommt bei der 2. Abfrage preg_match('~^HTTP/1\.\d (?P<status>\d+)~', $header, $matches); Status 302 und startet durch. d.h das die 1. Abfrage mit ssl//... bei fsockopen schon keine 200 in Status meldet.
Und genau das ist das Problem auch bei mir auf den eigenen Server mit der 301 Weiterleitung.

Code: Select all

$fp = fsockopen($scheme . $host, $port, $errno, $errstr, $timeout); wenn es hier schon mit ssl hängt
if (!$fp) return null;  - geht's hier ja nicht weiter

wenn es weiter geht mit irgend einer php-version oder openssl kommt dann 302 als Status -> mit dem neuen Aufruf funktioniert alles wie es soll.

Server - OpenSSL 1.0.2g 1 Mar 2016 - error
Portable_XH - OpenSSL 0.9.8zf 19 Mar 2015 - error
xampp - OpenSSL 1.1.1g 21 Apr 2020 - local gehts

Jetzt wird es ganz verrückt - Unter Info bekomme ich auch auf local jetzt neuerdings eine Fehlermeldung!

Code: Select all

WARNING: get_headers(http://localhost:8080/...././cmsimple/config.php): failed to open stream: HTTP request failed!
C:\Portable_XH-1alpha1\html\.....\cmsimple\adminfuncs.php:196 

auf den Server

Code: Select all

WARNING: get_headers(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
/.../www/…./…....de/httpdocs/cmsimple/adminfuncs.php:196

[knollsen]

Auf Server:
Ich Blödmann, da poste ich noch den Fehler der eigentlich das Problem schon sagt!
Wie auch immer - habe die Anpassung in der PHP.ini gesetzt und es funktioniert, auch mit der 301 Weiterleitung. Obwohl ich nie den path zum certificat gesetzt habe, scheint es plötzlich jetzt so zu sein.
Also bei Problemen
zusätzlich zur Aktivierung von openSSL muss noch der Pfad zum Zertifikat angegeben werden bei "openssl.cafile=" (Semikolon davor entfernen)
Jetzt verstehe ich auch, warum fsockopen bei ssl:// kein Rückgabewert liefert bei der alten Version von openSSL

Local läuft der updatechecker mit cmsimple_xh aber immer noch nicht. - das bekomme ich auch noch raus!

Trotzdem sollte das gefixt werden, aber da streich ich die Flügel. (erst einmal)

[cmb]

Also bei Problemen
zusätzlich zur Aktivierung von openSSL muss noch der Pfad zum Zertifikat angegeben werden bei "openssl.cafile=" (Semikolon davor entfernen)
Jetzt verstehe ich auch, warum fsockopen bei ssl:// kein Rückgabewert liefert bei der alten Version von openSSL

Oh, Mann! Das könnte auch der Grund für diverse andere bereits gemeldete Fehlschläge sein. Guter Fund!

Trotzdem sollte das gefixt werden, aber da streich ich die Flügel. (erst einmal)

Aber wie? Ist der Pfad zur Zertifikatsdatei nicht richtig gesetzt, können wir nicht viel tun (außer den User explizit darauf hinzuweisen, dass das unter Umständen das Problem sein könnte). In diesem Fall könnten wir vielleicht auch noch auf die Zertifikatsprüfung verzichten (vielleicht per versteckter Konfigurationsoption), aber das ginge wohl nur mit cURL oder echten Streams, aber nicht mit Sockets.

Na ja, vielleicht sollten wir auch einfach zunächst die Fehlerdiagnostik verbessern.

[olape]

Na ja, vielleicht sollten wir auch einfach zunächst die Fehlerdiagnostik verbessern.

Ich halte das für die bessere Lösung viewtopic.php?f=16&t=12729&p=76114&hili ... eck#p76114
Und noch besser beides.

[knollsen]

…auf die Zertifikatsprüfung verzichten...

Ich hätte damit kein Problem, immerhin geht es um eine Updateprüfung. Und wo steht das bei der Installation von CMSimple OpenSSL oder cURL aktiviert sein muss? Bei meisten ist in der PHP.ini auch nicht extension=php_curl.dll aktiviert. Pattsituation - mhmm

[olape]

Und wo steht das bei der Installation von CMSimple OpenSSL oder cURL aktiviert sein muss?

Zu OpenSSL ok. Da kann ich zur Verfügbarkeit keine Aussage machen.
Zu cURL:

Sprich, wenn ext/curl verfügbar ist, dann sollten wir besser dieses verwenden, und falls nicht, dann prüfen ob allow_url_fopen aktiviert ist, und falls ja, dann einfach file_get_contents(). Nur wenn diese beiden Möglichkeiten nicht gegeben sind, dann auf Socket-Funktionen zurückfallen.

Es würden drei Varianten genutzt, eine davon, die bisherige. Das sollte passen. Auf jeden Fall besser als jetzt. Und cURL ist mit der Weile auch bei den meisten vorhanden.