Ergebnis 1 bis 5 von 5
  1. #1
    Mitglied
    Registriert seit
    Jun 2009
    Beiträge
    315

    Standard [htaccess] mod_rewrite + zugriff verbieten

    Guten abend...

    Meine frage heute abend ist folgende:
    wie kann ich mod_rewrite nutzen und die ausgangs dateien sperren
    z.b. Rewrite.. indes.html$ index.php
    und wie kann ich verhindern dass man index.php aufruft?

    Danke :-)

  2. #2
    Mitglied
    Registriert seit
    Jun 2009
    Ort
    Im Forum
    Beiträge
    530

    Standard Re: [htaccess] mod_rewrite + zugriff verbieten

    Da gibts doch nen Flag für oder nicht ?
    [L] wäre das glaube ich...
    Damit linkst du einfach weiter, anstatt die URL nur anders darzustellen.

  3. #3
    Nerd

    Board:Crew

    Avatar von Kugelfisch23
    Registriert seit
    Oct 2007
    Ort
    Im Ozean
    Beiträge
    16.811

    Standard Re: [htaccess] mod_rewrite + zugriff verbieten

    Nein, das ist nicht über ein mod_rewrite-Flag für eine bestehende Regel möglich. Das [L]-Flag sorgt lediglich dafür, dass die Regel (so sie angewendet wird) die letzte ist, d.h. die Verarbeitung danach abgebrochen wird, vgl. http://httpd.apache.org/docs/current...gs.html#flag_l. Möglich wäre das durch eine zusätzliche Regel für index.php mit dem [F]-Flag (http://httpd.apache.org/docs/current...gs.html#flag_f), allerdings ist dann zu beachten, dass der Regelsatz u.U. aufgrund interner Redirects mehrfach durchlaufen wird, insbesondere dann, wenn im per-Directory-Kontext umgeschrieben wird. Deshalb ist zusätzlich z.B. %{THE_REQUEST} über eine RewriteCond-Direktive zu überprüfen:
    Code:
    RewriteCond %{THE_REQUEST} index\.php
    RewriteRule ^index\.php$ - [F]
    Sinnvoller als das komplette Verbieten schiene mir allerdings die externe Umleitung solcher Anfrage mit einem 301-Statuscode auf den zugehörigen kanonischen URI, z.B. von /index.php?foo=bar nach /bar/.

  4. #4
    Mitglied

    (Threadstarter)


    Registriert seit
    Jun 2009
    Beiträge
    315

    Standard Re: [htaccess] mod_rewrite + zugriff verbieten

    Also ich möchte nicht nur index.php umschreiben, sondenr auch z.b. captcha.php zu captcha.png. Ich möchte halt nur verhindern, dass die Besucher auf captcha.php zugreifen können.

    Die kanonischen URIs habe ich mir bereits angeschaut. Ich konnte mich damit nur nicht wirklich anfreunden. Wie sieht das denn aus wenn man index.php?foo=bar&bar=xy ind index.php/bar/ umschreiben will... wir der query einfach dann drangehängt also index.php/bar/?bar=xy

    oder wie sieht das aus?

  5. #5
    Nerd

    Board:Crew

    Avatar von Kugelfisch23
    Registriert seit
    Oct 2007
    Ort
    Im Ozean
    Beiträge
    16.811

    Standard Re: [htaccess] mod_rewrite + zugriff verbieten

    Zitat Zitat von KaleR Beitrag anzeigen
    Also ich möchte nicht nur index.php umschreiben, sondenr auch z.b. captcha.php zu captcha.png. Ich möchte halt nur verhindern, dass die Besucher auf captcha.php zugreifen können.
    Dass du dieselben Inhalte nicht unter mehreren URIs zur Verfügung stellen möchtest, ist sicherlich sinnvoll (auch wenn das im Falle des captcha.php-Skripts kaum relevant wäre). Allerdings: Was möchtest du in deinem Beispiel durch die Umschreibung erreichen? Du kannst auch einen auf captcha.php endenden URI als src-Attribut nutzen, bei Browsern und Proxy-Servern, welche Heuristiken zur Bestimmung der Cachebarkeit einer Ressource nutzen könnte die Nutzung eines auf png endenden (und daher statisch anmutenden) URI-Pfads ggf. sogar das Caching fördern, was wenig wünschenswert wäre.

    Zitat Zitat von KaleR Beitrag anzeigen
    Die kanonischen URIs habe ich mir bereits angeschaut. Ich konnte mich damit nur nicht wirklich anfreunden.
    Offenbar verwechselst du das von mir erwähnte Konzept, durchgehend kanonische URIs zu nutzen mit dem häufig über ein URI-Rewriting-Modul wie mod_rewrite vorgenommenen `Verschönerung` von URIs von quasi-statischen Inhalten (z.B. den Unterseiten einer Website, die durch ein CMS erzeugt werden), so dass diese statisch aussehen - das ist u.U. aus SEO-Gründen von Vorteil.

    Der kanonische URI einer Ressource muss jedoch keineswegs solch eine Struktur aufweisen (/bar/ in meinem Beitrag war bloss ein Beispiel), so könnte z.B. auch http://example.com/foo.php?bar=baz der kanonische URI einer bestimmten Ressource sein - sofern du ihn dazu erklärst, indem du ihn durchgehend nutzt, wenn diese Ressource referenziert werden soll und ggf. andere URIs, die auf dieselbe Ressource zeigen sollen, darauf umleitest - demnach ist das Konzept. Siehe z.B. http://schneegans.de/web/kanonische-...iversifikation. Das Konzept besagt lediglich, dass jede Ressource unter genau einem URI zugänglich gemacht werden sollte.

    Zitat Zitat von KaleR Beitrag anzeigen
    Wie sieht das denn aus wenn man index.php?foo=bar&bar=xy ind index.php/bar/ umschreiben will... wir der query einfach dann drangehängt also index.php/bar/?bar=xy
    Mutmasslich möchtest du nicht /index.php?foo=bar&bar=xy in index.php/bar/ umschreiben, sondern die Umschreibung in anderer Richtung - von z.B. /bar/ (externer URI-Bestandteil) zu /index.php?foo=bar (interner URI-Bestandteil nach der Umschreibung); vgl. http://board.gulli.com/thread/16907...5#post14360905.
    Was dabei mit einem eventuellen Query-String geschieht, kannst du bei Nutzung von mod_rewrite entscheiden. Das Verhalten ist in http://httpd.apache.org/docs/current...ml#rewriterule dokumentiert:
    By default, the query string is passed through unchanged. You can, however, create URLs in the substitution string containing a query string part. Simply use a question mark inside the substitution string to indicate that the following text should be re-injected into the query string. When you want to erase an existing query string, end the substitution string with just a question mark. To combine new and old query strings, use the [QSA] flag.
    Wenn du den Query-String erhalten und um einen oder mehrere Parameter ergänzen möchtest, setze das [QSA]-Flag für die jeweilige RewriteRule-Direktive.

  6.  
     
     

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •