mod_proxy user-agent im request header ändern

[jmar83]

hallo zusammen

weiss jemand wie das geht und ob?

mein provider sperrt ein paar bots, u.a. auch von majestic.com, ich brauch das aber für seo...

habe eine java-junit-testapp geschreiben, akzepiert wird:

////
URLConnection c = clURL.openConnection();
// c.setRequestProperty("User-Agent", "MJ12bot");
// lInputStreamReader = new InputStreamReader(clURL.openStream());
lInputStreamReader = new InputStreamReader(c.getInputStream());
////

NICHT aber:

////
URLConnection c = clURL.openConnection();
c.setRequestProperty("User-Agent", "MJ12bot");
// lInputStreamReader = new InputStreamReader(clURL.openStream());
lInputStreamReader = new InputStreamReader(c.getInputStream());
////

scheinbar erlaube mein doofer shared-hosting-provider das überschreiben per .htaccess nicht. nun gibt's noch einen weg: die umleitung von www.domain.com nach domain.com erfolgt bei mir z.zt. über einen linux-vserver (also voll root rechte) über mod_proxy...

wie kann ich mod_proxy nun dazu veranlassen den request-header umzuschreiben, falls dort drin "user-agent: MJ12bot" drin steht... kann meintwegen umgeschreiben werden nach "user-agent: blabla" oder wie auch immer, falls als wert für den user-agent "MJ12bot" reinkommt..

danke für die feedbacks.

[jmar83]

was .htaccess betrifft habe ich beim shared-hosting-provicer folgendes gemacht, scheint aber nicht akzeptiert zu werden vom server (inzwischen halt auskommentiert):

# BEGIN User
#SetEnvIfNoCase User-Agent "MJ12bot" good_bot
#<Limit GET POST HEAD>
#Order Allow,Deny
#Allow from all
#Allow from env=good_bot
#</Limit>
# END User

[jmar83]

Problem gelöst:

<LocationMatch "/robots.txt">
ProxyPass http://www.xyz.info.tm/robots.txt
ProxyPassReverse http://www.xyz.info.tm/robots.txt
Header add X-Robots-Tag "noindex, follow"
RequestHeader set X-Robots-Tag "noindex, follow"
RequestHeader set User-Agent "Googlebot"
</LocationMatch>

"die umleitung von http://www.domain.com nach domain.com erfolgt bei mir z.zt. über einen linux-vserver (also voll root rechte) über mod_proxy..."

Besser gesagt: die Umleitung von www.domain.xyz nach www.domain.info.tm erfolgt bei mir z.Zt. über einen Linux-vserver...

[Nobbie]

Ich würde dennoch überlegen, den Provider zu wechseln. Erscheint mir ziemlich restriktiv. Oder gleich einen vServer nehmen, was ist denn das für ein linux-vserver, wieso benutzt Du den nicht für Deine Seiten?

[jmar83]

Der Server läuft mit Debian und Plesk, viel mehr als ab und zu "apt-get update" sowie "apt-get upgrade" muss ich nicht machen um den stabil und sicher zu halten. Sonst will ich nicht gross eingreifen dort, die mod_proxy-konfig konnte ich auf in ein Textfeld im Plesk schreiben. Alles ziemlich problemlos.

Vorübergehend kann ich mit dieser "Lösung" noch leben, war schon vorher so, habe nicht extra deswegen (majestic.com-Problem) die Domain mit http://www.domain.xyz auf dem Vserver mit mod_proxy eingerichtet. Beim shared-Hoster ((www.)domain.info.tm) läuft derzeit ein WordPress-System, dort müsste ich dann halt ein paar Sachen migrieren: Domain- sowie interne Webserver-Pfad-Angaben in den konfig-Files, irgendwelche Verzeichnis- und Dateiberechtigungen ("chmod") etc. Ehrlich gesagt gerade null Bock auf sowas! Die MySQL-Datenbank läuft auf einer Windows-Server-VM bei einem Kollegen zuhause, weil ich auch "Stored Procedures" und "Views" verwende. (Das ist bei shared-Hostern grundsätzlich nie möglich)

Die .info.tm-Domain hatte ich am Anfang des Projektes, da kostenlos. Später habe ich gemerkt dass

