Beiträge von ThomasChr

    My 2 cents:

    - 700 MB Datenbank ist echt nicht viel. Eine vernünftige DB Struktur kann das problemlos handeln. Von viel reden wir hier erst ab ein paar hundert GB...

    - Aber die Datenbank vom Webhosting sollen wohl langsam sein... das kann deine Probleme verursachen

    - Ja, ein Managed Server sollte das Problem beheben. Wobei du hier auch nicht viel selbst machen kannst. Das ist genau wie Webhosting nur dass der Server halt nur mit dir belegt ist.

    - Wirklich flexibel bist du nur mit einem eigenen Server, DEN musst du aber natürlich auch selber verwalten können

    Hast Du dort mod_rewrite? Dann erstelle eine RewriteRule, die den X-Forwarded-Host prüft und entsprechend ein anderes Verzeichnis ausgibt. Je nachdem was der Apache da ausliefert, könnte das allerdings schwierig werden, weil die Anwendung dahinter mit solchen Tricks nicht klar kommt.

    Oder Du schaust mal, ob man den DocumentRoot o.ä. in einem IF-Block anpassen kann. Dort könnte man nämlich auch beliebige HTTP-Header auswerten.

    Ich denke ich mach es jetzt erstmal wie jeder gute Devops Mitarbeiter.... Ich schiebe die Schuld auf die anderen.

    Aber ja, das sind schonmal ein paar gute Tipps. mod_rewrite gibts natürlich, der Server ist unter meine Kontrolle. Nur ned das komische Proxy Zeugs davor!

    Hallo Forum,

    ich brauch mal nen kleinen Schubs in die richtige Richtung. Bei einem Kunden habe ich die Domain a.de und b.de - beide zeigen auf die gleiche IP.

    Diese IP ist ein Proxy der die Requests direkt an einen Apachen weitergibt (der Apache steht in einer DMZ on premise und der Kunde hat das zusammengebastelt).

    Nun will ich dass a.de vom Apachen aus einem anderen Ordner ausgeliefert wird als b.de.

    Normalerweise mach ich nun zwei Seiten (Virtual Hosts) im Apachen mit dieser config;

    Code
    <VirtualHost *:80>
            ServerName a.de      
            DocumentRoot /var/www/a
    </VirtualHost>
    
    <VirtualHost *:80>
            ServerName a.de      
            DocumentRoot /var/www/b
    </VirtualHost>

    Afaik matcht der Apache nun den Host-Header im http request gegen den ServerName und weiß nun wo er hin muss. ABER der Proxy sendet sich im Host-Header - und den eigentlichen Host im "X-Forwarded-Host" mit.

    Code
    GET /la.html HTTP/1.1
    Host: 192.168.0.10
    Upgrade-Insecure-Requests: 1
    X-Forwarded-Proto: https
    X-Forwarded-For: 91.49.174.137
    X-Forwarded-Host: www.a.de
    X-Forwarded-Server: www.a.de
    Connection: Keep-Alive

    Wie kann ich nun ServerName sagen dass es nicht gegen den Host-Header sondern gegen den X-Forwarded-Host-Header prüfen soll?

    Trotz einiger Google Suchen find ich immer nur wie ich den Apachen als Proxy konfiguriere und ihn dazu bringe den X-Forwarded-Host Header zu setzen. Nicht mein Problem dass ich abhängig von diesem Header meinen virtuellen Host (und damit den Ordner aus dem die Seite geholt wird) auswählen will.

    Das kann doch jetzt nix außergewöhnliches sein, oder?

    Thomas

    Hatte mich da mal informiert. Das nginx geht gut. Das Hauptproblem ist dabei aber dass du eine rtmp stream kriegst den der browser nicht direkt anzeigen kann. Jeder müsste VLC oder ein ähnliches Programm nehmen...

    Hatte dann irgendwann aufgegeben den Stream direkt in den Browser (wie man es halt von youtube und co kennt) zu bringen...

    Hier meine Anleitung:

    Nach einem langen Gespräch bin ich nun allerdings auf dem Stand: Wieso hängen wir an diesen Begriffen? Geht wirklich die Welt unter, wenn man stattdessen "Allow-/Blocklist" und "Primary/Secondary" oder "Leader/Follower" einführt? Es ist mit Sicherheit nicht unsere größte Baustelle in der aktuellen Zeit, aber wenn man mal objektiv drauf schaut, spricht auch nicht wirklich etwas gegen diese Änderung.

    Gleiche Meinung bei mir schon auch. Die Sprache entwickelt sich und manche Begriffe verändern sich.

    Was mich hier nur so sehr ärgert ist der Grund warum wir meinen diese Begriffe ändern zu müssen!

    Ich wollte damit nur sagen dass manche Sicherheitslösungen meistens mehr Probleme verursachen als das sie lösen.

    Und umso umfangreicher und toller, umso tiefer sitzen die im System drin und umso mehr Probleme erzeugen die oftmals.

    NinjaFirewall scheint mir da ein schönes Beispiel zu sein. Laut der Beschreibung klemmt der sich ja in jede Anfrage die an Wordpress geht.

    Das erscheint mir ziemlich gruselig und übertrieben.

    Wordpress ist nicht so unsicher wie alle immer behaupten. Nur gut gepflegte Plugins und Themes, starke Passwörter, vielleicht noch ein htaccess Schutz auf /wp-admin und fertig ist die Laube. Irgendein dahergelaufendes Securityplugin zu installieren reißt da wahrscheinlich mehr Lücken auf als das es stopft.