Theoretische Fragen: Usermanagement, Rechtevergabe, Login

**Abraxax** · 07.12.2005, 20:37

warum suchen die leute nicht einfach mal?

http://www.php-resource.de/forum/sho...threadid=61751

**firstlord18** · 07.12.2005, 20:48

toll, aus deinem "selbklärenden" DUmp werde ich auch nicht wirklich schlau. Warum nicht einfach mal gescheit die Antwort posten?

Danke!

**ghostgambler** · 07.12.2005, 21:34

Re: Theoretische Fragen: Usermanagement, Rechtevergabe, Login

Original geschrieben von firstlord18

Code:

table: rights

id   |   path

1        action=edit_news
2        action=create_user
3        datei.php?get=value
4        ?post=now
5        &get2=value2

find ich spontan doof...du kannst ja eine Website nicht verschieben ohne die Tabelle upzudaten

Code:

table: users

id    |    username     |     password    |     rights

1             test1                 pass1             1;5
2             david                php4life           2;3;5
3             nolimit               secret            1;2;3;4;5
4             rightless            mypwd

wäre das so sinnvoll?

nein, die Spalte rights widerspricht schon der ersten Normalform (Normalisierung einer Datenbank)

Die erste Normalform erlaubt nur atomare Attribute in den Relationenschemata, d.h. als Attributwerte sind Elemente von Standard-Datentypen wie integer oder string erlaubt, aber keine Konstruktoren wie array oder set

(Zu array und set zählt auch deine Konstruktion...)

Code:

table: usergroups

id    |    groupname     |        rights

1             test1                     1;5
2             david                    2;3;5
3             nolimit                 1;2;3;4;5
4             rightless

gleiches Problem wie oben

Nur wie kann ich dann das mit der Usertabelle verknüpfen. Also ich mein, dass sich die normalen Rechte nicht mit den Rechten der Usergruppe in die Quere kommen?
Und dass man da auch noch den Überblick bewahrt ...

ich hatte es bei mir so gemacht, dass ich einzelne Rechte verteilen kann, oder eben eine Gruppe. Und eine Gruppe vereint nur mehrere Rechte unter einem Namen... (bei mir alles noch etwas komplexer, weil die Gruppen gleich noch bestimmte Bereiche von einem Artikel-System "belegen", aber vereinfacht kann man es wie ich vor der Klammer geschrieben hatte beschreiben)

So. und nun zum Einloggen, macht man das so:

- loginformular -> korrekter user+pass -> cookie setzten und in der session die daten wie password, username, und die rechte speichern

- wenn der User wiederkehrt, dann einfach nur schauen, ob ein Cookie existiert. Falls ja, dann schauen, ob die Daten mit den Daten aus der DB übereinstimmen. Falls ja, dessen Rechte laden und eben wieder in die Session speichern ...

- beim logout einfach session & cookies löschen

Wäre das so ok, oder lößt man sowas lieber anders?

wenn du mit Cookie den Session-Cookie meinst ist das schon gut so ... du weißt aber schon, dass man einen User anhand einer ID identifiziert und nicht an einem usernamen?
Spart Platz und man kann einen User im Nachhinein umbenennen, weil der Username einfach nur als nettes Anhängsel bei der Ausgabe benutzt wird und nicht in x Tabellen zur Zugehörigkeitsfindung eines Datensatzes benutzt wird...

**firstlord18** · 07.12.2005, 21:45

Re: Re: Theoretische Fragen: Usermanagement, Rechtevergabe, Login

danke für deinen dicken post.

das m,it den tabellen muss ich mir nochmal anschauen und anders machen

Original geschrieben von ghostgambler

wenn du mit Cookie den Session-Cookie meinst ist das schon gut so ... du weißt aber schon, dass man einen User anhand einer ID identifiziert und nicht an einem usernamen?
Spart Platz und man kann einen User im Nachhinein umbenennen, weil der Username einfach nur als nettes Anhängsel bei der Ausgabe benutzt wird und nicht in x Tabellen zur Zugehörigkeitsfindung eines Datensatzes benutzt wird...

nein, ich habe nicht das session cookie sondern ein cookie gemeint, das ich setzte, und in das ich die id und das pw speicher.

wenn er dann auf die seite zurückkommt und keine session gesetzt ist, dann wird halt in der db nach der id geschaut, und mit dem pw aus dem cookie vergleichen.

falls das übereinstimmt, wird halt eine session eröffnet ...

Naja, und wenn ne session erstmal besteht, muss ich dann nicht mehr nach werten aus der db schauen? also kann der user die session nicht irgendwie manipulieren, sodass er als eingeloggt gilt ...?
oder muss ich auch bei jedem seitenaufruf die session-daten mit den daten aus der db vergleichen?

