webEdition - Forum

Hallo zusammen,
ich will beim Versenden von Newsletter die Email des jeweiligen Abonnenten zum Abmelden ein bisschen verschlüsseln damit wenigstens keiner direkt andere Personen einfach abmelden kann. Ich verwende dafür $GLOBALS['WE_MAIL'] um die Email auszulesen. soweit funktioniert auch alles super: /unsubscribe.html?email=<?php echo $GLOBALS['WE_MAIL']; ?>

Das Abmelden funktioniert mit der Email in Klarsicht perfekt.

Sobald ich base64_encode($GLOBALS['WE_MAIL']) verwende, wird hier immer nur '###EMAIL###' codiert ausgegeben.

Weiß da jemand weiter?
Ich weiß, dass dies kein guter Schutz ist aber es ist definitiv besser als die Email direkt anzuzeigen. Vielleicht hat auch hier jemand einen Tipp, um das Abmelden noch sicherer zu machen.

Hi,
Du könntest Dir vielleicht in der Kundenverwaltung (oder arbeitest Du mit einer csv?) einen hash zum USer ablegen, den Du immer mit dem Link übergibst und dann gar nicht mit der Email-Adresse arbeitest - oder in Kombination. Das Abmelden wirst Du dann aber nicht nativ über we-tags bewerkstelligen können...

Hallo,
danke für deine Antwort. Wir arbeiten mit der Kundenverwaltung und ich will es eigentlich so einfach wie möglich machen und momentan keine zusätzliche Felder anlegen. Die we-Tags zum An- und Abmelden nutzen wir nicht, da haben wir was eigenes. Ich will eigentlich nur schnell bestehende Vorlagen anpassen und mit base64_encode($GLOBALS['WE_MAIL']) ergänzen aber es scheint nicht zu funktionieren.

$GLOBALS['WE_MAIL'] gibt die Email beim Newsletterversand korrekt aus, sobald ich encoden will mit base64_encode($GLOBALS['WE_MAIL']), wird stattdessen ###email### genommen. Ich verstehe die Logik dahinter nicht oder habe ich da einen Denkfehler?

also wenn die Variable Globals den Wert ausspuckt, musst Du da auch drauf zugreifen können und mit dem Wert machen können was Du willst. Versuch mal das und steck dann $email an den Link ran... so richtig Sinn macht das Verhalten für mich aber ach nicht...

Hi, hab ich auch schon probiert und dann versucht $email zu encoden. Kommt trotzdem immer verschlüsselt ###email### raus. Das ist ja das merkwürdige, was ich nicht kapiere.

prüfts Du das beim korrekten Versand oder nur in der Vorschau? In der Vorschau steht nämlich immer ###email### drin, erst wenn das Ding korrekt als Kampagne verschickt wird, wird die Adresse je recipient gesetzt

Ich prüfe das schon direkt im erhaltenen Newsletter.

Nein. Im Newsletter wird ein Template erstellt, was danach mit den Werten befüllt wird. Eine Auswertung pro NL würde viel zu viel Ressourcen kosten.

Hallo,
was ist damit genau gemeint? Eine Auswertung benötige ich hier nicht.

"ein. Im Newsletter wird ein Template erstellt, was danach mit den Werten befüllt wird. Eine Auswertung pro NL würde viel zu viel Ressourcen kosten.

Ich habe den Testnewsletter an mehrere Test-Emailadressen versand und zur Probe die Email mit $GLOBALS['WE_MAIL'] ausgegeben und mit base64_encode($GLOBALS['WE_MAIL']).
Bei $GLOBALS['WE_MAIL'] wird die Email immer korrekt ausgegeben, bei base64_encode($GLOBALS['WE_MAIL']) immer codiert ###EMAIL###.

Ich kann das Verhalten einfach nicht nachvollziehen. Gibt es sonst eine andere Möglichkeit auf die Email-Adresse zuzugreifen?

Hi, noch einmal hoch mit dem Problem!
Weiß wirklich keiner weiter? Werde sonst ein Ticket im Bug Tracker eröffnen.

Gruß
Heiko

Du kannst dieses Feld nicht bei der NL-Generierung beeinflussen oder weiterverarbeiten. Das ist so nicht vorgesehen.

Danke für die Antwort,
eine andere Lösung gibt es nicht?
Kann man nicht irgendwie separat die Email erhalten z.B. über eine Datenbankabfrage?

So kann man ja einfach andere aus dem Newsletter abmelden, vorausgesetzt man kennt die Email.

Gruß Heiko

Ich muss das hier noch einmal aufgreifen.

Ich habe es jetzt auch mit einer Datenbankabfrage beim Newsletterversand getestet, das funktioniert nicht.
Ein separates Feld in der Datenbank habe ich auch angelegt und versucht mit $GLOBALS drauf zuzugreifen, funktioniert auch nicht.

Hat irgendeiner noch eine Idee? mokraemer?

Gruß
Heiko

Hallo zusammen,
habe nun einen Feature-Wunsch im Bug Tracker angelegt. Ich hoffe, da passiert dann auch was.
Emailadressen statt einem Hashwert ausgeben ist 2017 nicht mehr ganz aktuell

Gruß
Heiko

Zur Info... ID in der Bugbase: #11393