[PHP/JS] Besucher wieder identifizieren **erledigt**

[strolch00]

Hi @all,

also ich möchte auf meiner Seite eine Abo-funktion einbauen, jetzt brauchte ich mal Meinungen von euch was ich nutzen kann um einen Besucher wieder zu identifizieren.

Also grob umschrieben dachte ich daran, daß wenn ein User etwas aboniert wird per JS ein Cookie gesetzt, und ein DB-eintrag gemacht. Jetzt ist es aber so das ein User auch seine Cookies löschen kann/muss. Wie kann ich dann vorgehen? Muss ich da wirklich eine komplette User DB heranziehen und mit pflegen oder kann ich das simpler gestalten?

Mein Problem ist nicht das, dass Cookie geklaut werden kann, weil mir des wurscht ist (stehen nur DB id´s drin von den Dingen die der User aboniert hat). Somit hatte ich eigentlich nicht vor ne große Anmeldeseite zu basteln inclusive großem Login, weil die abonierten Sachen direkt auf der Startseite angezeigt werden sollen. Die Ip fällt ja auch schonmal flach, aber da ich nicht der JS Profi bin dachte ich mir, vielleicht gibt es einen Befehl mit dem ich Rechnerspezifisch was machen kann.

Zur Not wenn hier niemand was weiß, dachte ich noch daran das die User beim abonieren gecheckt werden:
Ist der Cookie da wird kein zusätzliches PW erfragt, ist er nicht da wird ein zusätzliches PW erfragt. Aber dies birgt halt wieder das Risiko das ein User seine Cookies löschen kann/muss und setzt außerdem vorraus das der User beim abonieren immer den gleichen Usernamen nutzen muss.

Tjo das sind zur Zeit meine leiden, ich hoffe jemand hat nützliche Tipps.

 

[ZeroCCC]

entweder du machst nen login oder benutz nen cookie... was anders macht wenig sinn. auch wenn du ein rechner eindeutig identifizieren könntest... was passiert wenn der user nen anderen rechner nimmt?

 

[Astrodan]

Ich würde auch zu Cookie tendieren. Denn selbst bei nem Login muss er sich entweder jedes Mal neu einloggen, oder du brauchst auch Cookies.

entweder du machst nen login oder benutz nen cookie... was anders macht wenig sinn. auch wenn du ein rechner eindeutig identifizieren könntest... was passiert wenn der user nen anderen rechner nimmt?

Dann bringt auch das Cookie recht wenig

 

[strolch00]

Erstmal danke euch beiden, genau aus dem Grund tendiere ich auch zu Cookies und wollte e eigentlich von Anfang an so machen, aber wie man so als netter Webbie ist will man es seinen Usern leicht machen. Das heist, wenn ein User seinen Cookie nimmer hat, soll der mit möglichst nur einem Klick(so wenig Aufwand wie möglich) einen neuen Cookie bekommen mit seinen Abo´s. Also der User soll nicht jedes nochmal einzeln abonieren müssen. Darum geht es mir. Die Userdatenbank pflege ich jetzt sowieso nebenher, weil bei Neuigkeiten des Abo´s kann man Email Versand aktivieren. Also könnte ich den Cookie leicht per db gespeicherte Daten neu setzen wenn nötig. Doch wie sollte man die möglichst kleine Autentifizierung gestalten?
Muss es in dem Fall wirklich eine ID und PW und am besten noch SESSION with Salt sein, das denke ich net.
Doch was kann man heranziehen dazu?

@Zero des is mir auch wurscht ob der nen anderen Rechner nutz das ist für mich das gleiche wie das Thema gelöschter Cookie, weil er is ja weg und der User soll seinen mit möglichst wenig Aufwand seinen Cookie mit allen gespeicherten Abo´s wieder bekommen.

Wobei mir grad was auffällt beim schreiben:

Und zwar die Datenmenge die ein Cookie aufnehmen kann ist ja sicher begrenzt. Das heist ich setz einfach nur nen Cookie mit der ID und dem Namen und gut is. Mit dessen Hilfe kann ich auch seine Abo´s auf der Startseite anzeigen lassen, und wenn der Cookie weg ist kommt ein normales Login. Was haltet Ihr von der Idee?? Soll ich andere Werte im Cookie speichern welche es mir evtl. leichter machen bei meinem Vorhaben(kann ja sein was ich in der Eile nicht bedenke).

Danke schonmal, freue mich schon auf Meinungen

 

[Astrodan]

Und zwar die Datenmenge die ein Cookie aufnehmen kann ist ja sicher begrenzt. Das heist ich setz einfach nur nen Cookie mit der ID und dem Namen und gut is. Mit dessen Hilfe kann ich auch seine Abo´s auf der Startseite anzeigen lassen, und wenn der Cookie weg ist kommt ein normales Login. Was haltet Ihr von der Idee??

