Hinter dem Link steckt kein wirklicher Empfänger, entsprechend werden keine Daten aus der Empfängerliste verwendet.insideRD hat geschrieben:Hallo,
danke für die Antworten.
Wie sieht es denn mit z.B. Zugangsdaten, die versendet werden, die über Funktionfelder personalisiert verschickt werden.
Diese werden niemals dort frei aufrufbar oder?
Siehe meine Antwort per E-Mail, kann man Passwort-Schutz verwenden oder halt gleich verbieten. Das image-Verzeichnis aber nicht mit Passwort versehen.Ich hatte Ihnen auch eine Mail bezüglich Schutz der Verzeichnisse unterhalb von /userfiles/ geschickt.
Ich habe einmal versucht in folgenden Verzeichnissen .htacces-Dateien mit folgendem Inhalt abzulegen:
../export/Code: Alles auswählen
order deny,allow deny from all
../file/
../Import
Dies führt dazu, dass die Inhalte in den Verzeichnissen nicht mehr über den Browser von überall erreichbar sind. Aus meiner Sicht hat dies auf die Funktion von SWM keine Auswirkungen.
Ist dies ein gangbarer Weg?
Die "Seite" wird immer erzeugt, also der HTML-Code der E-Mail dauerhaft mit dem Versandeintrag archiviert. Löscht man den Versandeintrag, wird auch der HTML-Code gelöscht. Durch "Abtesten" von IDs ist es möglich den unpersonalisierten Text zu sehen, in dem man halt das Script browser.php mit Parametern aufruft. Den personalisierten Text kann nur man sehen, in dem man auch noch die korrekte eindeutige 64-Byte-Zufallszeichenkette des Empfängers verrät, das wird sehr schwierig.Edit:
Wenn man den Tag [AltBrowserLink] nicht in eine Mail einfügt, wird dann diese "ID", bzw. Seite erzeugt oder nicht. Es geht uns darum, dass wird definitiv ausschließen möchten, dass Mails mit Zugangsdaten irgendwie (und wenn es auch unwahrscheinlich zu erraten ist) aufgerufen werden können.