Meine Fresse, heute bin ich wo drübergestolpert, wo ich mir dachte, gibt’s doch gar nicht…
Vielleicht erinnert sich ja noch der ein oder andere an das hier.
ENDLICH:
(und wer so grottige Browser oder nicht supportete Betriebssyssteme hat: klick)
(oder wie wird man langsam aber sicher in den Wahnsinn getrieben)
Nach dem neuesten Umzug mußte ich mich mit der Tatsache auseinandersetzen, daß mod_php zwar total unsicher, aber dafür sehr bequem ist, und suphp einem das Datei- und Ordner-Rechte-Thema sehr einfach macht.
Neuer Server läuft allerdings mit FastCGI, und da bei PHP ohnehin alles, was CGI-irgendwas ist, total Krätze läuft, war ich nicht erstaunt, als z-push in der Version 2.1 nicht mehr so tat wie es sollte.
Für suphp oder fcgid war das ja noch mit der compat.php getan, und schon hatte man das fehlende apache_request_headers() (oder getallheaders).
Problem bei FastCGI ist, laut PHP.net sollte mit Version 5.4 diese von so vielen Scripten genutzte Funktion nativ mit dabei sein, bei PHP5-FPM wohl noch nicht.
(wie immer bei den Dev’s von PHP; zuerst ja ja, kein Problem, dann wieder kräftig zurückrudern… oh, das erinnert mich ja noch an den full email disclosure… 😀 )
Wie dem auch sei, simples Script, um zu testen ob der Häuptling in der Lage ist, die nötigen Header auszuwerten:
<?php
if (empty($_SERVER['PHP_AUTH_USER'])) {
header('WWW-Authenticate: Basic realm="My Realm"');
header('HTTP/1.0 401 Unauthorized');
echo "Need auth!";
exit;
}
list($_SERVER['PHP_AUTH_USER'], $_SERVER['PHP_AUTH_PW']) = explode( ':', base64_decode(substr($_SERVER['PHP_AUTH_USER'], 6)) );
echo "<pre>";
print_r($_SERVER);
echo "</pre>";
?>
So, wer jetzt hier in der Endlos-Schleife landet, obwohl er die vielen tollen Tips aus dem Zarafa-Forum durchprobiert hat, die nötigen Aliase oder Rewrite-Rules in den entsprechenden .htaccess-Dateien durchgepfriemelt hat:
es liegt nicht an Euch.
Ich habe ein Wochenende damit verbracht, per trial & error eine funktionsfähige Lösung zusammenzuschrauben, was allerdings total unnötig ist.
Wenn Ihr shared Hosting gebucht habt, dann tut mir das leid, denn da könnte es sein, daß Euer Provider aus welchen Gründen auch immer Euch die nötige Konfiguration verweigern wird.
Für einen eigenen Server ist die Lösung so banal einfach:
FastCgiExternalServer /var/www/php-fpm/fpm.external -socket /var/lib/apache2/fastcgi/domain-fpm.socket -idle-timeout 400 -pass-header Authorization
(bitte auf die eigenen Gegebenheiten anpassen…)
Man kann ja ewig versuchen, einen Workaround für die Authentifizierung zu basteln; wenn der Apache die Header nicht bekommt, kann er auch nix auswerten.
Mit dem -pass-header Authorization, welches übrigens am Ende stehen muß, bekommt er wenigstens die User/Pass Daten übermittelt, was für z-Push ja ausreicht, denn der Rest ist ohnehin in der .htaccess hinterlegt:
RewriteEngine on
RewriteRule .* - [E=HTTP_MS_ASPROTOCOLVERSION:%{HTTP:Ms-Asprotocolversion}]
RewriteRule .* - [E=HTTP_X_MS_POLICYKEY:%{HTTP:X-Ms-Policykey}]
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
Tja, hätte man doch gleich mal auf die manpage geguckt…
Für mod_fcgid verhält es sich im Übrigen ähnlich, nur lautet es da:
FcgidPassHeader Authorization
Das eigentliche Problem ist der Indianer, der sich weigert den Authorization-Header an CGI-Skripte weiterzugeben.
Wenn man sein System eh from source baut, dann kann man das aber auch gleich mit:
export CFLAGS="-DSECURITY_HOLE_PASS_AUTHORIZATION $CFLAGS"
./configure [...]
make
abdrehen (bei shared Hosting wohl schwerlich möglich 😉 ).
So, als erstes:
apt-get install jpegoptim pngcrush optipng
Danach wechselt man ins Verzeichnis, in dem die jpegs oder pngs liegen, und mit:
find . -name "*.jpg" -exec jpegoptim {} +
erzielt man für jpg durchaus passable Schrumpfung bei akzeptabler Qualität.
Ja, damit werden die Originale überschrieben, d.h. ein Backup ist vorher sinnvoll.
Und mittels:
find . -name "*.png" -exec pngcrush {} +
oder wahlweise:
find . -name "*.png" -exec optipng -o7 {} +
schrumpft man dann auc seine PNG’s ein.
Auch hier, ja das Original is futsch…
