Ergebnis 1 bis 8 von 8

Thema: Userverwaltung

  1. #1
    h0tzenpl0tz ist offline Neuer Benutzer
    Registriert seit
    02.07.2011
    Beiträge
    2

    Standard Userverwaltung

    Hallo zusammen.


    Ich habe eine ziemlich grundsätzliche Frage eines Anfängers.


    Ich bin ein kleines Projekt am planen, es geht quasi um eine Webseite, wo verschiedene User ihre Daten zusammentragen können (eine Informationsplattform). Es sollte also verschiedene User geben, welche auch unterschiedliche Lese- und Schreibrechte haben (z.B. Admin, registrierter Benutzer, Gast).


    Meine Frage ist nun, wie ich diese User am Schlausten verwalte. Bei einem früheren Projekt (mit MySQL) hab ich etwa eine Tabelle "user" erstellt, wo dann Benutzername, Passwort etc. drin stand. Dann müsste ich aber fast noch eine zusätzliche Tabelle machen, wo drin steht welche Benutzergruppe was machen darf. Das wäre sicherlich eine Möglichkeit, doch ich weiss nicht ob es die beste ist.


    Für dieses Projekt will ich PostgreSQL 8.4 verwenden (hauptsächlich wegen PostGIS) und habe gesehen, dass PostgreSQL einige Möglichkeiten bezüglich Benutzer und deren Rechte bietet. Allerdings bin ich nicht sicher ob ich das richtig verstanden habe: könnte ich also beispielsweise für jede Benutzergruppe (z.B. registrierter Benutzer) eine ROLE (als Gruppe) erstellen mit den entsprechenden Lese- und Schreibrechten? Und dann würde jeder neu registrierte Benutzer eine neue ROLE innerhalb dieser Gruppe erhalten? Oder werden diese ROLEs hauptsächlich dazu verwendet, um den direkten Zugriff auf die Datenbank zu regeln?


    Ich weiss einfach nicht was diesbezüglich das gängige Vorgehen ist und auch die Vor- und Nachteile der beiden Methoden nicht ganz klar. Wenn ihr diesbezüglich einige Tipps hättet, wäre ich darüber sehr dankbar!


    Vielen Dank für eure Hilfe!


    Lieber Gruss

  2. #2
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.055

    Standard

    Das was du in der Dokumentation gefunden hast, sind Datenbankbenutzer und Rollen.
    Das möchtest du eigentlich nicht dafür verwenden.

    Implementiere dein eigenes Rechtekonzept für deine Webseite, das ist sinnvoll und lässt dir alle Möglichkeiten offen.
    Außerdem brauchst du dann nur einen Benutzer, mit dem sich die Webseite zur Datenbank verbindet.
    Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören

    Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

    PostgreSQL Service & Support

  3. #3
    akretschmer ist offline Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.465

    Standard

    Zitat Zitat von ads Beitrag anzeigen
    Das was du in der Dokumentation gefunden hast, sind Datenbankbenutzer und Rollen.
    Das möchtest du eigentlich nicht dafür verwenden.
    Warum eigentlich nicht?

    Implementiere dein eigenes Rechtekonzept für deine Webseite, das ist sinnvoll und lässt dir alle Möglichkeiten offen.
    Außerdem brauchst du dann nur einen Benutzer, mit dem sich die Webseite zur Datenbank verbindet.
    Dann muß er für die Website die User ja auch irgendwie verwalten. Vielleicht in einer Datenbank?

    @ads: sorry, aber ich kann Deinen Einwänden nicht ganz folgen.

    @hotzenplotz: warum 8.4? Bei guten Providern findest Du 9.0, und wenn 9.1 stable ist, dann das. ;-)


    Andreas
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  4. #4
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.055

    Standard

    Nun, erstens braucht er einen privilegierten Nutzer, um weitere Nutzer anzulegen.
    Wenn er das Rollenkonzept der Datenbank verwendet, loggt sich jeder Benutzer von der Webseite aus mit "seinem" Account in die Datenbank ein.
    Um neue Accounts anzulegen, braucht es halt irgendjemanden, der das in der Datenbank darf. Das ist per se schon mal unschön.

    Dann weiß danach auch jeder User sein Datenbankpasswort. Wenn derjenige an der Webseite vorbei irgendwie auf die Datenbank kommt (ist ja ein internes System), dann kann er sich direkt auf der DB einloggen und ggf. allerhand Unsinn machen.

    Das Rollenkonzept von PostgreSQL bildet "nur" Benutzer und Gruppen ab. Das reicht für die Datenbank - reicht es auch für die Webseite?

    Zum Ändern von Rechten an irgendeinem Objekt in der DB muss man wiederum entweder Eigentümer des Objekts oder ein SuperUser sein. Problematisch.

    Connection Pooler und ähnliches funktionieren nicht, wenn du mit vielen unterschiedlichen Datenbankverbindungen daher kommst.


    Die Liste lässt sich noch fortsetzen.
    Ich sehe da nur wenig Vorteile darin, die Datenbankrollen dafür zu verwenden - jedoch eine Menge Nachteile.
    Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören

    Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

    PostgreSQL Service & Support

  5. #5
    Gisman ist offline Erfahrener Benutzer
    Registriert seit
    20.01.2006
    Ort
    Pfalz
    Beiträge
    790

    Standard

    Hallo!

    Wenn du das richtige Framework für deine Anwendung nimmst brauchst du dich um die Nuetzerverwaltung kaum kümmern. In der Python Welt würde ich dir Turbogears2 oder Django empfehlen, die bringen beide eine Userverwaltung mit, die du deinen Ansprüchen gemäß anpassen kannst. Turbogears benutzt dazu als ORM SQLAlchemy, was Postgres sehr gut unterstützt.
    Die Argumente von ads kann ich s unterschreiben. Das Rollenmodell der Datenbank zu verwenden, wäre zwar möglich, stellt aber eine nicht zu unterschätzende Quelle von Mehraufwand und Fehlern dar. Auch möchte man ganz gern die verschiedenen Ebenen einer Webanwendung aus Sicherheitsgründen getrennt haben. Eine Berechtigungsstruktur wie in einer Webanwendung möchte ich nicht in der DB nachbauen müssen. Zusätzlich vereinfacht es die Portierung der DB, was bei kleinen Webprojekten/in der Testphase ja schon mal vorkommen kann.

    Gruß Uwe
    Have a lot of fun!

  6. #6
    h0tzenpl0tz ist offline Neuer Benutzer
    Registriert seit
    02.07.2011
    Beiträge
    2

    Standard

    Hallo zusammen.

    Vielen Dank für die raschen Antworten! Ich werde demnach wohl wie bei meinem früheren Projekt die Benutzerverwaltung mit einer eigenen "user"-Tabelle machen. Ein weiterer Gedanke für die Verwendung von mehreren Datenbank-Benutzern war, dass ich im gerne einen Audit-Trail hätte, also Veränderungen in der Datenbank aufzeichnen möchte. Dies stelle ich mir am Einfachsten mit Trigger-Funktionen vor, wo ich dann den für die Veränderung verantwortlichen Benutzer ziemlich einfach herausfinden könnte ('SELECT current_user' oder so). Wenn ich nun immer mit einem einzigen Benutzer auf die Datenbank zugreife, funktioniert das dann nicht mehr. Vielleicht hat diesbezüglich grad jemand noch eine gute Lösung oder einen Tipp parat, oder ist somit ein solcher Trail mit Triggern gar nicht mehr umsetzbar?

    PostgreSQL 8.4 verwende ich im Übrigen deshalb, weil ich auch Karten mit PostGIS und MapFish einbinden möchte. Und MapFish scheint (noch) nicht mit PosgreSQL 9.0 kompatibel zu sein.

    Aber da MapFish auch auf Python (Pylons) basiert, könnten insbesondere die Empfehlungen von Gisman von Interesse sein. Ich weiss jetzt zwar noch nicht ganz wie ich Django oder Turbogears2 genau einbinden könnte - sind das nicht auch eigenständige Frameworks und würden daher mit MapFish eher konkurrieren als Vorteile bringen? Eh ja, werd mir die Sachen jedenfalls gerne mal anschauen (und hoffentlich schlau draus werden).

    Vielen Dank nochmals!

    Liebe Grüsse,
    Lukas

  7. #7
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.055

    Standard

    Das mit den Triggern ist richtig. Dafür hatte ich mal ein PostgreSQL-Modul geschrieben, nennt sich "table_log".
    Allerdings musst du abwägen zwischen dem sicheren Audit in der DB und dem sehr erheblichen Mehraufwand in der Applikation.
    Einen entsprechenden Audit Trail könntest du also auch in der Applikation erledigen. Speziell wenn du ein zentrales Modul für die Kommunikation mit der Datenbank verwendest.
    Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören

    Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

    PostgreSQL Service & Support

  8. #8
    Gisman ist offline Erfahrener Benutzer
    Registriert seit
    20.01.2006
    Ort
    Pfalz
    Beiträge
    790

    Standard

    AFAIR nutzt Mapfish GeoAlchemy, eine Geodaten-Erweiterung von SQLAlchemy. Eigentlich sollte das gehen, allerdings kommt es dabei vermutlich eher auf die Version des darunterliegenden psycopg2-Treibers an. Zumindest läuft bei uns verschiedenes auf PG 9.0.4 und Python 2.6, sowohl Turbogears, als auch direkt SQLAlchemy Anwendungen ohne Probleme. Du kannst dir ja mal ein virtualenv bauen und verschiedene Varianten ausprobieren, ohne dir gleich eine ganze Pythoninstallation zu versauen
    Da Turbogears ebenfalls auf Pylons basiert, solltest du dir das unbedingt mal anschauen. Ansonsten sähe ich unter Python nur wenig Probleme , verschiedene Dinge zusammen zu werfen .
    Du kannst unter SQLAlchemy Trigger auch in Form von Events im Klassenmodell abbilden. Damit lassen sich recht mächtige Effekte generieren, wenn man das benötigt, hab allerdings nur mal ein bisschen damit rumprobiert.

    Gruß Uwe
    Have a lot of fun!

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Links: Tobias Bauer - IT- und Funkdienstleistungen   -   Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen   -   Funkforum