nicht angemeldet
PHP MySql Passwortschutz
Hallo!
Ich habe folgendes Problem:
Ich würde gerne eine Login-Bereich auf meiner Website realisieren. Dieser soll so funktionieren, dass man sich mit Benutzername und Passwort anmelden kann. Das etwas aufwendige an der ganzen Gecshichte ist, dass mit mit verschiedenen Zugrifssdaten auf verschiedene Seiten kommt.
d.h.:
Seite1.html für benutzer a
seite2.html für benutzer b
...
Ich habe das halbe Netz abgesucht und leider von mysql bzw. php nicht viel Ahnung. Mit Hilfe von einem Tutorial bekomm ich das aber schon hin. Leider hab ich bislang nix in der Richtung gefunden. Kann mir jemand helfen?
Danke und grüße,
Tom
-
Hi,
Ich würde gerne eine Login-Bereich auf meiner Website realisieren. Dieser soll so funktionieren, dass man sich mit Benutzername und Passwort anmelden kann. Das etwas aufwendige an der ganzen Gecshichte ist, dass mit mit verschiedenen Zugrifssdaten auf verschiedene Seiten kommt.
Und wo ist das Problem, einfach den Namen dieser Seite zusammen mit den Zugangsdaten in der Datenbank abzulegen und auch wieder auszulesen?
(Wenn du wirklich nur einzelne „Seiten“ meinst. Wenn es dir eher um Inhalte als um Seiten im Sinne von einzelnen HTML-Dokumenten geht, dann willst du wohl eher eine Rechteverwaltung implementieren.)
MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right? -
hi,
Ich würde gerne eine Login-Bereich auf meiner Website realisieren. Dieser soll so funktionieren, dass man sich mit Benutzername und Passwort anmelden kann. Das etwas aufwendige an der ganzen Gecshichte ist, dass mit mit verschiedenen Zugrifssdaten auf verschiedene Seiten kommt.
Ja, es ist ein bischen Aufwand, aber machbar mit Benutzergruppen (1) und OOP (2).
- Jeder, der sich anmeldet, ist einer bestimmten Gruppe zugeordnet
- Jede Seite wird als Objekt betrachtet und bekommt ein zusätzliches Attribut 'gruppe'.
Beim Request auf eine Seite wird dann geprüft, ob überhaupt ein Login vorliegt und wenn ja, ob die Gruppenzugehörigkeiten übereinstimmen.
Hotti
-
Hi,
Ja, es ist ein bischen Aufwand, aber machbar mit Benutzergruppen (1) und OOP (2).
Und ohne OOP genauso.
Ernsthaft, hotti - du machst dich lächerlich mit deinen ständigen Versuchen, Bullshit-Bingo zu spielen, wenn du nur ein einziges Buzzword kennst.
- Jede Seite wird als Objekt betrachtet und bekommt ein zusätzliches Attribut 'gruppe'.
Dazu muss sie kein Objekt sein, auch bspw. ein Datensatz kann ein solches zusätzliches Attribut bekommen.
MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?-
hi,
Und ohne OOP genauso.
Ernsthaft, hotti - du machst dich lächerlich mit deinen ständigen Versuchen, Bullshit-Bingo zu spielen, wenn du nur ein einziges Buzzword kennst.
Also, was nun, Spiel oder Ernst? Welches Buzzwort?
- Jede Seite wird als Objekt betrachtet und bekommt ein zusätzliches Attribut 'gruppe'.
Dazu muss sie kein Objekt sein, auch bspw. ein Datensatz kann ein solches zusätzliches Attribut bekommen.
Welcher Datensatz?
Viele Grüße,
Hotti-
Hi,
Welches Buzzwort?
Das einzige, das du kennst - „OOP“.
(Wobei kennen hier nur in der Bedeutung „dem Namen nach“ verwendet ist.)Welcher Datensatz?
Welches Objekt?
MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?-
hi,
Das einzige, das du kennst - „OOP“.
(Wobei kennen hier nur in der Bedeutung „dem Namen nach“ verwendet ist.)Z.Z. entwickle ich in einem etwas größeren Projekt, objektorientiert mit Perl. Es beeinhaltet u.a. einen Loginprozess, eine Benutzerverwaltung und ein Berechtigungssystem für jede angeforderte Seite. Das ist so ziemlich genau das, was hier in diesem Thread als Aufgabe steht.
So um 2001 (kann auch länger her sein) habe ich ein ähnliches Projekt verwirklicht, auch in Perl jedoch nicht objektorientiert. Der Code war schwer überschaubar und sehr pflegebedürftig... kurzum, das was Du als 'Buzzword' bezeichnest, ist für mich eine Erfahrung aus der heraus ich eine Empfehlung ableite.
Sicher kannst Du die Aufgabe (siehe ganz oben) auch anders angehen, bedenke jedoch, dass nicht nur Programmierer Fehler machen, sondern auch die Anwender und die Suche in einem 2000-Zeiler-Script ist zeitaufwändiger als die Suche in einem Modul. Gerade zum Thema, Session, Login, Benutzerverwaltung usw. gibt es auf CPAN erstklassige Module mit klar definierten Schnittstellen, deren produktive Vorzüge demjenigen entgehen, der sie nicht zweckentsprechend einsetzen kann oder gar nicht erst verwendet.
Und gerne sag ichs nochmal: Gehe das Thema objektorientiert an, Du sparst Dir eine Menge Arbeit und Zeit.
Viele Grüße,
Hotti-
Hi,
Z.Z. entwickle ich in einem etwas größeren Projekt, [...]
Blah blah blah ... who gives a f***?
Von deiner ganzen Selbstbeweihräucherung halte ich in etwa so viel, wie bspw. Alexander auch.
kurzum, das was Du als 'Buzzword' bezeichnest, ist für mich eine Erfahrung aus der heraus ich eine Empfehlung ableite.
Ich bezeichne nicht OOP als Buzzword - sondern deine Verwendung des Begriffs.
Sicher kannst Du die Aufgabe (siehe ganz oben) auch anders angehen, bedenke jedoch, dass nicht nur Programmierer Fehler machen, sondern auch die Anwender und die Suche in einem 2000-Zeiler-Script ist zeitaufwändiger als die Suche in einem Modul.
Anwenderfehler muss nicht der Anwender im Code suchen.
Gerade zum Thema, Session, Login, Benutzerverwaltung usw. gibt es auf CPAN erstklassige Module mit klar definierten Schnittstellen, deren produktive Vorzüge demjenigen entgehen, der sie nicht zweckentsprechend einsetzen kann oder gar nicht erst verwendet.
Oder dem, der gar kein Perl verwendet, sondern hier nach PHP gefragt hat, was dir aber wieder mal entgangen ist.
Und gerne sag ichs nochmal: Gehe das Thema objektorientiert an, Du sparst Dir eine Menge Arbeit und Zeit.
Das ist ein absoluter Allgemeinplatz.
Und einem Anfänger, der mit OO noch überhaupt keine Berührung hatte, hilft der momentan vermutlich kaum weiter.MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?-
Hi,
also ich lese hottis Postings sehr gerne. Meistens nach Feierabend mit einem Bier in der Hand. Genauso wie ich gerne (wegen demselben Grund) z.B. bash.org lese.
Die Postings könnten mystischer nicht sein. Ich bewundere auch den langen Atem von Alexander, dedlfix, et al, die ihn immer wieder korrigieren.
Denn das ist zu oft einfach bitter nötig.Wie zum Beispiel im folgenden Thread: https://forum.selfhtml.org/?t=204529&m=1385233.
Die Korrekteure waren es müde noch ein Weiteres mal zu berichtigen (weil es auch dermaßen abstrus ist). Problematisch wird dies dann, wenn es im unkommentiert im Archiv landet.
Und das dann jemand liest. Jemand, der keine Ahnung hat.Ich würde ja auf no-archive plädieren, aber sowas macht man nicht *hust*.
Schade finde ich auch, dass niemand gerade bei den etwas schärferen Korrekturpostings auf "fachlich hilfreich" klickt, und
seine Unterstützung zeigt. Die Korrekteure werden mit der Zeit einfach mürbe ohne Unterstützung.so far, so long
-
hi,
Die Korrekteure waren es müde noch ein Weiteres mal zu berichtigen (weil es auch dermaßen abstrus ist). Problematisch wird dies dann, wenn es im unkommentiert im Archiv landet.
Das ist erstens ein Problem der Moderation und zweitens habe ich die Posts der "Korrekteure" längst umgesetzt, wenn das Forum archiviert wird.
Viele Grüße,
Hotti -
Hallo Unbeteiligter,
also ich lese hottis Postings sehr gerne. Meistens nach Feierabend mit einem Bier in der Hand.
Genauso wie ich gerne (wegen demselben Grund) z.B. bash.org lese.Aehnlich wie bei einem Autounfall: Es ist eklig, aber weggucken kann man auch nicht :)
Die Postings könnten mystischer nicht sein.
Ja, da gibt es bereits eine Reihe an Klassikern (ein Bier wird hier nicht reichen):
* Hottis mystischer Location-Header
* Hottis mystisches XHR-Objekt
* Hottis mystische JSON-Serialisierung
* Hottis mystische Ausschweifungen zum Thema Datenhaltung
* Hottis <rem>mystisches</rem><ins>professionelles</ins> Buch ueber "Serialisierung und Strukturierung binaerer Daten"
* Hottis mystisches Verstaendnis von VPN
Ich würde ja auf no-archive plädieren, aber sowas macht man nicht *hust*.
Ne *reusper* so was macht man nicht.. es sei denn, man moechte der Qualitaet des Archivs etwas Gutes tun.
Schade finde ich auch, dass niemand gerade bei den etwas schärferen Korrekturpostings auf "fachlich hilfreich" klickt
Es ist beachtlich wie lernresistent und zugleich selbstueberschaetzend diese Person hier im Forum ist.
Grusz,
Christopher-
Hello,
Ich würde ja auf no-archive plädieren, aber sowas macht man nicht *hust*.
Ne *reusper* so was macht man nicht.. es sei denn, man moechte der Qualitaet des Archivs etwas Gutes tun.Wenn Du die GÜTE steigern willst, dann solltest Du nicht mur "Mystic Links" posten, sondern auch dazu schreiben, was Dir daran nicht gefällt und wie man es besser/richtig machen muss.
Anderenfalls hast Du zu hundert Prozent die Qualität von Meckerpostern in diesem Forum getroffen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Oh Wunder, woher konnte ich es nur erahnen, dass sich ausgerechnet derjenige, der Hotti's Niveau in Sachen Lernresistenz, Falschaussagen, pauschale Antworten, Einsichtsunfaehigkeit und Fluechten vor Argumenten am Naehsten kommt, nun hier zu Wort meldet. Es ergibt sich der Eindruck, dass es sich hierbei entweder um Sockenpuppen handelt, oder aber tatsaechlich um das Traumpaar dieses Forums.
Unabhaengig davon: Lesen kannst Du, ja? Denn ich werde meine Zeit ganz sicherlich nicht damit verschwenden nur fuer Dich zu den von mir bereits verlinkten Postings noch die Folgepostings - in denen ALLE Falschaussagen Hottis berichtigt und korrigiert werden - zu verlinken. Das solltest du wohl noch selber hinbekommnen.
Wie du siehst war dein Posting nicht mal wieder nur Unfug, sondern gaenzlich Fehl am Platz. Denn ich denke, dass auch dir das Wohl der Leser wichtig ist, und dass auch Du nicht moechtest, dass Anfaenger den Bloedsinn glauben, den Hotti so von sich gibt.
Bist Du dir eigentlich wirklich nicht bewusst, dass genau DU dein an mir kritisiertes Verhalten an den Tag legst?
Grusz,
Christopher* Ach, Und bevor Du jetzt wieder deine Standardaussagen von wegen "Rumstaenkern" und "nichts selber Produktives hinzufuegen" von dir gibst -- ach so, die kamen ja schon! -- erzaehl uns doch bitte noch mal mehr ueber Extremprogrammierung oder "Schleifenkonstruktionen unter OOP"!
Wie, moechtest Du nicht? Na, so was aber auch!-
Hello,
Du hast deine Qualität wieder voll eingehalten. War leider zu erwarten.
Ich hoffe, dass Du in Deinem Leben noch Gelegenheit bekommst, Dein Sozialverhalten zu trainieren und zu verbessern.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo,
Ich hoffe, dass Du in Deinem Leben noch Gelegenheit bekommst, Dein Sozialverhalten zu trainieren und zu verbessern.
Bring auch mal inhaltliches und nicht nur Mobbing gegen andere Forumsteilnehmer.. sonste werde ich mich für Sanktionen gegen Dich stark machen!
Hm, das Bier schmeckt gut, Tom.
Grusz,
Christopher-
Hello,
Bring auch mal inhaltliches und nicht nur Mobbing gegen andere Forumsteilnehmer.. sonste werde ich mich für Sanktionen gegen Dich stark machen!
Genau, das mach mal.
Wann wirst Du eigentlich Vierzehn?Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-
Hi,
also abgesehen davon, dass ich deine Kritik etwas hart finde, wollte ich mich hier eigentlich gar nicht einmischen ... aber wenn ich sehe, dass das „Spaltenarray“-Gefasel schon wieder losgeht*, rollen meine Augen und Fußnägel auch mal wieder um die Wette.
MfG ChrisB
* Präventiv, @Tom: Nein, Danke, diesbezüglich kein Diskussionsbedarf (mehr).
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
-
-
-
-
-
-
Hi,
So um 2001 (kann auch länger her sein) habe ich ein ähnliches Projekt verwirklicht, auch in Perl jedoch nicht objektorientiert. Der Code war schwer überschaubar und sehr pflegebedürftig... kurzum, das was Du als 'Buzzword' bezeichnest, ist für mich eine Erfahrung aus der heraus ich eine Empfehlung ableite.
Zwischen "nix" und OOP gibt es ja auch noch Funktionen. Damit kann man sehr wohl eine Benutzerverwaltung realisieren. Vielleicht solltest du dein altes Projekt ja mal dahingehend umgestalten ;)
Bei mir gibt es Rechtelevel. Mit weniger als 5 Zeilen Code pro direkt aufrufbaren Skript kann ich sehr genau festlegen wer was sehen darf. Für "inline"-Rechteabfragen tut es eine Winzige funktion um das Rechelevel als zahl oder auch als Text zu erhalten.
Also ich habe da noch nie Probleme gehabt.
Sicher kannst Du die Aufgabe (siehe ganz oben) auch anders angehen, bedenke jedoch, dass nicht nur Programmierer Fehler machen, sondern auch die Anwender und die Suche in einem 2000-Zeiler-Script ist zeitaufwändiger als die Suche in einem Modul. Gerade zum Thema, Session, Login, Benutzerverwaltung usw. gibt es auf CPAN erstklassige Module mit klar definierten Schnittstellen, deren produktive Vorzüge demjenigen entgehen, der sie nicht zweckentsprechend einsetzen kann oder gar nicht erst verwendet.
Arbeitest du mit Includes? Einrückungen? Kommentaren?
Gruß
Alex-
hi,
Bei mir gibt es Rechtelevel. Mit weniger als 5 Zeilen Code pro direkt aufrufbaren Skript kann ich sehr genau festlegen wer was sehen darf.
Bei mir auch: Rechtelevel ;)
Wieviele Scripte hast du denn?
Ich habe nur eins und das kriegt in einer Zeile mitgeteilt, welche Parameter in welchem Level erlaubt sind. Den Rest erledigt der (Achtung Buzzwort!) Frontcontroler.
@ChrisB: OOP ist sehr klischeebehaftet, aber das ist nicht meine Schuld. Was wirklich kompliziert ist, ist die Vererbung.
Hotti
-
Hi,
Wieviele Scripte hast du denn?
»»
Es sind einige - die Zahl weiß ich grad nicht genau. Wollte irgendwann mal ein riesen Dokument machen, dass ich auch mal sehe wie viel Zeilen es insgesamt sind etc. ...hab ich aber noch nicht ;)Ich habe nur eins und das kriegt in einer Zeile mitgeteilt, welche Parameter in welchem Level erlaubt sind. Den Rest erledigt der (Achtung Buzzwort!) Frontcontroler.
»»
Der Login etc. passiert vor den einzelnen Skripten mit ihren Programmmodulen. In den Skripten ist dann jeweils festgelegt welches Rechtelevel was darf...Gruß
Alex-
hi Alex,
danke Dir!
Der Login etc. passiert vor den einzelnen Skripten mit ihren Programmmodulen. In den Skripten ist dann jeweils festgelegt welches Rechtelevel was darf...
!One Ring tu rule them all. Ein Script für Dies, ein Script für Jenes. Mit jedem Script schwindet die Übersicht... Idee: Ein Script macht alles. Teilaufgaben sind in Modulen ausgelagert mit klar definierten Schnittstellen z.B. für die Authentication/Authorization um die es hier geht. CPAN-Module kommen genau dem entgegen, die haben Layer für sowas: Radius, File, MySQL... was das Herz begehrt. Kein Gefrickel und der Spaß am Selbermachen geht trotzdem nicht verloren.
Hotti
-
-
-
Zwischen "nix" und OOP gibt es ja auch noch Funktionen.
Und Zwischen "nix" und "Funktionen" gibt es sogar noch Prozeduren :p
-
Hello,
Zwischen "nix" und OOP gibt es ja auch noch Funktionen.
Und Zwischen "nix" und "Funktionen" gibt es sogar noch Prozeduren :p
Und wie bezeichnet man fachlich richtig die Goto-Spaghetti-Codes?
Das interessiert mich jetzt mal.(Wieso ist mein Post eben schon wieder im Nirvana verschwunden?)
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Zwischen "nix" und OOP gibt es ja auch noch Funktionen.
Und Zwischen "nix" und "Funktionen" gibt es sogar noch Prozeduren :p
Und wie bezeichnet man fachlich richtig die Goto-Spaghetti-Codes?
Das interessiert mich jetzt mal.Das ist noch nichtmal strukturierte Programmierung - das ist das einfachste was imperative Sprachen hergeben - Spaghetti-Code ist möglicherweise sogar möglicherweise die Korrekte bezeichnung für den antiken GOTO-Krempel :D
-
-
-
Moin,
Bei mir gibt es Rechtelevel. Mit weniger als 5 Zeilen Code pro direkt aufrufbaren Skript kann ich sehr genau festlegen wer was sehen darf. Für "inline"-Rechteabfragen tut es eine Winzige funktion um das Rechelevel als zahl oder auch als Text zu erhalten.
Noch besser: Konfiguration vom Code trennen.
Arbeitest du mit Includes? Einrückungen? Kommentaren?
Freilich.
Nochwas zur Rechteverwaltung, mal angenommen, Du hast auf der Seite ein Download /kunde/otto.jpg
Laut Projektverwaltung ist der Content-Type: image/jpg
Jetzt möchte Kunde, dass das Bild nur in einer Anmeldung mit Level 99 zu sehen ist. Du möchtest dazu eine ordentlich formatierte Fehlermeldung einschließlich Navigation ausgeben, wenn keine Anmeldung im Level 99 vorliegt, d.h., du musst den Content-Type auf text/html ändern. Aber nicht nur den type, sondern auch Last-Modified, denn Fehlermeldungen brauchen keinen Cache. Jetzt haben wir schon zwei Attribute, die zu ändern sind, das Dritte ist der Content selbst, der URL jedoch soll ja bleiben. Wenn Du oo herangest, hast du nur _eine Methode, die das Ganze erledigt, d.h. im Fehlerfall rufst Du in Deinen Kontrollstrukturen nur noch die Methode $object->errpush("Anmleldung im Level '$level' erforderlich", "...").
Viele Grüße,
schöne Osterferien,Hotti
-
Hello,
Jetzt möchte Kunde, dass das Bild nur in einer Anmeldung mit Level 99 zu sehen ist. Du möchtest dazu eine ordentlich formatierte Fehlermeldung einschließlich Navigation ausgeben, wenn keine Anmeldung im Level 99 vorliegt, d.h., du musst den Content-Type auf text/html ändern. Aber nicht nur den type, sondern auch Last-Modified, denn Fehlermeldungen brauchen keinen Cache. Jetzt haben wir schon zwei Attribute, die zu ändern sind, das Dritte ist der Content selbst, der URL jedoch soll ja bleiben. Wenn Du oo herangest, hast du nur _eine Methode, die das Ganze erledigt, d.h. im Fehlerfall rufst Du in Deinen Kontrollstrukturen nur noch die Methode $object->errpush("Anmleldung im Level '$level' erforderlich", "...").
Dann musst Du aber auch das Template ändern, oder kann man in einem <img>-Element jetzt auch text/html anzeigen? Dann hätte ich wieder was gelernt.
Ostergrüße aus dem schönen Oberharz
Tom vom Berg
-
Hello,
Jetzt möchte Kunde, dass das Bild nur in einer Anmeldung mit Level 99 zu sehen ist. Du möchtest dazu eine ordentlich formatierte Fehlermeldung einschließlich Navigation ausgeben, wenn keine Anmeldung im Level 99 vorliegt, d.h., du musst den Content-Type auf text/html ändern. Aber nicht nur den type, sondern auch Last-Modified, denn Fehlermeldungen brauchen keinen Cache. Jetzt haben wir schon zwei Attribute, die zu ändern sind, das Dritte ist der Content selbst, der URL jedoch soll ja bleiben. Wenn Du oo herangest, hast du nur _eine Methode, die das Ganze erledigt, d.h. im Fehlerfall rufst Du in Deinen Kontrollstrukturen nur noch die Methode $object->errpush("Anmleldung im Level '$level' erforderlich", "...").
Dann musst Du aber auch das Template ändern,
Nein. Templates haben mit dem PAB nichts zu tun. Es läuft so ab, dass Eingabefehler ersteinmal nur "gesammelt" werden. Die Methode errpush() kann dazu mehrfach aufgerufen werden.
Im Finale brauchts dann keine weitere Kontrollstruktur, es werden einfach nur die Methoden gerufen, die auf die relevanten Eigenschaften zugreifen; Content-Type und Last-Modified gehören in den Header, der Rest ist Body (als Beispiel). Ich rufe also die Methoden obj.header() und obj.body(). Bis dahin, ist der Body mit Inhalten gefüllt, z.b. auch mit Content, der nur im Level 2 zugänglich sein soll. Das Level wurde jedoch weiter vorn geprüft und errpush() hat eine Liste von Fehlermeldungen erzeugt. Die Methode body() schaut, ob Fehler aufgelaufen sind und tauscht den kompletten Body gegen den bisherigen Body aus.
oder kann man in einem <img>-Element jetzt auch text/html anzeigen?
Im Zweifelsfall schauen wir bei SELFHTML nach ;)
Viele Grüße aus dem sonnigen Rheinessen,
HottiPS: Hab heute in Hessen neue Schuhe gekauft, der letzte Schrei! Die werden am Oster-WE in Thüringen ausgiebig getestet, ob sie Harz-tauglich sind ;)
-
-
-
-
-
-
Hello,
Ich würde gerne eine Login-Bereich auf meiner Website realisieren. Dieser soll so funktionieren, dass man sich mit Benutzername und Passwort anmelden kann. Das etwas aufwendige an der ganzen Gecshichte ist, dass mit mit verschiedenen Zugrifssdaten auf verschiedene Seiten kommt.
d.h.:
Seite1.html für benutzer a
seite2.html für benutzer bSoll denn PHP verwendet werden?
Werden diese "Seiten" auch vom PHP-Parser erstellt?
Müssen sie die Endung *.html haben? Hast Du entsprechnede Zugriffsrechte auf dem Webserver, um dies auch umzusetzen? Dann müssten *.html-Ressourcen eventuell auch vom PHP-Parser verarbeitet werden.Ich gehe davon aus, dass die Dokumente ohne Anmeldung nicht erreichbar sein sollen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
hi,
Falls Du nochmal reinschaust...
Ich habe das halbe Netz abgesucht und leider von mysql bzw. php nicht viel Ahnung. Mit Hilfe von einem Tutorial bekomm ich das aber schon hin. Leider hab ich bislang nix in der Richtung gefunden. Kann mir jemand helfen?
Das Erste, was Du brauchst, ist eine Session, die am Einfachsten über einen Cookie zu realisieren ist: Im Cookie ist ein Schlüssel hinterlegt, über den der Serverprozess, der die Seiten ausgibt, den Browser identifizieren kann. D.h., solange der Benutzer den Browser nicht schließt und ein neues Browserfenster aufmacht, ist der Schlüssel über eine Browsersitzung immer dergleiche. In dieser 'Ausbaustufe' ist der SessionKey (Session ID, SID) nur im Cookie gespeichert, dazu brauchst Du keine Datenbank oder Datei.
Die zweite Mindestanforderung ist eine Datenquelle, in der Benutzername, Passwort und Gruppenzugehörigkeit hinterlegt ist und eine Schnittstelle dazu. Selbstverständlich sind die Passworte nicht im Klartext gespeichert. Hier musst Du schauen, was in Frage kommt, die Möglichkeiten sind sehr vielfältig, das können Dateien sein, Directories, dedizierte Server(z.B. Radius) oder Datenbanken und natürlich auch MySQL.
Die dritte Anforderung beschreibt den Speicherort, in welchem die Login's gespeichert sind, Benutzername, Zeitpunkt der Anmeldung und Gruppenzugehörigkeit. Kann Datei sein, MySQL.... hängt von den Gegebenheiten ab.
Dann schaust Du in Deine Projektverwaltung, die Seiten müssen einen Flag (Tag, Attribut) bekommen, was die authorizierte Verwendung betrifft. Das kann numerisch sein (Level) oder der Gruppenname. Beispiel für Level:
URL Level
/foo 0 darf jeder sehen aber keine Parameter
/foo/bar 1 darf jeder sehen und Post/Get Parameter senden
/maint/admin 2 darf nur, wer in Level 2 angemeldet istDer Vorteil in der Verwendung von Levels gegenüber Gruppennamen besteht darin, das im Programm nur mit Zahlen operiert wird. Andererseits sind Gruppennamen besser zu merken und zu lesen.
Hast Du das, kommt der Loginprozess. Das kann ein eigenes Script sein oder der Prozess ist voll integriert in die gesamte Anwendung. Kunde gibt Name und Passwort ein und der Prozess liefert bei Erfolg die Gruppenzugehörigkeit (Level) zurück. Das wiederum wird zusammen mit dem SessionKey (SID) am Speicherort "Logins" eingetragen mit der SID als Schlüssel.
Die Anwemdung, die ja die SID kennt, hat somit jederzeit über eine Browsersitzung die Kontrolle darüber, wer mit welchem Level angemeldert ist und kann die Seite entweder native ausliefern oder mit einem anderen Inhalt.
Andere Möglichkeiten gibts bestimmt, z.B. derart, dass eine Session erst mit einer erfolgreichen Anmeldung aufgebaut wird.
Viel Erfolg,
Hotti