error 301 when rendering

schrieb ich doch…

Sonst versuch’ es mal so:

RewriteCond %{HTTPS} off

RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

1 „Gefällt mir“

DANKE ; jetzt funktioniert der Weiterleitung.

Und die 301 scheinen auch weg zu sein :-))

bis auf einen am Anfang:

Den ersten 301 Redirect bekommst Du nicht weg, wenn die Seite mit http aufgerufen wird, da die Condition aus der ersten Zeile erst eine Anweisung geben muss, was mit http: Aufrufen zu tun ist.

Die Condition der zweiten Zeile verhindert übrigens, diese Regel für eine Anfrage per https greift – es würde sonst eine Schleife entstehen.

1 „Gefällt mir“

Was den Fehler angeht:

zu früh gefreut: der Fehler ist heute wieder da, jetzt halt mit https: statt mit http: in der Fehlermeldung

[17-Oct-2017 13:55:43 Europe/Berlin] PHP Fatal error: Uncaught RuntimeException: Error when rendering "https://localhost/?action=info&controller=checkout&module=widgets" (Status code is 301). in /home/bioanzue/public_html/vendor/symfony/http-kernel/HttpCache/Esi.php:281

 

Zu diesem Zeitpunkt gab es nur einen Zugriff auf die Haupt-Seite / : (Kanada, ohne erkennbaren Benutzeragent und ohne referrer)

Es könnte also ein Bot sein der irgendwas abgreifen will…?

158.85.81.116
	
/
	
17.10.17, 13:55
	
7819
			
HTTP/1.1

 

Hattest Du mal eine lokale Testumgebung ? Etwas seltsam ist der Aufruf des Controllers mit https://localhost - da sollte eigentlich Deine Domain stehen …

VG

wieder zu früh gefreut; es war ein paar tage ruhe, jetzt ist er wieder da (mit localhost und normal):

https://bioanzuender.eu/?action=info&controller=checkout&module=widgets" (Status code is 301). in /home/bioanzue/public_html/vendor/symfony/http-kernel/HttpCache/Esi.php:281
Stack trace:
#0 /home/bioanzue/public_html/var/cache/production_201709190948/html/en/0b/5a/ffd817c10ff3ca8bc544517272059e5774cf0f222e9df086e605fa4e8b57(166): Symfony\Component\HttpKernel\HttpCache\Esi->handle(Object(Shopware\Components\HttpCache\AppCache), '/?module=widget...', '', false)
#1 /home/bioanzue/public_html/vendor/symfony/http-kernel/HttpCache/HttpCache.php(648): include('/home/bioanzue/...')
#2 /home/bioanzue/public_html/vendor/symfony/http-kernel/HttpCache/HttpCache.php(213): Symfony\Component\HttpKernel\HttpCache\HttpCache->restoreResponseBody(Object(Symfony\Component\HttpFoundation\Request), Object(Symfony\Component\HttpFoundation\Response))
#3 /home/bioanzue/public_html/engine/Shopware/Components/HttpCache/AppCache.php(116): Symfony\Component\HttpKernel\HttpCache\HttpCache-> in /home/bioanzue/public_html/vendor/symfony/http-kernel/HttpCache/Esi.php on line 281
[24-Oct-2017 09:36:55 Europe/Berlin] Stripe Notice: Undefined property of Stripe\Source instance: customer
[24-Oct-2017 19:16:57 Europe/Berlin] PHP Fatal error: Uncaught RuntimeException: Error when rendering "https://localhost/?action=info&controller=checkout&module=widgets" (Status code is 301). in /home/bioanzue/public_html/vendor/symfony/http-kernel/HttpCache/Esi.php:281
Stack trace:

