Woher weiß der Powerlink meine Klamm ID?

Warum auch nicht? Wo man halt Kekse akzeptiert hat man damit zu leben das sie ausgelesen werden, da stimmt der Satz: "Die Nebenwirkungen von Keksen gehen weit über das normale Übergewicht hinaus :mrgreen:" (deshalb habe ich auch nur bei ganz wenigen Seiten Kekse akzeptiert, sonst nicht..)
Kekse können nur von der Seite ausgelesen werden, die sie auch erstellt hat.

Deine KlammID ist ja keine PIN oder donstiges vertrauliches womit man Dir schaden könnte, das ist ein eindeutiges Identifizierungsmerkmal genau wie Dein Username. Meine Kampagne braucht die ID nur zu dem ZWeck das ich Dir nach einer erfolgreichen Teilnahme die Bonuslose schicken kann :)
Da die KlammID ein eindeutiges Identifizierungsmerkmal ist, gehört diese aber auch zu den privaten Daten und darf von Klamm nicht ohne Erlaubnis an fremde Seiten übergeben werden: Verstoß gegen die Privacy-Regeln
 
Hmm, zu kompliziert aus Usersicht denke ich.

Eine 1:1-Verknüpfung aus Pseudo-ID und tatsächlicher Klamm-ID wäre meines erachtens besser, beispielsweise A55432 weist auf meine Klamm-ID.

Der Buchende kann an A55432 Lose überweisen, kennt aber meine tatsächliche ID nicht. Somit wäre die Identifizierung des Klamm-Profils ausgehebelt.

Besser als eine Box ([x] Klicken Sie hier, um die Identifizierung ihres Profils zu ermöglichen (und Ihnen Lose zu senden)).

Da würden wieder massig Threads enstehen...

Kekse können nur von der Seite ausgelesen werden, die sie auch erstellt hat.[...]

So nicht ganz richtig, zugreifen darf nur folgende Server, die sich innerhalb der ausstellenden Domain befinden.

Heisst:
  • Wenn Server hugo.test.de ein Cookie ausstellt für hugo.test.de dann darf auch nur hugo darauf zugreifen.
  • Wenn Server hugo.test.de ein Cookie auf *.test.de austellt, dann darf auch lisa.test.de oder malware.test.de darauf zugreifen.

Gruß,

jiw
 
Zuletzt bearbeitet:
So nicht ganz richtig, zugreifen darf nur folgende Server, die sich innerhalb der ausstellenden Domain befinden.
dem bin ich mir natürlich bewusst, ich wollte es jedoch einfacher ausdrücken, damit es auch jeder versteht ;)
Das hugo.test.de zu test.de gehören muss und deshalb es sich um die gleiche Seite handelt (mal komische Free-Hoster außen vorgelassen) habe ich in der aussage einfach mal impliziert.
 
Das Problem dabei ist aber, dass kein User den Nicknamen A55432 haben darf. Vielleicht die KID einfach verschlüsseln? :think:

Warum sollte ein User nicht den Namen A55432 haben sollen, Username und Klamm-ID sind ja auch getrennt. und zwo Spalten.

Bei einer EF-Abfrage gibt es ja sicherlich auch zwo Variablen ob nun Buche auf "<Benutzername>" oder "<Klamm-ID>" oder?
und anhand des Axxxxx wäre für Script ersichtlich... "Aha pseudo ID, überweise Lose intern an die passende KlammID" ... mal salopp formuliert.

Gruß,

jiw
 
Warum sollte ein User nicht den Namen A55432 haben sollen, Username und Klamm-ID sind ja auch getrennt. und zwo Spalten.

Die sind zwar getrennt, aber das Script geht davon aus, dass A55432 ein Nickname ist, da es keine KID sein kann wegen dem "A".

Bei einer EF-Abfrage gibt es ja sicherlich auch zwo Variablen ob nun Buche auf "<Benutzername>" oder "<Klamm-ID>" oder?

Soweit ich weiß geht der Transfer von EF zu User nur über die KID.

und anhand des Axxxxx wäre für Script ersichtlich... "Aha pseudo ID, überweise Lose intern an die passende KlammID"

Was ist aber wenn ich den Nicknamen A55432 habe? Der würde dann ja auch als Pseudo erkannt werden und die Lose bei dem User mit der Pseudo-KID A55432 landen. Anders wäre es, wenn der Pseudo länger als 25 Zeichen wäre. Dann kann es weder Nickname noch KID sein.
 
Die sind zwar getrennt, aber das Script geht davon aus, dass A55432 ein Nickname ist, da es keine KID sein kann wegen dem "A".

Ganz ehrlich? Wenn ein Skript nur ein Parameter als Eingabe zuläßt,
aber anderseits den übergebenen Wert unterscheidet nach Username oder ID
dann passt man es vernünftig an, muiss man so oder so,
oder ändert die Parameter-Übergabe gleich vernünftig var KID, var KNName
und KID kann entweder die Klamm-ID oder die PseudoID enthalten.

Die interne Unterscheidung des KID-Wertes macht intern Lukas.
Wenn KID = A#### dan pseudoID sonst KlammID


Soweit ich weiß geht der Transfer von EF zu User nur über die KID.

Was spricht dagegen als Wert auch eine PseudoID zuzulassen?
s.o.
und warum führst Du dann hier eine Diskussion über den Nicknamen, wenn sowieso nur die ID erlaubt ist?
Was ist aber wenn ich den Nicknamen A55432 habe? Der würde dann ja auch als Pseudo erkannt werden und die Lose bei dem User mit der Pseudo-KID A55432 landen. Anders wäre es, wenn der Pseudo länger als 25 Zeichen wäre. Dann kann es weder Nickname noch KID sein.

