nicht angemeldet
hi,
RewriteRule ^/([-\w]+)$ /index.php?domainendung=%1&seite=$1 [QSA]
www.example.com/seite1/?seite=seite2
Dann ist theoretisch $_GET['seite'] = seite1 und wird aber durch den query überschrieben in $_GET['seite'] = seite2, stimmts?
Ja, kannste auch selber prüfen, machs endlich ;)
Mein Lösungsansatz wäre hier folgender, indem ich genau diese Variablen ausschließe:
[..]
zum PHP Skript hin nochmals manipuliert werden können, oder kann ich sicher sein, dass wenn
durch das mod_rewrite geprüfte und gesendete Wert "seite1" im PHP Skript auch als "seite1" »» ankommt, nachdem der Wert "seite1" gesendet wurde?
Du begehst einen systematischen Fehler in dem Moment, wo Du den Request-URI in Parameter zerlegst.
Aufbau URI (Uniform Ressource Identifier)
http://example.com:8078/foo/bar.html?name=boo;vname=dog#nose
\_/ \_____________/\__________/ \_______________/ \__/
| | | | |
Scheme Authority Path Query-String Fragment
Während die Teile Authority und Path unveränderlich im Request vorliegen, kann infolge Manipulation etwas anderes vorgetäuscht werden, d.h., auf Authority oder Path bezogene Mechanismen können ausgehebelt werden, wenn Dein Script diese Informationen aus Parametern bezieht.
Route über den Path und überlasse das durch Parameter bestimmte letzte Stück der Anwendung selbst. GET-Parameter sind, genauso wie POST-Parameter der jeweiligen Anwendung vorbehalten und spielen in der RewriteRule überhaupt keine Rolle.
Auf diese Art und Weise gibt es auch keine für alle Anwendungen reservierten Parameter und damit verbundene Abhängigkeiten, die bei komplexen Anwendungen schwer zu überschauen sind. Parameter sind und bleiben dadurch anwendungsspezifisch und effektiv nur für einen bestimmten URL. Das Routing über den Path benötigt eine Routing-Table mit dem Path als Primärschlüssel.
\ Schönes Wochenende (_)3