Komt mir wie ein cache-Problem vor.

 Was genau macht diese Datei (Verzeichnis: bin/vendor/ocramius/proxy-manager/ (Mich interressiert insbesondere dieser Codeschnipsel, wegen dem localhost-Fehler den ich immer noch habe )

Ist wie immer nur ein Strohhalm; sonst kann ich keinen localhost finden

$factory = new \ProxyManager\Factory\RemoteObjectFactory(
    new \ProxyManager\Factory\RemoteObject\Adapter\XmlRpc(
        new \Zend\XmlRpc\Client('https://localhost/xmlrpc.php')
    )
);

Hi,

scheint irgendwas mit der API zu tun zu haben:

VG

ja, irgendwas greift von außen zu und erzeugt den fehler

beim zugriff genau zu diesem Zeitpunkt ist der Benutzer-Agent und die referrer-Url leider leer

Edit:

Aber im log findet sich folgendes IP aus hanoi:

125.212.217.215 - - [11/Nov/2017:23:08:56 +0100] "GET / HTTP/1.1" 301 - "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36"
125.212.217.215 - - [11/Nov/2017:23:08:58 +0100] "GET / HTTP/1.1" 200 33952 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36"
125.212.217.215 - - [11/Nov/2017:23:09:04 +0100] "" 500 7839 "-" "-"
125.212.217.215 - - [11/Nov/2017:23:09:06 +0100] "" 500 7839 "-" "-"
125.212.217.215 - - [11/Nov/2017:23:09:07 +0100] "" 500 7839 "-" "-"
125.212.217.215 - - [11/Nov/2017:23:09:08 +0100] "" 500 7839 "-" "-"
125.212.217.215 - - [11/Nov/2017:23:09:09 +0100] "" 500 7839 "-" "-"
125.212.217.215 - - [11/Nov/2017:23:09:13 +0100] "quit" 500 7839 "-" "-"
125.212.217.215 - - [11/Nov/2017:23:09:19 +0100] "" 500 7839 "-" "-"
125.212.217.215 - - [11/Nov/2017:23:09:23 +0100] "GET /media/image/36/26/e0/favicon16.jpg HTTP/1.1" 200 1220 "-" "python-requests/2.18.4"

 

Hi,

das könnten auch Bots sein, die nach Wordpress Instanzen suchen (xmlrpc.php ist eine Standard Datei die zu Wordpress gehört - diese wird z.B. benötigt, um auf die Wordpress API per Smartphone zuzugreifen).

VG

So sehen die Zugriffe in  der Regel aus (hier mal einer aus DE m it 408, die meisten mit 500):

 

88.133.153.76 - - [16/Nov/2017:17:04:05 +0100] "-" 408 - "-" "-"
88.133.153.76 - - [16/Nov/2017:17:04:05 +0100] "-" 408 - "-" "-"
88.133.153.76 - - [16/Nov/2017:17:04:05 +0100] "-" 408 - "-" "-"
88.133.153.76 - - [16/Nov/2017:17:04:05 +0100] "-" 408 - "-" "-"
88.133.153.76 - - [16/Nov/2017:17:04:05 +0100] "-" 408 - "-" "-"
88.133.153.76 - - [16/Nov/2017:17:04:05 +0100] "-" 408 - "-" "-"

und hier einer mit etwas mehr info

71.6.165.200 - - [16/Nov/2017:06:10:43 +0100] "GET / HTTP/1.1" 301 - "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36"
71.6.165.200 - - [16/Nov/2017:06:10:44 +0100] "GET / HTTP/1.1" 200 33952 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36"
71.6.165.200 - - [16/Nov/2017:06:10:46 +0100] "" 500 7839 "-" "-"
71.6.165.200 - - [16/Nov/2017:06:10:48 +0100] "" 500 7839 "-" "-"
71.6.165.200 - - [16/Nov/2017:06:10:48 +0100] "" 500 7839 "-" "-"
71.6.165.200 - - [16/Nov/2017:06:10:49 +0100] "" 500 7839 "-" "-"
71.6.165.200 - - [16/Nov/2017:06:10:49 +0100] "" 500 7839 "-" "-"
71.6.165.200 - - [16/Nov/2017:06:10:53 +0100] "quit" 500 7839 "-" "-"
71.6.165.200 - - [16/Nov/2017:06:10:56 +0100] "GET /media/image/36/26/e0/favicon16.jpg HTTP/1.1" 200 1220 "-" "python-requests/2.10.0"
71.6.165.200 - - [16/Nov/2017:06:10:57 +0100] "" 500 7839 "-" "-"

Ein paar der gefundenen IPs habe ich gesperrt, aber natürlich kommen dann immer wieder neue.

 

scheint das übliche “Abklopfen” von Schwachstellen zu sein:

https://www.abuseipdb.com/check/71.6.165.200

Hi,

Wordpress Bots kannst Du z.B. auch so in Deiner .htaccess Datei von vornherein aussperren - diese “tasten” Domains immer nach dem gleichen Muster ab und prüfen auf das Vorhandensein bestimmter Dateien. Für Wordpress z.B. Zugriff auf xmlrpc.php und wp-login.php sperren - Beispiele:

http://techbloghunting.com/2017/08/28/using-htaccess-restrict-access-files-directories/

 

 

 

Schade, das Sperren speziell dieser beiden Dateinen nutzt leider nix:

169.54.244.75 - - [17/Nov/2017:21:23:57 +0100] "GET / HTTP/1.1" 500 7839 "-" "-"

Wie kriege ich raus, welche Dateien da noch abgefragt werden könnten ?