Ist hier nicht relevant, da bei den Actionlinks nur die KlammID übergeben wird, ein Austausch gegen eine PseudoID also einfach.
zwotens das Script nach deiner Aussage sowieso nur die ID zulässt,
welche auchnur übergeben wird? Woher soll alsoder Werbende den Namen bekommen? Des weiteren ist deine KID auch mit dem Nutzernamen A55432 unterschiedlich, da nur numerisch.
Eine Spalte PID zur Usertabelle mit PseudoIDs befüllt hinzuzufügen auch kein Akt.

Also wo siehst DU das Problem?
Und wer Scripte einsetzt die das von Dir beschriebene Verhalten zeigen, sollten dann gefälligst angepasst werden... schliesslich will der Werber ja die ID haben und damit was machen.. dann sollte es auch kein Aufwand sein das Skript anzupassen.
 
Zuletzt bearbeitet von einem Moderator:
Wenn KID = A#### dan pseudoID sonst KlammID

Angenommen ein User bekommt die Pseudo-ID A12345. Ein weiterer registriert sich mit dem Nicknamen A12345. Der Sponsor transferiert nun Lose an A12345. Wer bekommt die dann? Der mit der Pseudo-ID oder der mit dem gleichnamigen Nicknamen? ;)

Was spricht dagegen als Wert auch eine PseudoID zuzulassen?
s.o.
und warum führst Du dann hier eine Diskussion über den Nicknamen, wenn sowieso nur die ID erlaubt ist?

Beim EF ja. Da wäre es möglich mit einer weiteren Variable. Der Sponsor kann die Lose aber auch über seinen klamm Account transferieren. Da gibt es keine verschiedenen Variablen. Da gibts nur $empfaenger und der ist entweder Nickname oder KID. Vergleichbar mit KID/EFID. Da erkennt das Script auch keinen Unterschied ohne das der User per Radiobutton wählt.

Könnte man bei Pseudo/KID,NICK zwar auch machen. Ist aber bei weitem nicht so komfortabel :p
 
Also der Hintergrund ist, dass man bei Actionlinks ja was für Leads bekommt (als Sponsor). Um in solchen Fällen wie "ich hab mich angemeldet aber die Antwort war falsch obwohl sie richtig war" nachvollziehen zu können, ob der User tatsächlich teilgenommen hat, war die Idee halt, die klamm-ID durchzuschleifen. Dann sieht man "aha, der User hat wirklich teilgenommen" und kann ihm ggf. was geben. Anders sieht man nur "512 Teilnahmen". Fertig.

Die klamm-ID ist öffentlich.
Und jeder der die hat, kann das öffentliche klamm-Profil einsehen.
Privacy-Regeln werden ja alle berücksichtigt.

D.h. ein Sponsor der das Ganze "liest", kann maximal wissen "aha, klammID 12345 war auf meiner Seite" - und könnte das öffentliche Profil ansehen. Wobei er ja gar nicht weiß, dass die "subID" die da mitkommt eine "klammID" ist. Das interessiert Affili.net usw. auch gar nicht.

Edit:
Eine schnelle Lösung wäre, wenn ich jeder Kampagne einen Schlüssel gebe, mit der der Buchende die klamm-ID entschlüsseln kann. Das Netzwerk/der Werbepartner bekommt dann nur die verschlüsselte klamm-ID übertragen. Hier auf klamm kann sie dann aber trotzdem vom Buchenden verarbeitet werden, wenn auch mit viel mehr Aufwand.

Alternative2:
Ein Hinweis beim Powerlink-Klicken, dass die klamm-ID übertragen wird, um eventuelle Boni vom Sponsor zu bekommen. Dann kann man OK klicken oder halt abbrechen.

Edit3:
Man sieht beim Drüberfahren ja die klamm-ID im Tooltip, oder?
Also man sieht dann [[k_id]] ...
 
Die klamm-ID ist öffentlich.
Und jeder der die hat, kann das öffentliche klamm-Profil einsehen.
Privacy-Regeln werden ja alle berücksichtigt.

Die KlammID ist öffentlich richtig, aber wenn du diese Information an andere Dienste weitergibst, ermöglichst du die eindeutige Identifizierung eines Nutzer:
Das Telemediengesetz in Deutschland lässt nach § 12 Abs. 1 TMG eine Verarbeitung von personenbezogenen Daten nur zu, wenn der Benutzer vorher zugestimmt hat oder eine gesetzliche Ermächtigung vorliegt.

https://secure.wikimedia.org/wikipedia/de/wiki/Google_Analytics
Und genau das ist ja auch der Grund warum für Google Analytics eine Datenschutzerklärung formuliert werden muss, nämlich weil der Nutzer eindeutig anhand eines Merkmals (IP) identifiziert werden kann. Bei dir ist es das Gleiche, nur dass die IP nun die KlammID ist, an der KlammID kann ich einen Nutzer auch eindeutig identifizieren, denn 2 Benutzer mit der gleichen KlammID gibt es nicht.
 
Naja, bei IP hast Du eine Zuordnung zu Person/Telefonanschlussinhaber. Bei klamm-ID hast Du erstmal nur eine Zuordnung zur klamm-Nickpage. Ob diese wiederum auf eine Realperson schließen lässt, hat jeder mit seinen Privacy-Einstellungen selbst in der Hand.

Ich kanns auch abstellen.
Dann sind aber weder Nachvergütungen noch Boni möglich.

Edit: done!