Gut.
Wobei ich es nicht Login nennen würde, vielmehr eine kleine Eingabe Passwort / Name, oder eventl. nur nen unique Code, wobei das Cookie gesetzt wird.


Und weitere Daten - kA, je nachdem, was du den Usern bieten willst. Letzter Besuch. Datum des 'Logins'. Alles nicht wirklich viel Speicher.
Ich hab zwar keine Ahnung ob und wie weit Cookies speicherbegrenzt sind, aber da passen locker wesentlich mehr Infos rein, als das bisschen.

 

[chrissel]

Du kannst ja am besten alle Informationen als Array speichern und per serialize() dann in dem Cookie speichern.
Mit unserialize() wieder auslesen und die Daten sind aus einem Cookie wieder schön geordnet da
Nur so ein kl. Tipp am Rande

 

[strolch00]

@Astrodan
Jop genau es ist ja kein richtiges Login, aber genauso dachte ich es mir user gibt einmal Daten ein ==> Anlegen des Datensatzes in der DB bzw. update dessen und cookie anlegen.
danach kann der User abonieren was er will, wobei diese Daten auch in einer Tabelle gespeichert werden.
Aber mir sticht das pw Feld ins Auge, das mag ich irgendwie vermeiden, weil ich ja nicht so großen Wert auf die Sicherheit in dem Fall lege, will ich vermeiden ein PW abzufragen welches die User unter Umständen noch bei pp haben oder sowas. Jetzt stehen folgende Fragen im Raum:
1. soll ich es trotzdem sicher machen, und ein PW Feld nehmen, weil ja ebenso die Email in der DB steht für die Emailbenachrichtigung.
2. Oder nehme ich sowas in der Art "geheime Frage" wobei sehr viele user dort wo Sie geboren wurden nehmen und dieses Merkmal findet man eigentlich immer irgendwie raus.

@cp1992

Ein serialisieren eines Array´s kann ich mir in dem Fall sparen, weil ich trotzdem um die DB nicht drumrum komme, wenn ich es den Usern so einfach wie möglich machen will nach einem (versehentlichen) löschen der Cookies die Abo´s wieder zu bekommen.
Also kann ich gleich alles per DB verwalten, oder hast du noch mehr Vorteile der Serialisierung?

 

[ZeroCCC]

machs doch so und lass den user entscheiden... einmal nen gast zugang der die daten im cookie ablegt und für die die mehr wollen machste das ganze mit login. problem gelöst

 

[strolch00]

Das wäre natürlich perfekt.
Aber wie schauts hiermit aus?
1. soll ich es trotzdem sicher machen, und ein PW Feld nehmen, weil ja ebenso die Email in der DB steht für die Emailbenachrichtigung.
2. Oder nehme ich sowas in der Art "geheime Frage" wobei sehr viele user dort wo Sie geboren wurden nehmen und dieses Merkmal findet man eigentlich immer irgendwie raus.

Zuwas tendiert Ihr?

 

[Astrodan]

Kurz zitiert:

Zuwas tendiert Ihr?

1. soll ich es trotzdem sicher machen, und ein PW Feld nehmen, weil ja ebenso die Email in der DB steht für die Emailbenachrichtigung.

(komische drei Zeichen Begrenzung)

 

[strolch00]

Also Astrodan vertshe ich das richtig, Du würdest zu einer trotzdem sicheren Datenbank tendieren?

 

[Astrodan]

Also Astrodan vertshe ich das richtig, Du würdest zu einer trotzdem sicheren Datenbank tendieren?

Ich fände eine geheime Frage relativ nervig, denn ob ich nun ein Passwort eingebe oder eine Frage beantworte macht für mich als User keinen Unterschied. Bzw. würde ich das sogar so sehen, dass ich mir ein Passwort nicht merken muss, da die Browser das ja speichern können (was bei etwas so unwichtigem auch kein Sicherheitsproblem sein sollte), während die Antwort auf eine Frage ja immer wieder eingetippt werden muss.

Und da du die DB eh brauchst, um zu speichern, was die Antwort auf die Frage ist, isses ja schließlich egal.

Wenn du Angst hast, das jemand dort ein vertrauliches Passwort benutzt (von wo anders), dann schicke deinen Usern doch einfach nur generierte PWs zu.

 

[strolch00]

Das mit den generierten PW´s habe ich mir auch schon überlegt allerding wie soll ich checken ob der User sich dann einloggen oder registrieren will? Das ganze ist ein wenig kompliziert zu erklären, aber ich ich danke schonmal für die ganzen Anregungen und hoffe mal noch die optimale Lösung zu finden.