a.) die .info.tm-Domain bei Google nicht problemlos indexiert wird (Obwohl: https://www.google.ch/search?q=site%3Ai ... e&ie=UTF-8 ) - würde wohl tonnenweise Backlinks erfordern oder so? (Bing und Yahoo scheint's hingegen nicht zu stören, aber ich habe es nun in PHP so geschrieben, dass .info.tm nach .xyz umgeleitet wird per 302 falls man, oder ne Suchmaschine, darauf zugreift)

b.) eine .xyz-Domain schlicht professioneller aussieht als .info.tm (noch "bessere" tld's waren leider schon besetzt)


...noch etwas später habe ich für bestimmte Anforderungen eines Kunden einen Vserver gebraucht, so habe ich dann gedacht ich könnte den vorerst auch nutzen um die .xyz-Domain im Hintergrund per mod_proxy auf die alte Domain umzuleiten. Sollte eh mal alles umgekrempelt werden, das WordPress-Frontend habe ich mal durch eine Eigenentwicklung (mit Laravel und Smarty) ausgetauscht.

Der WordPress-Backend-PHP-Code wird dann wohl beim alten shared-Hoster bleiben, und den Content auf den MySQL-Server beim Kollegen schreiben. Da dort Port 3306 für bestimmte IP's und User geöffnet wird, ist eigentlich alles ziemlich von einander losgelöst. So kann ich es wohl vorerst verhindern, das WordPress komplett migrieren zu müssen, und mein Laravel/Smarty-Frontend sonstwo (egal) hosten. -> Einfach im konfig-File (".env") die entsprechenden MySQL-Parameter hinterlegen, und gut ist!

Hätte ich aber den Vserver und die .xyz-Domain von Anfang an gehabt, dann wäre es sicher nicht soweit gekommen! Der aktuelle shared-Hoster ist aber das "geringste Übel" das ich bezüglich shared-Hosting jemals hatte. (In den letzten 12 Jahren sicher 5x gewechselt, aber selber schuld, will halt immer möglichst wenig Geld dafür ausgeben)

[Nobbie]

Hätte ich aber den Vserver und die .xyz-Domain von Anfang an gehabt, dann wäre es sicher nicht soweit gekommen! Der aktuelle shared-Hoster ist aber das "geringste Übel" das ich bezüglich shared-Hosting jemals hatte. (In den letzten 12 Jahren sicher 5x gewechselt, aber selber schuld, will halt immer möglichst wenig Geld dafür ausgeben)

Wahrscheinlich hast Du ein x-faches an Manpowerkosten gehabt, als es ein vernünftiges System von Anfang an gekostet hätte.... Immer nur "billig, billig" wird immer viel teurer als von Anfang an "richtig".

[jmar83]

Da hast Du natürlich 100%ig recht, sicher.

Wobei ich sagen muss, dass a.) ein (guter!) shared-Hoster in Kombination mit b.) einem eigenen MySQL-Server gar nicht mal sooooo schlecht ist. Der Hoster kann dann schön auf Apache/PHP schauen, fleissig Updates vornehmen und Sicherheitslücken schliessen etc. Und ich kann mit dem MySQL-Server alles mögliche nutzen, nicht nur simple SQL Queries.. (Wenn es der Hoster unterstützt, kann mal natürlich auch eine andere Datenbank verwenden)

Aber noch nen 3. Server als reverse-Proxy, ne!!

[Nobbie]

Wobei ich sagen muss, dass a.) ein (guter!) shared-Hoster in Kombination mit b.) einem eigenen MySQL-Server gar nicht mal sooooo schlecht ist.

Da sind wir einer Meinung. Konkret bin ich beispielsweise mit all-inkl.com sehr zufrieden, die machen einen guten Job und das "KAS" (das Administrationssystem) ist wirklich sehr gelungen und die Leistung stets zeitgemäß. Aktuell haben die mir von "Lets Encrpyt" kostenlose Zertifikate eingebunden (per Knopfdruck, sehr angenehm!) und wie ich gerade gelesen habe, sind die auch bei PHP schon bei PHP7.1 angekommen (wahlweise ab PHP5.5). Sehr gut, kann man nicht anders sagen (auch wenn ich es gar nicht brauche, im Gegenteil, es gibt immer noch massenhaft bekannte CMS etc. die sich nicht mit PHP7 vertragen). Und ich habe auch keine schlechten Erfahrungen in Sachen Stabilität gemacht, ich bin (s.o.) wirklich sehr zufrieden.

Im Vergleich dazu, ich habe auch noch eine Seite bei 1blu.de - naja, teuer sind sie inzwischen auch und trotzdem haben wir regelmäßig Ausfälle. Und Ahnung haben die Jungens auch nur durchschnittlich. So ist das halt,ich habe eben auch mal nach "billigen" Anbietern geschaut, der liebe Gott straft es natürlich ab. Selbst Schuld....

[Altrea]

Ich bin bei all-inkl auch mehr als zufrieden. Meiner Meinung nach schon seit vielen Jahren der beste deutsche Hoster.

Ein Kunde von mir hat seinen Webspace bei domainfactory. Gibt da zwar auch einen sehr hohen Verfügbarkeitsgrad, aber Let's Encrypt wollen sie nicht unterstützen. Wahrscheinlich wollen die immernoch ihre eigenen SSL Zertifikate verkaufen. Paar Euros sind immernoch besser als garkeine...

Wenn man etwas mehr Freiheit haben möchte könnte ich noch Uberspace empfehlen. Hier kann man sogar selbst den Preis bestimmen.

[jmar83]

Also mit dem Linux-Vserver bei alfahosting.de ("Cloud Server", das günstigste Angebot) bin ich mehr als zufrieden, läuft bestens! Das Teil ist in ein paar Sekunden neu gestartet, geht wirklich zackig!!

Am besten nicht allzu viel "basteln" mit dem root-Zugriff, und fleissig die Pakete updaten. (Geht sogar automatisch) Dann kann (grundsätzlich) nicht viel passieren und das System läuft sehr stabil mit Plesk.

Kostet fast nix!

[jmar83]

Code Update: Besser so:

Code: Select all

#
SetEnvIfNoCase User-Agent "MJ12BOT" mj12bot
RequestHeader set User-Agent "Googlebot" env=mj12bot
#


...also den user-agent, falls er den String "MJ12BOT" ("case-insensitive") enthält, nach "Googlebot" ändern. Und das bei allen Zugriffen, nicht nur server.xyz/robots.txt! Sonst so sein lassen, wie es ist.