un nun nochmal die frage: wie soll ich dann die rechte so aufbauen, dass ich sie für jedes andere script nutzten kann?
was ist an meiner variante schlecht? ich find die irgendwie gut. weil ich denke nicht, dass sich die links auf die einzelnen sachen ändern innerhalb eines scripts. also angenommen ich habe ein gb, und möchte ein admin menu dazu.
dann würde ich halt die urls bei den rechten eintragen, wie z.b. ?action=del_gb_entries. Ich denke nicht, dass sich die seite, um die gb einträge zu löschen ändern würde, oder?

was gibt es als bessere methode?

danke!

**ghostgambler** · 07.12.2005, 21:57

Re: Re: Re: Theoretische Fragen: Usermanagement, Rechtevergabe, Login

Original geschrieben von firstlord18
nein, ich habe nicht das session cookie sondern ein cookie gemeint, das ich setzte, und in das ich die id und das pw speicher.

ich zitiere hier sinngemäß mal mrHappiness (glaube ich zumindest das er das war...)
Auf dem Client sollte nur eine zufallsgenerierte id gespeichert werden, anhand welcher man auf dem Server aus der Datenbank die zugehörigen Daten auslesen kann.

Hab ich bei meiner letzten Login-Programmierung mal gemacht (kommt ja nicht so häufig vor, dass man ein Login programmiert

) und es funktioniert wunderbar (just btw. es ist ein 500 Zeilen-Login (und ich habe meinen Stil gekürzt ... falls sich noch wer an meinen alten Stil erinnert?), wenn ich also sage, dass das eine gute Lösung ist, dann IST das eine gute Lösung ^^)

wenn er dann auf die seite zurückkommt und keine session gesetzt ist, dann wird halt in der db nach der id geschaut, und mit dem pw aus dem cookie vergleichen.

ne~
Session starten, session-id wird als Cookie gesetzt. Wenn die Session beendet wird (weil das File oder der DB-Eintrag vom GC gelöscht wird), dann SOLL der User ausgeloggt werden.
Das was du haben willst ist ein Auto-Login-Cookie (der auch nach oben beschriebener Methode mit der ID gemacht wird)

Naja, und wenn ne session erstmal besteht, muss ich dann nicht mehr nach werten aus der db schauen? also kann der user die session nicht irgendwie manipulieren, sodass er als eingeloggt gilt ...?

nein

oder muss ich auch bei jedem seitenaufruf die session-daten mit den daten aus der db vergleichen?

kannst du, musst du aber nicht. Nur wenn du dann Rechte (oder anderes) änderst, muss sich der User erst erneut einloggen bevor die Änderung greift!

un nun nochmal die frage: wie soll ich dann die rechte so aufbauen, dass ich sie für jedes andere script nutzten kann?
was ist an meiner variante schlecht? ich find die irgendwie gut. weil ich denke nicht, dass sich die links auf die einzelnen sachen ändern innerhalb eines scripts. also angenommen ich habe ein gb, und möchte ein admin menu dazu.
dann würde ich halt die urls bei den rechten eintragen, wie z.b. ?action=del_gb_entries. Ich denke nicht, dass sich die seite, um die gb einträge zu löschen ändern würde, oder?

was gibt es als bessere methode?[/B]

PHP-Code:


$adminseite = 'gb';

require('login.php');

login($adminseite);

und in der Login-Funktion wird dann halt nach 'gb' in der Datenbank geguckt und ob der User entsprechende Rechte hat.
Hat auch den Vorteil, dass du 2 Skripte mit exakt den selben Rechten benutzen kannst, ohne 2 URLs in die Datenbank einzutragen
(nur mal als ganz grobes Beispiel...)

**firstlord18** · 07.12.2005, 22:12

aber was genau bringt es, eine generierte id zu speichern? ich meine, die user id tut es doch auch oder?

also brauche ich ein session cookie (wird ja eh gesetzte) und zusätzlich dieses auto-login-cookie (versehen mit einer random id), welches den user identifiziert ...

soll sich dieser generierte wert ändern, oder wird dieser nur einmal beim login generiert und in der db festgehalten. falls das cookie dann halt 100tage gültig ist, soll dann die id dazwischen nicht geändert werden?

**matz0r** · 07.12.2005, 22:39

Original geschrieben von firstlord18
ich meine, die user id tut es doch auch oder?
[/B]

Und was ist wenn ich (User ohne Rechte mit der id xy) meine ID im Cookie auf deine ID ändere?

Hoffe du weisst was ich sagen will.... (und die anderen ja eigentlich schon gesagt haben).

**firstlord18** · 07.12.2005, 22:45

Original geschrieben von matz0r
Und was ist wenn ich (User ohne Rechte mit der id xy) meine ID im Cookie auf deine ID ändere?

Hoffe du weisst was ich sagen will.... (und die anderen ja eigentlich schon gesagt haben).

