Claudiocool

Ich hatte das auch mal bei einer Mail im 1.6.1.7, aber das ist schon ewig her und ich weiß nicht, wie das damals gelöst wurde, eventuell hilft es mir schon weiter, wenn ich sehe, mit welchem Script die Mails erzeugt werden, da hatten wir damals irgendwo den Teil des Links entfernt, der dafür verantwortlich war. Wie gesagt, zu lange her

Hallo zusammen, ich habe heute von einem Kunden erfahren, dass er in Kundenmails, die er als Antwort erhält, nicht mit Klick auf den Link seine Antwort posten kann, weil dieser ins Leere läuft. Der Link an sich wird zwar richtig gesetzt, sogar als solcher angezeigt, aber wenn er draufklickt, wird unser Admin-Verzeichnis vorangestellt. Das ist in zweierlei Hinsicht blöd, einerseits wird der Kunde auf die "Seite-nicht-gefunden"-Umleitung gelegt und andererseits wird da auch noch die Admin-URL offengelegt, was dann andere unerwünschte Effekte haben könnte. man kann zwar den Link in den Übersetzungen von reply_msg editieren und dort auch das Admin-Prefix entfernen, aber direkt nach dem Speichern steht es dort wieder drin. Jetzt die Frage, wie kommt das immer wieder da rein, und wie kann man das abstellen?

In der Kasse bleibt es doch dieselbe Summe. Bei Preisen mit Umsatzsteuer mußt du ja die Steuer beim FA abliefern, dann hat der Artikel auch nur noch netto 25,20 eingebracht, also exakt denselben Preis wie im Drittland. Da der Drittlandkunde später auch noch Abgaben im eigenen Land haben wird, ist er danach genausoviel Geld (zumindest ähnlich viel) los wie der 19%-Kunde. Wenn du Kleinunternehmer bist, darfst du an keiner Stelle mit Umsatzsteuer arbeiten, da ist der Drittlandkunde dann unter Umständen mehr Geld los und wird dort kaufen, wo das obige zutrifft. Aber egal, wie du den Drittlandkunden jetzt benachteiligen willst, mach es und du musst dann auch nicht mehr extra zum Paketshop fahren

Ich weiß ja, wo der Link im Code ist, allerdings kenne ich die Syntax der Abfrage nicht, die nötig wäre. Bis vor ein paar Tagen hat es ja noch funktioniert.

Hallo zusammen, ich nutze das native Modul, um die VAT-ID abzfragen, wenn sich ein Kunde damit anmeldet. Bisher haben die Abfragen über den Webservice geklappt, seit ein paar Tagen kommt hier die Meldung, dass die Abfrage nicht möglich ist. Weiß jemand, ob sich da was an dem Abfragelink geändert hat in der VIES-Datenbank?

Caches löschen, vermutlich sucht der Caches, die so gar nicht im Backup existiert haben

Normalerweise sollten die Provider schon ihre Maßnahmen treffen, um DDOS-Atacken abzuwehren, so dass man davon eigentlich nichts mitbekommen sollte. Dazu dann eine sauber eingerichtete modsecurity-Firewall mit Fail2Ban im Hintergrund sollte das sofort abwürgen können.

Werden die gängigen Firewalls eingesetzt?

Das sind Crawler, ist also normal, anhand der Serverlogs kann man sehen, wer es ist (referrer) und dann ggf. in der htaccess für Ruhe sorgen. Allerdings nicht immer eine gute Idee, denn andererseits hast du sicher nichts dagegen, bei Suchmaschinen gefunden zu werden.

Das dürfte vermutlich ein Crawler sein, die kommen bei uns auch immer wieder und legen 3 Teile in den Cart. In der robots.txt kann man sich das verbitten, indem man Disallow: /*de/warenkorb Disallow: /*en/cart eingibt für die jeweiligen Sprachen und wie der Warenkorb da so heisst. Sollte das den Crawler nicht beeindrucken und er macht weiter, kann man ihn dann mit einem Ausschluss in der htaccess belohnen: SetEnvIfNoCase user-Agent {hier den Namen des Bots einsetzen} spam_ref=1 Also Beispielsweise SetEnvIfNoCase user-Agent MJ12bot spam_ref=1 Und dann die Aktion definieren. <Limit GET HEAD POST> order deny,allow Deny from env=spam_ref </Limit> Den Namen des Bots kann man sich aus den Serverlogs holen, damit hat man schnell Ruhe.

Vielleicht interessiert es ja auch andere, wie du das hingebogen hast, das könnte in der Tat nützlich sein.

Hallo zusammen, im BO wird einem, wenn ein Kunde eine Rücksendung auslöst, der Zähler bei aktuell anhängig hochgesetzt, wie eben auch bei Bestellungen. Bestellungen verschwinden aus dem Zähler, wenn man sie versendet hat, bei den Retouren ist das nicht der Fall. Ich gehe davon aus, dass ich da irgendwo was anhaken muss, um auch hier den Zähler nach Erledigung der Sache zu reduzieren. Wo?

Es kann viele Gründe haben, aber nachdem es ja mit deaktivierter Firewall läuft, kann man jetzt ja in den Logs nachsehen, welche Regel hier angekratzt wurde. Diese Regeln haben ID's und die kann man dann deaktivieren. Vielleicht genügt es aber auch, die Sensibilität etwas zu reduzieren, hier hat man mehrere Stufen zur Auswahl, zu streng ist bei interaktiven Systemen wie Shops fast immer eine Garantie, dass da einen Falle zuschlägt.

Bei Mod_securuty kann der Hoster, wenn du ihm schilderst, was zu welchem Zeitpunkt passiert ist, in den Protokolldateien nachsehen, welche Regel verletzt wurde und diese eine Regel ausnehmen oder so modifizieren, dass du deine Aktion durchführen kannst, dann bleibt der Rest sicher. Eine IP auszunehmen, ist nicht zielführend.

Bei mir hats grad funktioniert