Koozali.org: home of the SME Server
Other Languages => Deutsch => Topic started by: capri on June 29, 2006, 11:01:52 PM
-
Da ja beim SME Server 7 die .htaccess Dateien nicht benutzt werden, würde ich fragen wie es zu Lösen ist URL's mit mode_rewrite umschreiben zu lassen?
-
Das würde mich auch brennend interessieren! Weiß denn da niemand eine Lösung? Suchmaschinenfreundliche Permalinks haben doch echt was für sich...
Thanks in advance!
-
Hatte den Weg wie in den englischspachigen Foren beschrieben gemacht, funktionierte aber nicht :(
Dann OX7 und ein paar andere Contribs installiert, aber Wunder über Wunder aufeimal ging das URL Umschreiben auch für die anderen Sites, habe dann natürlich in der httpd.conf nachgesehen und was finde ich ?
# AccessFileName: The name of the file to look for in each directory
# for access control information.
AccessFileName .htaccess
...
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
Also entweder bin ich zu Blöd das System von SME 7 zu durchschauen, oder SME 7 hat 'mystische' Eigenschaften :)
-
Hallo Capri,
in welches Template muss das rein?
# AccessFileName: The name of the file to look for in each directory
# for access control information.
AccessFileName .htaccess
...
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
Bin ja mal sehr gespannt, ob das klappt...!
-
Das ist ja das Verrückte, habe gerade nochmal die /etc/e-smith/templates/* (auch die custom) und die Datenbank Datei durchsucht und nichts gefunden, aber definitiv werden die Werte in die httpd.conf geschrieben.
Kenn mich immer noch zu wenig mit SME7 aus um zu wissen wo ich noch suchen könnte.
-
Das ist ja das Verrückte, habe gerade nochmal die /etc/e-smith/templates/* (auch die custom) und die Datenbank Datei durchsucht und nichts gefunden, aber definitiv werden die Werte in die httpd.conf geschrieben.
Kenn mich immer noch zu wenig mit SME7 aus um zu wissen wo ich noch suchen könnte.
Einfach:
grep -ir 'AccessFileName .htaccess' /etc/e-smith/templates* sagt mir:
/etc/e-smith/templates/etc/httpd/conf/httpd.conf/60AccessFileName:AccessFileName .htaccess
/etc/e-smith/templates/etc/httpd/admin-conf/httpd.conf/20Manager:AccessFileName .htaccess
-
Hm... also es ist ja so, das WP die .htaccess in seinem Wurzelverzeichnis erstellt und FÜR SICH umschreibt; das sieht dann z.B. so aus:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Der Punkt ist dann eben, dass für den Apache diese Links "nicht existieren" da die .htaccess nicht die Berechtigung hat sie anstelle des Servers umzuschreiben, und die Links deswegen natürlich ins Leere laufen.
ALSO... nach dem Lesen von http://codex.wordpress.org/Using_Permalinks bin ich nu soweit, daß es für SME'ler wohl folgende Lösung gibt; die erste davon habe ich ausprobiert und sie funktioniert:
1. Workaround um mod_rewrite: bei der Angabe der benutzerdefinierten Struktur zum umschreiben der Links gibt man am Anfanf noch zusätzlich ein "/index.php" ein; also so:
/index.php/%category%/%postname%/
statt so:
/%category%/%postname%/
und entsprechend, wenn die Struktur auf Datum oder Archiv basiert.
Das ist etwas unschön und sieht dann folgendermaßen aus
http://www.familieschwab.info/index.php/mission/christ-darf-nicht-in-den-iran-abgeschoben-werden/ (funktionierender Link)
--------------------------------------->^^^^^^^^
statt so
http://www.familieschwab.info/mission/christ-darf-nicht-in-den-iran-abgeschoben-werden/ (toter Link)
Fazit: funzt mit kleinem Schönheitsfehler!
2. AllowOverrideAll
Auf derselben Seite ist zu finden, daß eine Einstellung in der httpd.conf dazu führt, daß der Webserver die .htaccess keines Blickes würdigt: AllowOverrideAll
AllowOverride Not Enabled
Your server may not have the AllowOverride directive enabled. If the AllowOverride directive is set to None in your Apache httpd.config file, then .htaccess files are completely ignored. In this case, the server will not even attempt to read .htaccess files in the filesystem. When this directive is set to All, then any directive which has the .htaccess Context is allowed in .htaccess files. Example of enabled AllowOverride directive in httpd.config:
<Directory />
Options FollowSymLinks
AllowOverride All
</Directory>
Das könnte funktionieren, und ich bin gespannt, ob das so klappt. Bis dahin habt ihr ja jetzt immerhin Lösung 1, mit der man zumindest zweitweise auch leben kann.
Für heute...
-
grep -ir 'AccessFileName .htaccess' /etc/e-smith/templates*
Danke für den Tipp, damit habe ich nun gefunden wo die Rewirte Engine aktiviert wird:
/etc/e-smith/templates/etc/httpd/conf/httpd.conf/ProxyPassVirtualHosts/26RewriteTraceAndTrack: RewriteEngine on
/etc/e-smith/templates/etc/httpd/conf/httpd.conf/VirtualHosts/26RewriteTraceAndTrack: RewriteEngine on
Damit macht bei mir zumindest ein 'AllowOverride All' in den Directorys kein Problem mehr.
-
Hallo capri,
habe gerade gemerkt, dass ich mit der Wordpress-Geschichte ja eigentlich auf einen anderen Thread ( http://forums.contribs.org/index.php?topic=31131.0 )Bezug nehme... So was...!
Wie auch immer: denkst du, man kann die entsprechenden Angaben der .htaccess die man für die jeweilige Anwendung braucht in die von dir gefundenen Templates eintragen kann?
Funktioniert das auch mit den standardmäßig restriktiven Einstellungen bez. AllowOverride? Denn: falls man hier "All" einstellt, bedeutet das wohl daß man einiges an Sicherheit einbüßt... Oder?
-
Hallo capri,
Wie auch immer: denkst du, man kann die entsprechenden Angaben der .htaccess die man für die jeweilige Anwendung braucht in die von dir gefundenen Templates eintragen kann
Prinzipiell ginge das, Sinn macht es aber keinen da bei einem Update des Systems wieder Alles überschrieben würde, darum sollte man die entsprechenden Dateien in /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/ oder Etsprechnd im template-custom kopieren und dort bearbeiten, dann werden sie bei einem Update auch nicht überschrieben und trotzdem noch genutzt.
Funktioniert das auch mit den standardmäßig restriktiven Einstellungen bez. AllowOverride? Denn: falls man hier "All" einstellt, bedeutet das wohl daß man einiges an Sicherheit einbüßt... Oder?
Die Macher von SME7 haben sich wohl etwas dabei gedacht, als sie .htaccess Dateien unterbunden haben, es ist für einen potentiellen Angreifer halt leichter das System zu manipulieren wenn er Zugriff auf die Datei erreicht, ohne diese Möglichkeit tut er sich garantiert erheblich schwerer :)
EDIT: Es wird soviel über Serversicherheit geredet, dabei wird nur allzu oft vergessen, ein einziger grober Patzer in einem öffentlich zugänglichen PHP Script auf einen Server der nicht dagegen abgesichert ist und es ist selbst für Script Kiddys ein Leichtes die ganze Sicherheit des Systems auszuhebeln.
Und wir kennen ja unsere 'lieben' PHP CMS etc. Programmierer, da wird wie wild drauf losprogrammiert und Sicherheit erst nach entsprechenden Meldungen von Nutzern eingebaut, wenn überhaupt (siehe PHPNuke).