ja wie gesagt, ich speichere die id+ das passwort, und bei einer wiederkehr auf die seite, wird natürlich der user aus der datenmbank genommen, dem die id entspricht, un mit dem passwort im cookie vergleichn. bringt also nix, das so zu ädnern

**ghostgambler** · 08.12.2005, 14:56

Original geschrieben von firstlord18
ja wie gesagt, ich speichere die id+ das passwort, und bei einer wiederkehr auf die seite, wird natürlich der user aus der datenmbank genommen, dem die id entspricht, un mit dem passwort im cookie vergleichn. bringt also nix, das so zu ädnern

das Passwort sollte aber nicht im Cookie auftauchen, denn dann kann man auch einfach sich den Cookies an einem fremden Rechner anschauen und da das Passwort auslesen...

**firstlord18** · 08.12.2005, 15:28

Original geschrieben von ghostgambler
das Passwort sollte aber nicht im Cookie auftauchen, denn dann kann man auch einfach sich den Cookies an einem fremden Rechner anschauen und da das Passwort auslesen...

achso, jetzt leuchtet mir der sinn der random id ein :>
naja, aber muss die dann nicht jedes mal neu generitert werden, oder wie ist das?

sonst könnte ich doch auch einfach hingehen und diese random-id von einem cookie meines kumpels auslesen und bei mir eintragen ... so wär ich auch wieder eingeloggt ...

irgendwie verstehe ich das nicht so richtig. bitte nochmal genau erklären. danke (achso, also ich meine nun immer das auto-logincookie und nicht das sessioncookie)

**ghostgambler** · 08.12.2005, 15:46

Original geschrieben von firstlord18
achso, jetzt leuchtet mir der sinn der random id ein :>
naja, aber muss die dann nicht jedes mal neu generitert werden, oder wie ist das?

sonst könnte ich doch auch einfach hingehen und diese random-id von einem cookie meines kumpels auslesen und bei mir eintragen ... so wär ich auch wieder eingeloggt ...

irgendwie verstehe ich das nicht so richtig. bitte nochmal genau erklären. danke (achso, also ich meine nun immer das auto-logincookie und nicht das sessioncookie)

zumindest kennst du dann aber sein Passwort nicht...über Einzelheiten zu der Thematik darfst du dir selbst Gedanken machen

**firstlord18** · 08.12.2005, 16:05

Original geschrieben von ghostgambler
zumindest kennst du dann aber sein Passwort nicht...über Einzelheiten zu der Thematik darfst du dir selbst Gedanken machen

hm, stimmt auch wieder

Naja, warum alleine Gedanken machen? Kann man doch super in solch einem Thread diskutieren.

Also ich sähe folgende Möglichkeiten:
- Die Random ID bei jedem Seitenaufruf in Cookie und DB ändern, das wären dann eben viele Queries ...

Naja wobei, wenn ich mir das recht überlege, bringt eigentlich auch nichts.
Da wenn der User dann ne Random Id in seinem Cookie hat, und ich es klaue, kann ich mich damit ja wiederum einloggen, nur bekomme ich dann eben wieder verschiedene RandomId's zugewießen ... aber trotzdem bleibe ich eingeloggt (also als RandomId-Dieb) und das System merkt ja nicht, wem es die RandomID's vergibt ...

Was wären denn dann sichere Möglichkeiten? Wahrscheinlich kann man solche Auto-Login-Cookies garnicht gegen Diebstahl sichern, oder?
Man könnte zwar dem User sein Browser oder sowas speichern, aber trotzdem weiß man ja nicht, ob er später sein Browser gewechselt hat :-P

Naja, darum nutzten Online Banking und Kundenbereiche auch keine AutoLoginCookies ...

**ghostgambler** · 08.12.2005, 16:14

meine Idee wäre jetzt spontan, dass bei jedem Login (NICHT Seitenaufruf) die Auto-Login-ID geändert wird und ggf. alte IDs, die nicht mehr für den momentanen Rechner erreichbar sind (weil das Cookie nicht vorhanden, oder eine andere ID hat) aus der DB gelöscht werden, sodass man sich damit nicht mehr einloggen kann

**firstlord18** · 08.12.2005, 16:21

Ja aber wie macht man das dann bitte mit deine AutoLoginCookie?
Diesen Wert kann man nicht aus der DB speichern, und mit diesem Wert (egal was im Cookie gespeichert ist, ob die Userid, das Password, die RandomID, oder Kombinationen aus mehreren Dingen) kann ein CookieDieb sich einloggen ...

Da kann man wohl nichts dagegen tun, außer halt die AutoLoginCookies nicht zu benutzten, sondern es so zu machen, dass man sich bei jedem Besuch halt neu einloggen muss!

Theoretische Fragen: Usermanagement, Rechtevergabe, Login