User und so

Kampfgummibaerlie

Datenbank-Guru
Beiträge
728
Also, meine 1. Idee war, eine eigene Tabelle zu erstellen, welche das PW und den Username beinhaltet, aber ja, nachdem ich mich in meinem Leben noch deutlich länger damit auseinandersetzen wollen würde (!), möchte ich auch das ganze Role-System von PostgreSQL verstehen, und so weiter.

Was mir bisher aufgefallen ist:
Ich müsste zB die Rolle "Anonym" (für jeden, der sich mal eben anmeldet) folgenden Code verwenden, damit die Homepage, auf der ich pg_connect als user "Anonym" verwende folgenden Code verwenden:

Code:
create role anonym nosuperuser nocreatedb inherit login noreplication in role postgres

Warum erstelle ich hier dann einen eigenen Thread?
Ich weiß, lieber Akretschmer, dass ich in der Doku nachschauen soll. Rate mal woher ich den bisherigen Code habe ;)

Und würde hierbei eben gerne nachfragen, was wie sinnvoller wäre:
1.: Sollte ich die ganzen User in eine eigene Tabelle fassen, oder liefert PostgreSQL eigentlich eh ein entsprechend gutes "Role-System"?

2.: Kann man von einer Role noch eine Unter-Role machen? Zum Beispiel: Eine Familie Gruber, und diese Familie Gruber hat einen Ernst, Franz und Sepp, ich möchte in diesem Fall (habe ich nicht vor anzuwenden, aber es würde mich interessieren) der Gruppe "Gruber" allgemein das "Recht" geben, eine eigene Datenbank zu erstellen. Wird dann eine geänderte Eigenschaft geerbt? (Ja, ich weiß, dass man (1 mal sicherlich) erben einstellen kann, aber ich weiß nicht ob das auch bei Veränderungen so stattfindet.

3.: Muss ich eine Role erstellen, welche wiederum die einen oder anderen Rechte von Postgres erbt, welche dann wiederum die noch vorhandenen Rechte erbt?

Anhang:
Ja, ich werde wohl durch meinen Try & Error - Lehrweg selbst draufkommen (Macht auch den meisten Spaß ^^)
 
Werbung:
Achtung! Das Passwort sollte niemals (!) unverschlüsselt in der DB gespeichert werden.

Viele Web Applikationen nutzen einen DB nutzer, mit dem sie alles was die DB betrifft gemacht wird (select, insert,...) machen. Die Anwender werden dann in der DB gespeichert.

Man kann natürlich DB User nutzen, muss aber dann die Anmeldung von der Applikation durchreichen. Wird aber eher weniger gemacht, da klassischerweise die DB Rechte eher auf Tabellen eingeschränkt wurden und von den Applikationen eher Daten innerhalb einer Tabelle verrechtet werden sollten. Dabei benötigt man dann zwei Ebene für die Rechte. Mittlerweile gibt es bei vielen Datenbanken die Möglichkeit einzelne Zeilen zu berechtigen. K.a. ob dies häufig genutzt wird.


Bei dem Thema Sicherheit ist ein Try & Error kein optimaler Lehrweg, vorallem wenn das System online erreichbar ist.
 
Ich sehe das auch so wie @Dukel. PostgreSQL kann zwar Dinge wie Row Lecel Security und hat auch ein sehr mächtiges Benutzerkonzept mit Rollen, Vererbungen etc., mit dem man sehr viel abbilden kann. Ich kenne auch Kunden, die das intensiv nutzen. Aber für die Anwendung unseres Freundes hier mehrere Zehnerodnungen zu komplex - und unnötig.
 
Das Passwort sollt überhaupt nicht in der DB gespeichert, sondern als Hash abgelegt sein. Bitte mit Salz und kein MD5, SHA-1 o.ä.
 
Bezüglich zu diesem Thema, da ich ja täglich nichts anderes zu tun habe, und außerdem nach einer Pause immer noch interessierter darin bin, als vorher, jetzt meine (bisher beste) Lösungsmethode, die ich im Internet gefunden habe:
Easy password hashing with Postgres and pgcrypto

Ich habe darin gelesen, dass in diesem "Guide", nenne ich es mal, auch ein Salt verwendet wird.

Meine erste Frage bezüglich dazu:
Darf ich mich trauen, es (ersteinmal nur ohne wirklich enorm riskanten Daten, wie Kontonummern, Telefonnummern, oder sonstiges) anzuwenden, und in erster Linie nur den Zweck von privaten Erwartungen zu erfüllen? xD (Mir ist nichts anderes als Begründung eingefallen... :/ )

Weil ich würde verdammt gerne mit Usern arbeiten, wenn auch in der Anfangsphase nur zwecks einer kleinen Plauderecke, wo ein jeder "User" seine x-beliebigen Texte reinkritzeln kann.

Meine zweite Frage bezüglich dazu:
Kann man mittels dem Contains-Operator auch Texte vergleichen? Ich hätte vor, einen Schimpfwortschutz einzuprogrammieren, damit ich nicht haften kann, falls dort irgendwer nicht wirklich legitime Dinge hineinschreiben sollte.
 
1 Minute zu spät....

Lösung bezüglich des Wortfilters, ja, es ist möglich, einfach über den Concalation-Syntax (Glaube, heißt so xD):

Beispielhaft:
Code:
select * from plauderecke where lower(message) like '%'||lower('ich')||'%'

nimmt alle Reihen aus plauderecke, in welcher die Spalte message das wort "ich" enthält.
ist sicherlich auch mit den entsprechenden anderen Worten verungleichbar.
 
die Performance dürfte unterirdisch sein. Beschäftie Dich mit diesem Kapitel: PostgreSQL: Documentation: 10: Chapter 12. Full Text Search

Ich denke/hoffe du meinst die Performance von dem Schimpfwortfilter, wäre aber auch sehr erfreut über deine Meinung bezüglich dem mit den Passwörtern.
Das mit dem Schimpfwortfilter ist mir gelungen, über die Methode, die du mir geschrieben hast (1 functions und 1 constraint)
1. Function select * from schimpfwörter (die nur 1 spalte als text hat)
2. Constraint der mittels Check prüft ob eben 1 Wort der tabelle schimpfwörter enthalten ist, und eben diese nicht zulässt, weil die function in Punkt 1 False sein muss laut constraint, und ein eintragen verhindert.

Bin gerade im Kinderdienst (Neffen aufpassen), wollte euch nur am Stand meiner Erfahrung teilhaben lassen ^^

EDIT: Den Dienst editiert, verdammte Auto-Korrektur, muss ich mal abschalten :D
 
Zuletzt bearbeitet:
Aber ja, für alle weiteren, die es interessieren würde:

Hier der Code, den ich in einer Function stehen habe: (Ich denke mir, ich brauche nicht erläutern, wie man das in eine Function integrieren kann)
Code:
insert into accounts(name, passwort) VALUES (x, crypt(y, gen_salt('bf', '8')));

Die Authentifizierungsfunktion:
Code:
create or replace function account_auth(x text, y text) returns boolean
as $$ declare passed boolean; begin SELECT passwort = crypt($2, passwort) into passed
FROM accounts where name = $1; return passed; end; $$ language plpgsql;

Um das Ganze zu probieren:
select account_auth('dein_benutzername', 'dein_passwort')

Wenn ihr sowohl den Benutzernamen, wie auch das Passwort richtig angegeben habt, sollte dabei folgendes rauskommen:
17.png

Falls hier irgendwas fragwürdig mit Sicherheit oder sonstiges ist, bitte sofort schreien ;) (Noch bleibt das Ganze eh nur offline, aber ja... ihr wisst ja, Sicherheit geht vor)

EDIT: Ja, Akretschmer, am Ende hat mir die PostgreSQL-Doku geholfen ;D
 
Nachdem ich heute wieder bei diesem Punkt gehangen bin, aber wegen Scharm nicht fragen wollte, hier der Code für eine Authentifizierungs-Function, welche true oder false antwortet:

Code:
create function new_account(x text, y text) returns void as $$ insert into accounts(name, passwort) VALUES (x, crypt(y, gen_salt('bf', '8'))) $$ language sql;

Es sind offenbar die Dollarzeichen wichtig (?), weil, wie ich das ganze mit einfachen Anführungszeichen probiert habe, ging es nicht, glaube ich :/

Aber ja, bevor wir es vergessen, weil es hier noch nie erwähnt wurde:
Nötig dafür ist die Extension pgcrypto, welche mittels folgendem Code einfach installiert wird:

Code:
create extension pgcrypto;

Danke :)
 
Der Funktionstext ginge auch mit ' anstelle der $$, dann müßtest Du aber innen dann doppelt quoten. Das sog. Dollar-Quoting wurde irgendwann mit 8.x eingeführt - lange her.
 
Werbung:
Zurück
Oben