Hallo QTip
Ich bin glücklicher Nutzer des DDNS updaters und sehr zufrieden damit. Nun musste ich leider feststellen, dass dieser nach dem gestrigen Update auf die neue DSM 5.0 Beta aufgehört hat zu funktionieren. Darum habe ich mich ein bisschen genauer damit befasst und auch herausgefunden an was es liegt. Ich werde darum meine Erkenntnisse hier teilen, damit du evtl. Arbeit an einem Update einsparen kannst. Möglicherweise können sogar auch die DSM 4.3 Nutzer von der umgeschriebenen Benutzerprüfung profitieren, jedoch konnte ich sie nicht testen. Doch alles der Reihe nach.
- Init_3rdparty lässt sich nicht mehr starten (da ich gesehen hab, dass du auch von diesem Paket Mitentwickler bist, kommt das auch gleich hier rein )
Hier ist der Grund, dass der Pfad der Konfigurationsdatei von Apache httpd geändert hat. Es ist nicht mehr /usr/syno/apache/conf/httpd.conf-sys sondern neu /etc/httpd/conf/httpd.conf-sys. Den Pfad angepasst im start-stop-status Script läuft Init_3rdparty wieder.
- Trotz Installation von Init_3rdparty scheint PHP auf dem apache-sys nicht zu funktionieren.
Synology liefert mit DSM 5.0 Beta keine libphp5.so mehr mit. Es läuft neu alles über php-fpm. Da ich keine Lust hatte, an irgendwelchen php-Konfigurationen rumzuschrauben oder libphp5.so selber zu kompilieren, hab ich die einfache Variante gewählt und per ipkg das Paket php-apache installiert, welches die libphp5.so unter /opt/libexec/libphp5.so ablegt. Den Pfad angepasst in der 3rdparty.conf vom Init_3rdparty Paket liess PHP wieder perfekt funktionieren.
- Beim Zugriff auf DDNS Updater (und anderen Paketen von dir) kommt es immer nur zur Anzeige von "403 Forbidden".
Offenbar hat Synology für DSM 5.0 Beta an ihrer Authentifizierungsmethode geschraubt, jedenfalls gibt es das file /tmp/current.token, auf dem die Authentifizierung basierte, nicht mehr. Ich habe mir das Ganze einmal angeschaut, mir auch deinen Thread über Anwendungsberechtigung (http://www.synology-forum.de/showth...gung-und-SynoToken-f%FCr-3rdparty-Anwendungen) durchgelesen, Manuals von Synology studiert und dann noch etwas experimentiert. Ich denke ich bin zu einer guten und evtl. auch von Synology so gewollten Lösung gekommen. Hier ist der Code:
PHP:
if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])){
$clientIP = $_SERVER['HTTP_X_FORWARDED_FOR'];
} elseif (isset($_SERVER['HTTP_X_REAL_IP'])){
$clientIP = $_SERVER['HTTP_X_REAL_IP'];
} else {
$clientIP = $_SERVER['REMOTE_ADDR'];
}
putenv('HTTP_COOKIE='.$_SERVER['HTTP_COOKIE']);
putenv('REMOTE_ADDR='.$clientIP);
$login = array();
exec("/usr/syno/synoman/webman/login.cgi", $login);
$token = explode('"', $login[4]);
putenv('QUERY_STRING=SynoToken='.$token[3]);
$user = exec("/usr/syno/synoman/webman/modules/authenticate.cgi");
if ($user === '') {
exit("403 Forbidden");
}
Grösstenteils ist es übernommener Code. Neu ist das Aufrufen von /usr/syno/synoman/webman/login.cgi. Dieses Script kann man auch vom Webbrowser aus aufrufen und wenn man angemeldet ist, wird das SynoToken angezeigt. Im Code wird das SynoToken nach $token[3] extrahiert und dann in die Umgebungsvariable QUERY_STRING abgelegt. Der Aufruf von /usr/syno/synoman/webman/modules/authenticate.cgi liefert nun den korrekten Benutzernamen auch mit aktivierter Option "Schutz gegen Cross-Site-Request-Forgery-Attacken verbessern". Offenbar ignoriert die authenticate.cgi den QUERY_STRING, wenn die CSRF-Option ausgeschaltet ist, denn mein Code funktioniert sowohl mit, als auch ohne aktivierte CSRF-Option.
Nach diesen 3 Anpassungen funktionierte der DDNS updater wieder wie gewohnt.
Ich hoffe meine Ausführungen sind irgendwie nützlich, auf jeden Fall aber ein ganz grosses DANKESCHÖN für deine Arbeit. Deine Tools sind wirklich nützlich, funktionieren einwandfrei und sind dazu auch noch schön gestaltet!
Gruss
mrsandman