Verfasste Forenbeiträge

Ansicht von 3 Antworten - 1 bis 3 (von insgesamt 3)
  • Thread-Starter ac2124

    (@ac2124)

    Hallo,

    dank des IONOS-Supports weiß ich mittlerweile, wo der Hund begraben liegt. Im Grunde eine ziemlich simple Lösung, umso ärgerlicher für mich, dass ich nicht selbst darauf gekommen bin:
    Bei IONOS läuft PHP als CGI. Daher können die Header bei normalen .html-Seiten über die .htaccess geändert werden, wohingegen das bei php nicht geht. Im Netz konnte ich dann noch lesen, dass wenn in der httpd.conf der AllowOverride-Parameter auf enabled gesetzt ist, die Konfiguration über die htaccess auch bei PHP-CGI funktionieren würde (siehe https://stackoverflow.com/questions/4117572/using-htaccess-with-fastcgi), jedoch ist dieser Parameter bei IONOS auf disabled gesetzt.

    @Hans-Gerd Gerhards: wie du sicher gelesen hast, habe ich bereits Plugins ausprobiert (bspw. HTTP Headers). Plugins schaffen aber auch keine neuen Möglichkeiten, sondern bedienen sich vorhandener Möglichkeiten, wie beispielsweise Header setzen über die .htaccess, und übernehmen dann lediglich die „komplizierte“ technische Konfiguration. Möglicherweise hätte sich ein anderes Plugin einer anderen technischen Möglichkeit bedient und daher funktioniert, aber ich wollte zunächst verstehen, warum die Konfiguration über die htaccess nicht funktioniert.
    Und zu deinem 2ten Hinweis: Die Seite über eine htpasswd zu schützen, kann für den Adminbereich sicher sinnvoll sein, ganz sicher ist es aber kein sinnvolles Mittel um bspw. Cross-Site-Scripting auf einer öffentlichen Homepage zu unterbinden.

    Dennoch möchte ich euch beiden für eure investierte Zeit danken.

    Mit freundlichen Grüßen,
    Milan Binder

    • Diese Antwort wurde geändert vor 4 Jahren, 8 Monaten von ac2124. Grund: Ergänzung einer Quelle
    Thread-Starter ac2124

    (@ac2124)

    Zunächst einmal geht es mir um mehr Sicherheit, also X-XSS-Protection, X-Frame-Options, HSTS, CORS, CSP, … die Standard-Security-Header. Im Anschluss will ich natürlich auch über sinnvolle Caching-Richtlinien (Cache-Control-Header) einen Geschwindigkeitszuwachs erreichen.

    Bei Strato hat das setzten der gewünschten Header über die htaccess ja auch wunderbar funktioniert. Leider hosten wir unsere Website nicht bei Strato…

    Korrigiere mich wenn ich das falsch sehe, aber die htaccess ist eine serverseitige Konfiguration. Was du möglicherweise meinst ist, dass der Hoster verhindert, dass die entsprechenden Header über die htaccess gesetzt werden…? Ich weiß nicht, ob das möglich ist, da kenne ich mich nicht aus, aber selbst wenn es die Möglichkeit gibt: Da die Header bei der Auslieferung einer einfachen HTML Seite, die im gleichen Webrootverzeichnis liegt, korrekt ausgeliefert werden, können wir davon ausgehen, dass die Header prinzipiell über die htaccess gesetzt werden können.

    Thread-Starter ac2124

    (@ac2124)

    Hallo hupe13,

    danke für die schnelle Reaktion und deine Hilfsbereitschaft.

    Was will ich erreichen: Ich möchte über die .htaccess-Datei HTTP-Header setzen. Das sollte über eine Headerdirektive in der htaccess (mod_headers) eigentlich kein Problem sein, ist es aber scheinbar, da die Header bei mir nicht entsprechend der Direktiven der .htaccess ausgeliefert werden (geprüft über mehrere Websiten, die auf die entsprechenden Header prüfen und über die Developerkonsolen in Chrome und Firefox). Die HTTP Header können ja auf mehreren Ebenen gesetzt und zurückgesetzt werden. Wenn ich aber eine neue WordPressinstallation habe und eine Headerdirektive in die htaccess schreibe, würde ich erwarten, dass dieser HTTP Header auch ausgeliefert wird.

    Im Supportforum des Plugins nachfragen scheint mir zum aktuellen Zeitpunkt nicht sinnvoll, da ich ja in einer neu aufgesetzten WordPressinstanz ohne das Plugin genau das gleiche Problem habe, dass manuell in der htaccess hinzugefügte Headerdirektiven nicht mit der WordPressstartseite ausgeliefert werden. Die Möglichkeit, dass die htaccess fehlerhaft sein könnte sehe ich als widerlegt an, da wenn ich ein einfaches HTML-Dokument im gleichen Webroot ablege und aufrufe, bei diesem Dokument die gleiche htaccess zu den gewünschten HTTP Headern führt (also bei einem Aufruf ohne das ganze WordPressprocessing, weshalb ich in Richtung Problem mit WordPress dachte).

    Mittlerweile habe ich allerdings noch bei einem 3ten Hoster (Strato) eine WordPressinstanz aufgesetzt. Ebenfalls ohne Plugins und nur mit dem Standardtheme. Hier habe ich die gleiche .htaccess angelegt wie auch auf den anderen WordPressinstanzen: Hier werden die HTTP Header wie gewünscht ausgeliefert. Ich denke daher nicht länger an ein Problem in WordPress. Stattdessen werde ich mit dieser Erkenntnis zunächst erneut auf meinen Hoster zugehen.

    Über weitere Ideen oder Ansätze, wie es zu dem Problem kommen kann, wäre ich natürlich weiterhin dankbar. Vielleicht eine ungünstige Konfiguration im Webserver des Hosters? Vielleicht weiß dazu ja jemand mehr oder hat zumindest einen Hinweis für mich…oder vllt gibt es ja doch auch WordPresskonfigurationen in dieser Richtung >> möglicherweise irgendeine PHP Routine, welche die HTTP Header nochmal bearbeitet und die für gewöhnlich aktiviert ist, und die der Hoster Strato bei seinen automatisierten WordPressinstallationen eben deaktiviert?

    Mit freundlichen Grüßen,
    Milan Binder

Ansicht von 3 Antworten - 1 bis 3 (von insgesamt 3)