nicht angemeldet
Rolf B
Matthias Scharwies
Rolf B
Matthias Scharwies
Rolf B
Der Martin
Rolf B
Gunnar Bittersmann
Rolf B
Rolf B
Robert B.
Hi,
kann die .htaccess von Bots gelesen werden?
Hallo Jörg,
Im Normalfall: Nein. Ein Bot, der über's Web an einen Apache geht, bekommt keine .ht* Datei geliefert, und wenn er noch so bettelt.
Wenn es eine PHP Seite mit Bugs gibt, die das Lesen beliebiger Dateien erlauben, sieht die Sache anders aus.
Wenn der Webserver KEIN Apache ist, sieht's auch anders aus, aber dann ist die .htaccess auch wurscht.
Rolf
Hallo Rolf
Wenn der Webserver KEIN Apache ist, sieht's auch anders aus, aber dann ist die .htaccess auch wurscht.
Wenn die .htaccess "wurscht" ist, dann läuft ja meine Anwendung nur auf Apache-Servern, denn in meiner .htaccess stehen DirectoryIndex-, ErrorDocument-, SetEnv- u.a. Angaben.
Servus!
Hallo Rolf
Wenn der Webserver KEIN Apache ist, sieht's auch anders aus, aber dann ist die .htaccess auch wurscht.
Wenn die .htaccess "wurscht" ist, dann läuft ja meine Anwendung nur auf Apache-Servern, denn in meiner .htaccess stehen DirectoryIndex-, ErrorDocument-, SetEnv- u.a. Angaben.
Deine Anwendung läuft nur auf einem, nämlich Deinem Server.
Welche Browser clientseitig vorhanden sind, hat nichts mit Servern zu tun.
Herzliche Grüße
Matthias Scharwies
Ich verstehe Euch nicht.
Ich habe doch keinen eigenen Server.
Und auf den Server des Providers habe ich doch keinen Einfluss.
Hallo Jörg,
vielleicht erklärst Du uns mal, was Du eigentlich wissen willst.
.htaccess ist eine Datei, die auf einem Apache-getriebenen Webserver in einem Ordner liegen kann, der vom Webserver im Netz bereitgestellt wird. Darin stehen Steueranweisungen für den Apache. Und - wie ich schon schrieb - der Apache kümmert sich darum, dass von außen keiner an die Datei herankommt. Der Apache verwehrt den Zugriff auf alle Dateien, deren Name mit .ht beginnt.
Ein Zugang zur .htaccess am Apache vorbei ist möglich, setzt aber voraus, dass Du selbst eine Schwachstelle einbaust. Wie ich schon schrieb.
Aber wenn Du keinen Server hast - was soll dann die Frage?
Rolf
Aber wenn Du keinen Server hast - was soll dann die Frage?
Wenn ich meine Anwendung bei einem Provider hochlade, lade ich auch die .htaccess hoch. Also habe ich zwar keinen Server, aber der Provider. Und ob der Apache einsetzt, weiß ich im Normalfall nicht.
Wenn ich Euch richtig verstanden habe, ist die .htaccess nur auf Apache-Servern relevant. Wie funktionieren aber dann bei anderen Serven die genannten .htaccess-Einträge?
In vielen Posts im Selfhtml habe ich über Einträge in der .htaccess gelesen, nie aber den Hinweis "Vorsicht, nur für Apache verwenden".
Wenn ich meine Anwendung bei einem Provider hochlade, lade ich auch die .htaccess hoch. Also habe ich zwar keinen Server, aber der Provider. Und ob der Apache einsetzt, weiß ich im Normalfall nicht.
Das sollte sich zumindest in Erfahrung bringen lassen.
Wenn ich Euch richtig verstanden habe, ist die .htaccess nur auf Apache-Servern relevant.
Selbst beim Apache ist die nicht zwangsläufig relevant. Ob und welche Direktiven hierfür freigeschaltet sind, ist Sache der darunter liegenden Serverkonfiguration.
Wie funktionieren aber dann bei anderen Serven die genannten .htaccess-Einträge?
1:1 meines Wissens überhaupt nirgends. Der RolfB ist hier der IIS-Guru. Da gibt es analoge Mechanismen, welche aber komplett anders hinterlegt werden.
Ich meine mich an irgendwelche XML-Konstrukte in irgendeiner Gui zu erinnern, das ist aber schon viele Jahre her…
IIS im Massenhosting dürfte allerdings eher selten sein ;-) Im Regelfall wirst Du da einen Apache haben, ja. Nur wie gesagt: ob und welche Spielereien da via .htaccess gehen, wäre erstmal zu prüfen.
In vielen Posts im Selfhtml habe ich über Einträge in der .htaccess gelesen, nie aber den Hinweis "Vorsicht, nur für Apache verwenden".
Das könnte evtl. daran liegen, dass die üblichen Fragen zum Thema sehr spezifisch auf den Apache abzielen.
Servus!
In vielen Posts im Selfhtml habe ich über Einträge in der .htaccess gelesen, nie aber den Hinweis "Vorsicht, nur für Apache verwenden".
Das Forum ist ein guter Ort um Fragen zu stellen und Antworten zu erhalten.
Man sollte aber auch Selbststudium betreiben. Im SELF-Wiki gibt es mehrere Seiten zu .htaccess:
Die .htaccess-Datei (englisch hypertext access „Hypertext-Zugriff“) ist eine Konfigurationsdatei auf NCSA-kompatiblen Webservern wie dem vor allem bei Shared-Hosting weit verbreiteten Apache.
Herzliche Grüße
Matthias Scharwies
Hallo Jörg,
wie der Mitleser schrieb, sieht die Welt bei anderen Servern anders aus - wobei man da auch genau mit dem Begriff aufpassen muss. Server kann das Konglomerat aus Blech und Silizium sein, auf dem man Popcorn rösten kann, aber auch das Stück Software, das darauf läuft und Dir dein HTML nach Hause schickt. Hier meine ich mit "anderen Servern" die Software.
.htaccess ist definitiv Apache-spezifisch. MÖGLICHERWEISE gibt es andere Webserverprogramme, die ebenfalls eine .htaccess Datei nutzen. Das entzieht sich meiner Knoff-Hoff-Sphäre.
Beim IIS (Windows Webserver) gibt es die zentrale applicationhost.config Datei (eine XML Datei), wo Dinge drinstehen, der der Serveradmin einstellt. Dort wird dann auch - analog zum Apache - festgelegt, welche Einstellungen im Web überschrieben werden dürfen.
Das geschieht dann mittels web.config Dateien (ebenfalls XML), deren Inhalt zur Kategorie WRITE-ONLY gehört. Microsoft dokumentiert das zwar auf doc.microsoft.com, aber ohne den IIS Manager ist man reichlich am Schwimmen.
Der NGINX, den wir bspw. für das Offline-Wiki verwenden, kennt eine Datei nginx.conf. Deren Format ist nicht XML, nicht JSON, es scheint auch nicht YAML zu sein. Wenn das ein Standardformat ist, kenne ich es nicht. Ob der NGINX ebenfalls lokale Config-Dateien kennt, die zentrale Settings überschreiben, weiß ich nicht.
Im Tomcat wird es sicherlich wieder anders sein, aber von dem kenn' ich nur den Namen.
Und so weiter und so weiter.
Die diversen Hosting-Anbieter, bei denen Du Webspace mieten kannst, verwenden typischerweise den Apache. Warum? Weil der der gängige und bekannteste Webserver für Linux ist und nichts kostet.
Mein Arbeitgeber setzt auf den IIS. Warum? Weil wir viele .net Anwendungen betreiben und der IIS die perfekt integriert.
Rolf
Hallo Jörg,
Also habe ich zwar keinen Server, aber der Provider. Und ob der Apache einsetzt, weiß ich im Normalfall nicht.
im Normalfall doch. Denn entweder sind meine Ansprüche so niedrig, dass mir die technischen Details einfach egal sind (z.B. wenn ich nur eine einfache Web-Visitenkarte machen will), oder ich suche mir den Provider und das Hosting-Paket gezielt danach aus, dass da ein Apache jodelt.
In vielen Posts im Selfhtml habe ich über Einträge in der .htaccess gelesen, nie aber den Hinweis "Vorsicht, nur für Apache verwenden".
Vermutlich weil das bei den allermeisten Hostingpaketen der Fall ist.
Einen schönen Tag noch
Martin
In vielen Posts im Selfhtml habe ich über Einträge in der .htaccess gelesen, nie aber den Hinweis "Vorsicht, nur für Apache verwenden".
Ja! Mein Gott! Im Massenhosting ist anderes als der Apache Webserver faktisch nicht anzutreffen. Wer etwas anderes hat weiß das. Und vor allem ist mir jedenfalls kein anderer Server bekannt, der die fürs das Massenhosting mit PHP & Co. notwendigen Eigenschaften/Module hat. (Schaue mal nach fcgi, suexec, …)
Sehr viel häufiger wäre, dass Du auf einem Server bei einem Massenhoster die von Dir selbst gesetzten Eigenschaften nicht bestimmen kannst (darfst), denn das konfiguriert der Hoster. Du musst also sowieso vor dem Kauf bzw. der Miete beim Kundendienst nachfragen.
Hallo Raketenwilli,
(Schaue mal nach fcgi, suexec, …)
IIS...
FastCGI - Check
suexec - Was zum Teufel? Ich lege einen Application Pool an, trage einen User ein und lege noch fest, wieviele Prozesse maximal im Pool laufen. Fettich.
vhosts - was auch immer das im Apache genau ist, aber in meinem IIS konfiguriere ich so viele Webs wie ich will, binde sie an IPs und Hostnamen und lege für jedes fest, in welchem AppPool es laufen soll.
Ich bin ein WIMP und stolz drauf 😂
Spaß beiseite: Der Apache hat vermutlich in seinen drölftausend mod_dingsbumsen eine Menge Funktionen, die der IIS nicht hat. Als Nicht-Indianerhäuptlich kenn ich die nicht. Und da ich mit dem IIS kein Massenhoster bin, sondern nur mich selbst auf meinem Test-PC beheimate, hab ich auch den Bedarf nicht.
Rolf
@@Jörg der 2.
Aber wenn Du keinen Server hast - was soll dann die Frage?
Wenn ich meine Anwendung bei einem Provider hochlade, lade ich auch die .htaccess hoch. Also habe ich zwar keinen Server, aber der Provider.
Nein! Der Provider hat auch keinen Server, sondern das Rechenzentrum … Du ahnst, wie unsinnig die Wortklauberei ist‽ Wohin du deinen Kram hochlädst, ist mit „dein Server“ gemeint. Es ist dein Server.
Und ob der Apache einsetzt, weiß ich im Normalfall nicht.
Wenn ich Euch richtig verstanden habe, ist die .htaccess nur auf Apache-Servern relevant.
Eben. Das heißt andersrum: Wenn .htaccess etwas bei der Serverkonfiguration bewirkt, dann handelt es sich um einen Apachen.
🖖 Живіть довго і процвітайте
Hallo Gunnar,
Wenn .htaccess etwas bei der Serverkonfiguration bewirkt, dann handelt es sich um einen Apachen.
Yep. Und der Umkehrschluss gilt nicht.
Denn:
<Files ".ht*"> steht, und dafür sorgen, dass der neue Name ebenfalls geblockt wirdVermutlich gibt's auch noch andere Möglichkeiten, einen Apachen umzuerziehen…
Rolf
Hallo Jörg,
wenn dein Server mit Apache läuft, dann ist die .htaccess natürlcih relevant, aber da kümmert sich der Apache darum, dass ein Bot oder sonst ein Webclient nicht auf direktem Wege an .ht* Dateien herankommt.
Ich habe den Fall "nicht Apache" nur deshalb aufgelistet, weil Du deine Frage dermaßen globalgalaktisch formuliert hast.
Rolf
Moin Rolf,
Im Normalfall: Nein. Ein Bot, der über's Web an einen Apache geht, bekommt keine .ht* Datei geliefert, und wenn er noch so bettelt.
Das kommt darauf an, welcher AccessFileName und Zugriffsschutz definiert ist. Der Default ist
<FilesMatch "^\.ht">
Require all denied
</FilesMatch>
allerdings ist es sinnvoll das anzupassen, wenn man einen anderen AccessFileName verwendet.
Wenn es eine PHP Seite mit Bugs gibt, die das Lesen beliebiger Dateien erlauben, sieht die Sache anders aus.
So sieht das auch aus, wenn beliebige andere Seiten (ASP, JSP, …) oder CGI-Executables Mist bauen.
Wenn der Webserver KEIN Apache ist, sieht's auch anders aus, aber dann ist die .htaccess auch wurscht.
Dafür gibt es dort andere Ressourcen, die man schützen möchte.
Viele Grüße
Robert
kann die .htaccess von Bots gelesen werden?
Möglicherweise! Kannst Du sie denn via HTTP abrufen? Warum fragst Du?
Hallo,
da habe ich seit Jahren für mehrere Vereine einfache Homepages erstellt bei den unterschiedlichsen Providern und immer die .htaccess verwendet.
Auch im Forum habe ich mir immer wieder Tipps zu der .htaccess-Datei geholt. Nie gab es Probleme!
Glück gehabt!
Aber gibt es aber eine Datei, in der man redirects steuern, globale Variablen anlegen kann, die bei allen Servertypen verwendet werden kann.
Hallo Lydia,
Aber gibt es aber eine Datei, in der man redirects steuern, globale Variablen anlegen kann, die bei allen Servertypen verwendet werden kann.
Nein. Da kocht jeder Server seine eigene Suppe.
Das URL-Rewrite Modul vom IIS hat ein Feature zum Import von mod_rewrite-Anweisungen für den Apache, aber das ist alles.
Rolf
Glück gehabt
Ungefähr so viel, wie wenn Du ins Wasser fasst und dann fest stellst, dass es nass ist.
Aber gibt es aber eine Datei, in der man redirects steuern, globale Variablen anlegen kann, die bei allen Servertypen verwendet werden kann.
Unabhängig vom Server kann man vieles (nicht alles) z.B. (es gibt weitere Möglichkeiten, angefangen bei SSI) in einer stets zu inkludierenden PHP-Datei (PHP muss er dazu freilich können) machen. Das müsste aber auch dann geschehen können, wenn ein 404er auftritt.
Hallo Raketenwilli,
kann man vieles ... machen
Aber sollte man das - außer zum akademischen Lustgewinn? Als Privatmensch deploye ich eine Webanwendung ja normalerweise auf genau einen Typ Server und weiß deshalb, in welche Konfiguration ich was eintragen muss.
Wenn ich eine kommerzielle Anwendung erstelle, die auf vielen unterschiedlichen Servertypen laufen können soll, dann kann ich
(a) die Configs für diese Typen mitliefern (b) eine Anleitung erstellen, die beschreibt, welche Funktionen der Server beistellen muss und vom Admin erwarten, dass er das konfiguriert.
Gerne auch beides. Als kommerzieller Anbieter muss ich meine Anwendung ja auf den von mir als "unterstützt" gelisteten Webservern getestet haben und kann in dem Zusammenhang Muster-Konfigurationen erstellen. Und für die Anwender, denen die Musterkonfigurationen nicht reichen, muss ich die Konfigurationsmöglichkeiten eh dokumentieren.
Eine Lösung, die die nativen Möglichkeiten des Servers ignoriert und sie statt dessen auf andere Weise nachbaut, kann im produktiven Einsatz nur schlechter sein. Sie ist umständlicher, fehleranfälliger und sehr wahrscheinlich auch weniger performant. Der einzige Grund, weshalb man so etwas tun sollte, wäre ein Server, den ich nicht wie erforderlich unter Kontrolle habe und die nativen Möglichkeiten nicht konfigurieren darf.
Oder ein Server, der die nativen Möglichkeiten schlicht nicht bietet. Gibt's sicher auch. Aber sollte man deshalb eine Anwendung ausgehend vom dümmsten aller möglichen Fälle bauen?
Bei einer "historischen" Anwendung mag das anders sein. Vielleicht hat man mit einem Server begonnen, dem es an solchen Funktionen gebrach, und schleppt deswegen handgemachte Redirects und ähnliches mit. Das wäre dann aber ein Sanierungsfall. Bei neuen Anwendungen sollte man die nativen Möglichkeiten nutzen, die existieren.
Oder ich sehe die Welt zu blauäugig, kommt gerne immer wieder vor…
Rolf
Hallo Raketenwilli,
Moin Rolf
kann man vieles ... machen
Aber sollte man das
Ganz ehrlich? Nein. Ich persönlich betrachte ja nicht einmal einen Apache unter Windows (z.B. XAMPP) als geeignete Testumgebung. Außerdem ist spätestens seit dem HyperVi und also Windows 8 jede, bisher als Begründung ansehbare Notwendigkeit, sowas zu machen, schon lange entfallen.
Bevor gefragt wird: Den IIS bzw. Kestrel halte ich in „besonders kontrollierten Umgebungen“ für akzeptabel, wenn er genutzt werden soll, z.B. (es gibt weitere Gründe) weil eine Anbindung an die Authorisierungsmechanik von Windows-Domaincontrolern, ASP.net, … erforderlich oder ausreichend dringend gewünscht ist.
Dann wäre es nämlich „akademisch“ auf dem Apache zu bestehen und den mit Modulen oder schrägen Konfigurationen dafür fit zu machen.
Eine Lösung, die die nativen Möglichkeiten des Servers ignoriert und sie statt dessen auf andere Weise nachbaut, kann im produktiven Einsatz nur schlechter sein. Sie ist umständlicher, fehleranfälliger und sehr wahrscheinlich auch weniger performant.
Und darüber hinaus völlig unnötig wenn der „Server mit den nativen Möglichkeiten“ derart verbreitet ist wie der Apache. Ich investiere doch nicht hunderte Kilo Gehirnschmalz und Zeit um etwas zu bauen, was ich mit 3 bis 10 Config-Zeilen und einen ausreichend aufmerksamen Blick auf die Beschreibung/Dokumentation des Hosters (notfalls einen Anruf vor dem Kauf) schon haben kann.