OXID esales: mod_rewrite wird als nicht aktiv angezeigt

tl;dr: Problem war der .htaccess-Verzeichnisschutz, der verhindert, dass OXID korrekt prüfen kann, ob mod_rewrite funktioniert. Die Lösung ist den Schutz zu deaktivieren oder die Server-IP explizit zuzulassen.

Ich habe kürzlich einen OXID esales Shop installiert. An sich ist das kein Hexenwerk, allerdings gab es ein hartnäckiges Problem: mod_rewrite wurde nicht erkannt bzw. als nicht aktiv markiert. In diversen Foren liest man nur, dass man einfach im Code (!) die Prüfung deaktivieren könne. Da es mir eigentlich fern liegt, als „Laie“ an fremdem Code zu frickeln, daher habe ich das Problem mal nachvollzogen.

Der OXID-Shop überprüft das Vorhandensein von mod_rewrite auf recht kreative Art und Weise. Der zugehörige Code steht in core/oxsysrequirements.php (ctrl+f checkModRewrite) Und zwar wird folgender Request an den Server gesendet:

http://<domain>/oxseo.php?mod_rewrite_module_is=off

Durch eine RewriteRule, die in der mitgelieferten .htaccess-Datei steht, wird der Request aber umgeschrieben:

RewriteCond %{REQUEST_URI} oxseo\.php$
RewriteCond %{QUERY_STRING} mod_rewrite_module_is=off
RewriteRule oxseo\.php$ oxseo.php?mod_rewrite_module_is=on [L]

Das aufgerufene Skript macht dabei nichts anderes als zu prüfen, wie der übergebene Parameter lautet (also ob korrekt umgeschrieben wurde) und anschließend entweder mod_rewrite_on oder mod_rewrite_off auszugeben.

Per Hand abgesetzt brachte der Request aber die korrekte Ausgabe. Der Fehler lag also irgendwo in der Kommunikation und war schnell gefunden: Ich hatte für das Aufsetzen eine Authentifizierung per .htaccess eingerichtet. Diese funkte jetzt dazwischen und beantwortete den Request von OXID mit einem 401. Da das dort nicht abgefangen wird, geht der Shop davon aus, dass mod_rewrite nicht korrekt arbeitet. Die Lösung sah einfach aus: Zusätzlich zu der Authentifizierung per Username und Passwort darf auch der Server selbst auf sich zugreifen:

Require group oxid
Require ip <IP des Servers>

weiterlesen

Subversion: SVN Repository-Server mit Apache2

Ein Freund fragte mich kürzlich, ob ich ihm einen SVN-Server aufsetzen könne. Ich habe selbst von SVN keine Ahnung und habe auch nicht vor mich einzulesen, da ich mit git ganz fit bin. Das ist also nur eine kleine Gedankenstütze für mich.

Voraussetzungen

  • funktionierender Apache2 auf einem Linuxsystem (hier: Debian)

Zielsetzung

Ziel soll es sein, dass ein Freund sich per SSH auf meinem Server einloggen kann und dann per „svnadmin“ die Repositories erstellt. Danach kann er über den Apache-VHost svn.misterunknown.de auf diese Repos zugreifen und diese verändern. Es gibt allerlei externe Programme, die mit dem Server kommunizieren können, beispielsweise TortoiseSVN.

Vorgehen

Als erstes hab ich die SVN-Erweiterung von Apache installiert.

apt-get install libapache2-svn

Anschließend kann man sich die (auskommentierte) Default-Konfiguration mal angucken (im Apache 2.4 heißt die Datei /etc/apache2/mods-available/dav_svn.conf). Ich dort allerdings alles auskommentiert gelassen und einen frischen VHost aufgesetzt:

<VirtualHost *:44
        ServerName svn.misterunknown.de
        ServerAdmin webmaster@misterunknown.de

        SSLEngine On # man sollte Verschlüsselung benutzen
        ...

        <Location />
                DAV svn
                SVNParentPath /data/svn
                SVNListParentPath on

                AuthType Basic # Authentifizierung einrichten
                ...
                <LimitExcept GET PROPFIND OPTIONS REPORT>
                        Require group svn
                </LimitExcept>
        </Location>

        DocumentRoot /data/svn
        <Directory /data/svn>
                Require all granted
                AllowOverride None
        </Directory>

        ... # normales Error- und Access-Log definieren
        CustomLog /var/log/apache2/vhosts/svn.misterunknown.de-svn.log "%t %u %{SVN-ACTION}e" env=SVN-ACTION
</VirtualHost>

weiterlesen