geb ich dir gern ne ANleitung für den Downgrade an die Hand
auch das hat sich bereits erledigt ich mabe mir das selbst "geflickt"
geb ich dir gern ne ANleitung für den Downgrade an die Hand
auch das hat sich bereits erledigt ich mabe mir das selbst "geflickt"
geb ich dir gern ne ANleitung für den Downgrade an die Hand.
dann bitte ich um diese
Wie du aber merkst, drehen wir uns da etwas im Kreis.
ja aber weniger wegen dem neuen feature sondern eher weil du entweder das garnicht erst hättest einbauen sollen ooooder wenn schon dann richtig integieren (zumindest sehe ich das so)
es ist ja aber leider oft so das da nur so halbgares zeug kommt
mfg
Die Meldung kam nicht, weil er bis zu zu diesem Punkt gar nicht kam, um ihn entsprechend melden zu können.
das ist doch aber genau so eine irreführende falschmeldung, wie die "mit manipulierten daten", nur weil ein user mehrere endgeräte nutzt.
es kann ja nicht sein, dass man a.g. der meldungen ständig im ACP rumwackelt um zu prüfen, ob der nun tatsächlich nen doppelacc hat oder NUR ne trashmail.
dazu kommt, dass die meldung nicht immer kommt, was zusätzlich verwirrt. bei manchen usern kommt nur eine trashmail-meldung, bei anderen komm zusätzlich die falsche doppelacc-meldung, was bedeutet, dass wir atm permanent in der log-liste im acp zu gange sind um das gegenzuprüfen.
Das Problem ist aber mit dem aktuellen Update behoben.
ja atm wären wir froh, es wäre NICHT behoben, denn mit einer trashmail-meldung waren wir durchaus zufrieden ... doppelgemoppelt & irreführend brauchen wir bei über 30.000 usern tatsächlich nicht.
und hätten wir vorher gewusst, dass
a) die info abhängig ist, ob sperre eingetragen oder nicht
b) eingetragene sperren NUR manuell zu entfernen sind
hätten wir dir den tag gespart und uns die pl4 (was wohl auch der grund sein kann, warum bisher keiner den "fehler" gemeldet hat)
Der Benutzer wird nach Ablauf der Zeit, bei der nächsten Durchführung des Cronjobs, gesperrt. Außer du nimmst ihn von der Liste.
und da bist du nicht gewillt, etwas dran zu ändern, sodass man dem user die möglichkeit geben kann, seinen account zu retten? (für WSF 2.1 )
denn das ist fast unzumutbar, im acp die sperrliste zu kontrollieren, zu kontrollieren, ob der seine mail-addy geändert hat (womöglich noch mit exotischer trashmail, die einem nicht geläufig ist) um den ggf. dann manuell von der liste zu entfernen.
btw: das wäre auch für doppelacounts sinnvoll, wenn der user durch kontolöschung selbst die möglichkeit hat, einen der 2 acc zu retten.
so, wie das atm arbeitet taugt die trashmail-meldung tatsächlich nur, um reg/änderung mit trashmail zu verhindern. der rest ist eher last als feature, sorry, wenn man das so formulieren muss.
sorry Marcel, bei allem verständnis ...
vllt. solltest du einfach mal ausfühlich kommunizieren, wenn du siehst, dass deine zahlenden kunden offensichtlich probleme mit dem verständnis der funktionsweise haben?
- dein "hinweistext ist allgemein" bezog sich nach deinen eigenen angaben stets auf den inhalt, nicht auf das verhalten (welches bis dato gar nicht zur debatte stand)
Das nach deiner gewünschten Aktion dein gewünschtes Ergebnis nicht eintritt, ist eben so.
was ist das denn für eine aussage?
verständlich wäre das verhalten, wenn der user tatsächlich auch gesperrt wird.
was passiert denn, wenn die eingestellte zeitverzögerung abgelaufen ist? wird der user dann trotzdem gesperrt (auch nach mail-adressen-änderung) oder wird er von der sperrliste entfernt?
Jepp, die Meldung kommt, weil das Plugin immernoch Multihunter heißt und nicht Trashmail Finder
mir kommt es so vor, als wüsstest du selbt nicht, wie das funktioniert
VOR deinem letzten update kam keine doppel-account-meldung sondern eben korrekt NUR eine trashmail-meldung, wenn der user keinen doppelacc hat.
warum sich das plugin nun plötzlich daran erinnert, ja eigentlich alles auch als doppelacc melden zu müssen, weil es dem namen gerecht werden will, scheinst du nicht erklären zu wollen oder nicht zu wissen?
Hat mich jetzt fast den ganzen Abend gekostet, ...
hat sich aber gelohnt
zumindest FAST
ich befürchte, du musst nochmal ein paar minuten ran.
- moderative meldung kommt
- user-info kommt
- user wird auf die sperrliste gesetzt (sperre erfolgt natürlich nicht vor ablauf der frist, bei verzögerter sperre)
und jetzt kommt das ABER ...
- user ändert wie gewünscht die mail-addy innerhalb der frist
adresse ist nun keine trashmail-addy mehr, aber die infobox wird weiter angezeigt
und zwar solange, bis er MANUELL aus der sperrliste entfernt wird
hier fehlt noch eine aktion, die den user von der sperrliste wieder löscht, wenn die erneute prüfung ergibt, dass keine trashmail-addy mehr eingetragen ist.
und ein zweites ABER (wo wir aber noch beobachten, ob das Einzelfälle sind und welche Konstellationen es da gibt)
seit dem update auf 2.0.12 pl 4 erfolgt nicht nur die moderative meldung "trashmail" sondern eine ZWEITE moderative meldung user hat sich mit einem Doppelaccount angemeldet. obwohl es KEINEN doppelaccount gibt sondern nur die trashmail.
weder im userprofil noch im negativ-log ist ein doppelaccount (zweiter user) zu finden.
Meine Aussage geht nicht, bezog sich auf die von dir gewünschte Hinweismeldung.
und das sollte ich wie erkennen? ist ja nicht so, als hatte meine anfrage nur aus diesem einen punkt bestanden
Bei Bedarf nen Info Text
den man selbst festlegen kann? und demnach, wenn wir das ausschliesslich für trashmails nutzen, ...
... eine Allgemeine.
so formulieren könnten, dass sie sich auf "änder deine mail-addy ... blabla" beschränkt?
--------------------------
dann nochmal die frage: woran kann es liegen, dass weder eine info an user rausgeht, noch die eingestellte zeitlich versetzte sperre funktioniert?
die moderative meldung "user xyz hat sich mit einer wegwerfadresse angemeldet." funktioniert (an fehlenden einträgen der trashmail-anbieter kann es also nicht liegen)
- wir möchten, dass diese user eine auto-Info erhalten, dass sie ihre mail-addys ändern sollen
in erreichbare innerhalb xyz Stunden und nach Ablauf der Frist das Konto gesperrt/mindestens deaktiviert wird (=> klappt nicht, wedder die auto-Info, noch i-eine Aktion)
Nein, das ist mit dem Multihunter nicht umsetzbar.
Es wird beim User der den Alarm ausgelöst hat eine infobox auf jeder seite mit den angegebenen text angezeigt.
Beim nächsten Login wird der betroffende Benutzer entsprechend gesperrt, sofern eingestellt.
ja was nun? geht nicht (dein #2)? oder geht doch (dein #7)?
und wenn ja, wieso funktioniert es dann nicht, wie beabsichtigt?
seltsam ist jedoch, dass bereits jetzt für die Automatische Sperre als Kriterium "Trashmail" auswählbar ist, die nach meinem Verständnis so funktionieren sollte
(was sie nicht tut)- auto-Sperre zeitverzögert nach 48 Std.
- vorgegebener Infotext geht an User mit der Möglichkeit, das Problem zu beheben
- 48 Std abgelaufen, User loggt sich ein nach wie vor mit trashmail
- auto-Sperre mit vorgegebenem Sperrgrundatm erfolgt weder eine Info an user und (soweit ich erinnere) auch keine Sperre.
kannst du bitte mal meinen (ich meine ausführlichen und verständlichen) post #3 punkt für punkt analysieren und ggf. beantworten, ob das so korrekt ist und ggf. benennen, warum es dann eben nicht läuft, wie eingestellt?
auch wenn ich mich wiederhole
Wozu ist denn dann die jetzt bereits integrierte auto-Sperre-trashmail bzw. wie funktioniert die denn korrekt (was muss wie eingestellt sein?)
als Beschreibung steht bei dem Feld
Geben Sie hier an, welchen Informationstext der Benutzer zu sehen bekommt bis zum Zeitpunkt seiner Sperrung. Ist dieses Feld leer, wird kein Informationstext angezeigt.
Könnte ich aber für die ferne Zukunft mit auf die ToDo setzen.
Kannst du (kann dich nicht davon abhalten ) nutzt mir aber nichts, weil auch DAS (wie das administrative anlegen Doppelacc MIT Kommentar) kein Grund sein wird, aufs WSC zu wechseln.
seltsam ist jedoch, dass bereits jetzt für die Automatische Sperre als Kriterium "Trashmail" auswählbar ist, die nach meinem Verständnis so funktionieren sollte
(was sie nicht tut)
- auto-Sperre zeitverzögert nach 48 Std.
- vorgegebener Infotext geht an User mit der Möglichkeit, das Problem zu beheben
- 48 Std abgelaufen, User loggt sich ein nach wie vor mit trashmail
- auto-Sperre mit vorgegebenem Sperrgrund
atm erfolgt weder eine Info an user und (soweit ich erinnere) auch keine Sperre.
Wozu ist denn dann die jetzt bereits integrierte auto-Sperre-trashmail bzw. wie funktioniert die denn korrekt (was muss wie eingestellt sein?)
Moin moin,
folgendes ist unser Ziel:
- wir möchten, dass Bestandsuser beim login auf trashmail-addy überprüft werden (=> klappt, moderative Meldung erfolgt auch)
- wir möchten, dass diese user eine auto-Info erhalten, dass sie ihre mail-addys ändern sollen
in erreichbare innerhalb xyz Stunden und nach Ablauf der Frist das Konto gesperrt/mindestens deaktiviert wird (=> klappt nicht, wedder die auto-Info, noch i-eine Aktion)
nun die Fragen:
- Ist das überhaupt mit dem MH umsetzbar?
- Wie genau muss die Konfig. dazu aussehen?
MfG
Den Multihunter interessiert es nicht, ob ein Benutzer gesperrt ist oder nicht.
das wollt ich wissen, danke
Das die automatischen Prüfungen ausgehebelt werden können sollte jedem Administrator bewusst sein.
ist es
Hallo,
vorweg: die Option "automatisch sperren" im MH ist nicht aktiv, wir sperren alles manuell, was wir gesperrt haben wollen.
Für die Sperrung ist keine Benachrichtigung vorgesehen. Diese wäre nämlich gleichbedeutend mit der Meldung, das ein Doppelaccount gefunden wurde.
Ist das so zu verstehen, dass für gesperrte Benutzer generell keine Prüfung erfolgt (bei neu-Reg nach Bann)?
Bei uns ist es mal so, mal so. Mal wird Alarm ausgelöst, wenn ein Gesperrter sich neu registriert, in der Mehrzahl aber nicht. Wobei die Neureg. in allen Fällen sehr zeitnah nach Bann erfolgen (z.B. um nachzufragen, warum gesperrt wurde)
Woran sich das orientiert weiss ich nicht.
Wünschenswert wäre natürlich eine Prüfung, damit man gleich sieht, dass es eine Neureg. nach Bann ist.
MfG
moin,
kannst du mich nochmal erleuchten?
was genau wird denn bei "IndexedDB Prüfung" geprüft?
und wie hoch ist die wahrscheinlichkeit, dass es sich tatsächlich um einen doppel-acc handelt, wenn nur diese prüfung "positiv" ist.
mfg
inwiefern ändert das dann aber etwas daran, dass weiter ausgelöst wird
Cookie Prüfung
Local Storage Prüfung
IndexedDB Prüfung
diese 3 prüfungen wo der 2. account lokalisiert wurde (Registrierungs Prüfung: leer / Super Cookie Prüfung: Es war kein Super Cookie vorhanden.)
dazu wurde, wie im startpost geschrieben, aber KEINE meldung ausgelöst, kein thema erstellt und auch kein user-querverweis in den beiden profilen erstellt
es handelt sich also um funde, die beim scrollen im negativ-log ZUFÄLLIG entdeckt wurden
Prüfung: IndexedDB Prüfung
wo ebenfalls der 2. account lokalisiert wurde (die anderen 4 prüfungen leer bzw "es war kein ... vorhanden")
und hier umgekehrt, meldung ausgelöst, thema erstellt, querverbindung in den profilen aber KEIN eintrag im negativ-log (hier mit bestätigung vom user, dass es definitiv kein fehlalarm war)
..................................
ich war der annahme, wenn ich von 5 möglichen prüfungen 3 nenne bzw. im 2. fall eine nenne, dass dann klar ist, dass diese prüfung dann auch einen entsprechenden eintrag (den jeweils anderen account) enthält
Wir halten es noch immer für eine Fehlfunktion, dass, wenn ein Doppelacc gelöscht wird, in Einzelfällen der verbliebene Acc. mit manipulierten Daten auslöst. Zumindest ist die Meldung total irreführend, da der keine Daten manipuliert.
Und nach Löschung des 2. Acc ist alles wieder im Lot und der sollte nicht weiter "nerven" weil er vor zig Monden mal einen nicht erwünschten 2. Acc hatte.
Wir können schlecht nach jedem gelöschten Doppelacc die Cookies umbenennen oder alles neu installieren. Zumal auch dieses Phänomen nicht regelmässig auftaucht bei einem verbliebenen Acc sondern nur in Einzelfällen und aus nicht verifizierbarem Grund.
Ich kann mit deiner Rückfrage nichts anfangen.
Welche Prüfungen jeweils erfolgt sind, steht sowohl bei dem Problem Startbeitrag (Einträge im Log OHNE Alarm) als auch beim Gegenpart aus Beitrag #4 (Alarm aber kein Log-Eintrag)
Beides tritt voneinander unabhängig und mit völlig anderen usern auf (falls es das ist, was du wissen willst)
Als Gegenstück dazu
gerade eben: Meldung ausgelöst, Thema wurde erstellt, Eintrag/Querverbindung in beiden Userprofilen
ABER kein Eintrag im Negativ-Log
Prüfung: IndexedDB Prüfung
vom User bestätigt, dass 2 Accounts am selben Endgerät waren, also definitiv kein Fehlalarm