nicht angemeldet
Konstante User in PHP-Code oder Datenbank speichern?
Hi,
bin grade dabei, ein CMS zu coden. Da soll es einige Superadmins
geben, die andere Admins bzw. Projekte anlegen können. Habe zwar
Usertabellen, aber nur für Projekte (acms_[Projekt-ID]_users),
jedoch nicht für Superadmins; sie sind ja projektunabhängig.
Jetzt meine Frage: Eine Superadmin-Tabelle (acms_users) anlegen,
oder die Superadmins in den PHP-Code schreiben?
Der jetzige Code:
http://asc0000.calibra-web.de/acms/?show_source=authenticate
Was meint ihr?
Danke schon im Voraus,
Peter
-
Moin
Jetzt meine Frage: Eine Superadmin-Tabelle (acms_users) anlegen,
oder die Superadmins in den PHP-Code schreiben?Was meint ihr?
Kommt drauf an wie oft sich die Superadmins ändern und wer die Änderungen vornehmen soll. Allein mit Blick auf die Zukunft würde ich für die Tabellenlösung plädieren. Persönlich bin ich ausserdem dafür einen Superuser fest in das Skript zu coden, der die ganze Anlage wieder aus der Sch* ziehen kann, falls die Datenbank ausfällt, kaputtgeht, nicht verfügbar ist, etc.
--
Henryk Plötz
Grüße aus Berlin-
Moin
N'Abend auch,
Kommt drauf an wie oft sich die Superadmins ändern und wer die Änderungen vornehmen soll. Allein mit Blick auf die Zukunft würde ich für die Tabellenlösung plädieren. Persönlich bin ich ausserdem dafür einen Superuser fest in das Skript zu coden, der die ganze Anlage wieder aus der Sch* ziehen kann, falls die Datenbank ausfällt, kaputtgeht, nicht verfügbar ist, etc.
Tägliche Datenbanksicherung. Ich bin auch für eine Tabellenlösung,
wir schreiben zu zweit an dem CMS, und der andere ist für die an-
dere Lösung, da er meint, diese Tabelle verbrauche zu viele Res-
sourcen. Stimmt nicht, oder?
Dieser eine Superadmin ist nicht schlecht, allerdings wüsste ich
nicht, wozu man den braucht, da ich wie gesagt jeweils die aktue-
elle Datenbanksicherung, die vom Vortag, Zugriff aus die Datenbank
via phpMyAdmin2 und SSH habe. Oder gibt's noch einen Grund?Danke für deine Antwort,
Peter-
Moin
Tägliche Datenbanksicherung. Ich bin auch für eine Tabellenlösung,
wir schreiben zu zweit an dem CMS, und der andere ist für die an-
dere Lösung, da er meint, diese Tabelle verbrauche zu viele Res-
sourcen. Stimmt nicht, oder?Also wenn euer DBMS nicht grade auf einem 486 läuft kriegt ihr das gar nicht mit.
Dieser eine Superadmin ist nicht schlecht, allerdings wüsste ich
nicht, wozu man den braucht, da ich wie gesagt jeweils die aktue-
elle Datenbanksicherung, die vom Vortag, Zugriff aus die Datenbank
via phpMyAdmin2 und SSH habe. Oder gibt's noch einen Grund?Nein, ich mag es nur wenn sich meine Skripte von selbst wieder aus der Bredouille befreien können, bzw. ich sie bei einer Erstinstallation auf eine leere Datenbank loslassen kann, um dann die ersten Benutzer direkt aus den Skripten heraus zu erstellen und nicht irgendwo eine SQL-Query abschicken zu müssen, um mich beim ersten Mal überhaupt einloggen zu können. Ausserdem sollen sich die Superadmins doch wohl nicht gegenseitig erstellen können, oder? Und wenn es dafür sowieso genau _einen_ privelegierten Benutzer gibt, kann man doch dessen Sonderrolle dadurch betonen dass man ihn fest verdrahtet. Zumal: Falls ihr wirklich mal einen GAU habt und jemand es schafft Müll in die User-Tabelle zu schreiben, braucht ihr (nachdem das Skript von der Sicherheitslücke befreit wurde) nicht erst das ganze Backup vom Vortag einspielen und sämtliche Änderungen der Zwischenzeit verlieren oder mühselig die User-Tabellen aus dem Backup rausfischen um sie wiedereinzuspielen, sondern loggt euch über den unveränderten, weil unveränderbaren, Superuser ein und bringt die Tabellen wieder in Ordnung. (Wenn der böse Bube es geschafft hat den Quellcode zu verändern habt ihr sowieso verloren.)
Generell kann es nicht schaden, zwei unabhängige Authorisationsinstanzen (Datenbank und Quellcode) zu haben, denn du weisst ja: shit happens.
--
Henryk Plötz
Grüße aus Berlin-
Moin
Tägliche Datenbanksicherung. Ich bin auch für eine Tabellenlösung,
wir schreiben zu zweit an dem CMS, und der andere ist für die an-
dere Lösung, da er meint, diese Tabelle verbrauche zu viele Res-
sourcen. Stimmt nicht, oder?Also wenn euer DBMS nicht grade auf einem 486 läuft kriegt ihr das gar nicht mit.
Dieser eine Superadmin ist nicht schlecht, allerdings wüsste ich
nicht, wozu man den braucht, da ich wie gesagt jeweils die aktue-
elle Datenbanksicherung, die vom Vortag, Zugriff aus die Datenbank
via phpMyAdmin2 und SSH habe. Oder gibt's noch einen Grund?Nein, ich mag es nur wenn sich meine Skripte von selbst wieder aus der Bredouille befreien können, bzw. ich sie bei einer Erstinstallation auf eine leere Datenbank loslassen kann, um dann die ersten Benutzer direkt aus den Skripten heraus zu erstellen und nicht irgendwo eine SQL-Query abschicken zu müssen, um mich beim ersten Mal überhaupt einloggen zu können. Ausserdem sollen sich die Superadmins doch wohl nicht gegenseitig erstellen können, oder? Und wenn es dafür sowieso genau _einen_ privelegierten Benutzer gibt, kann man doch dessen Sonderrolle dadurch betonen dass man ihn fest verdrahtet. Zumal: Falls ihr wirklich mal einen GAU habt und jemand es schafft Müll in die User-Tabelle zu schreiben, braucht ihr (nachdem das Skript von der Sicherheitslücke befreit wurde) nicht erst das ganze Backup vom Vortag einspielen und sämtliche Änderungen der Zwischenzeit verlieren oder mühselig die User-Tabellen aus dem Backup rausfischen um sie wiedereinzuspielen, sondern loggt euch über den unveränderten, weil unveränderbaren, Superuser ein und bringt die Tabellen wieder in Ordnung. (Wenn der böse Bube es geschafft hat den Quellcode zu verändern habt ihr sowieso verloren.)
Generell kann es nicht schaden, zwei unabhängige Authorisationsinstanzen (Datenbank und Quellcode) zu haben, denn du weisst ja: shit happens.
--
Henryk Plötz
Grüße aus BerlinTach Leude,
ich hab nie gemeint, das des zu viel Ressourcen verbrauchen würde, sondern nur, dass des unübersichtlich wird. Vor allem, weil es ja sowieso nur einen Superadmin geben wird. Und die anderen meinen ja auch, dass einer im Quellcode stehen sollte!
Gruß,
Manni-
Moin
ich hab nie gemeint, das des zu viel Ressourcen verbrauchen würde, sondern nur, dass des unübersichtlich wird. Vor allem, weil es ja sowieso nur einen Superadmin geben wird. Und die anderen meinen ja auch, dass einer im Quellcode stehen sollte!
Ja, sicher, bei _einem_ Admin würde ich den in den Quellcode schreiben. Ich persönlich mag die Zero-One-Infinity-Rule(http://www.tuxedo.org/~esr/jargon/html/entry/Zero-One-Infinity-Rule.html) und glaube kaum dass ihr unendlich viele Admins in den Quellcode eintragen wollt. Daher: 1 Admin -> Quellcode, unbestimmte Anzahl -> Datenbank.
Im übrigen:
bin grade dabei, ein CMS zu coden. Da soll es einige Superadmins
geben,"Einige" ist mehr als einer, daher Datenbank.
--
Henryk Plötz
Grüße aus Berlin-
Hi,
ich hab nie gemeint, das des zu viel Ressourcen verbrauchen würde, sondern nur, dass des unübersichtlich wird. Vor allem, weil es ja sowieso nur einen Superadmin geben wird. Und die anderen meinen ja auch, dass einer im Quellcode stehen sollte!
Ja, sicher, bei _einem_ Admin würde ich den in den Quellcode schreiben. Ich persönlich mag die Zero-One-Infinity-Rule(http://www.tuxedo.org/~esr/jargon/html/entry/Zero-One-Infinity-Rule.html) und glaube kaum dass ihr unendlich viele Admins in den Quellcode eintragen wollt. Daher: 1 Admin -> Quellcode, unbestimmte Anzahl -> Datenbank.
Es geht einen Unterschied zwischen Admin und Superadmin. Super-
admins (alle Mitglieder der Assistance4All GbR) sind gleichzei-
tig normale CMS-Benutzer für unseren Auftritt. Kollege Krone und
ich haben uns jetzt darauf geeinigt. Es wird also mindestens drei
Superadmins geben (die Kollegen Krone, Hofmann und ich).
Den Turboadmin werde ich dann im Code verankern ;-)bin grade dabei, ein CMS zu coden. Da soll es einige Superadmins
geben,"Einige" ist mehr als einer, daher Datenbank.
Ja, war ein Mistverständnis. Einer in den Code, die anderen in
die DB.Danke für deine Hilfe,
Peter
-
-
-
Hi!
Zumal: Falls ihr wirklich mal einen GAU habt und jemand es schafft Müll in die User-Tabelle zu schreiben, braucht ihr (nachdem das Skript von der Sicherheitslücke befreit wurde) nicht erst das ganze Backup vom Vortag einspielen und sämtliche Änderungen der Zwischenzeit verlieren oder mühselig die User-Tabellen aus dem Backup rausfischen um sie wiedereinzuspielen, sondern loggt euch über den unveränderten, weil unveränderbaren, Superuser ein und bringt die Tabellen wieder in Ordnung.
Wenn jemand Müll da rein bringt, kann man das dann wohl über die Seite wieder hearusbekommen? Was meint Ihr genau mit 'Müll', sowas wie die Javascripte die Ihr damals in meine DB geschrieben habt? Nur weiß ich nicht auch wenn ich einen Super-Turbo-Mega-sonstwas-Admin gehabt hätte, ob ich das damit überhaupt beheben könnte, wenn das wirklich böser Code gewesen wäre. Zur Not würde ich lediglich diesen Datensatz in PHPmyAdmin löschen.
Oder an was für ein Szenario hast Du da gedacht?Grüße Andreas
-
Moin
Wenn jemand Müll da rein bringt, kann man das dann wohl über die Seite wieder hearusbekommen? Was meint Ihr genau mit 'Müll', sowas wie die Javascripte die Ihr damals in meine DB geschrieben habt? Nur weiß ich nicht auch wenn ich einen Super-Turbo-Mega-sonstwas-Admin gehabt hätte, ob ich das damit überhaupt beheben könnte, wenn das wirklich böser Code gewesen wäre. Zur Not würde ich lediglich diesen Datensatz in PHPmyAdmin löschen.
Oder an was für ein Szenario hast Du da gedacht?Also an Javascript habe ich eher nicht gedacht (ich gehe davon aus dass mittlerweile jeder weiss dass das Böse ist und bei der Ausgabe kaputtgemacht wird).
Ich dachte eher an so Scherze wie DELETE FROM blabla_users; INSERT INTO blabla_users SET name="l33th4ck3r", admin=true, comment="1 0wn y4";
(unabhängig von der darunterliegenden Datenbankstruktur, ich hoffe die Namen sprechen für sich), was man dann ganz einfach wieder beheben kann, wenn man einen Admin hat der auch nach dem DELETE noch geht und der in jedem Fall in der Rechte-Struktur über allen anderen Admins steht.--
Henryk Plötz
Grüße aus Berlin-
OK, verstanden das ist natürlich war! Wobei es glaub ich nicht so einfach ist in MySQL Sachen zu löschen, da immer nur ein Abfrage ausgeführt wird und solange man da keine "Offene Variable" für eine Abfrage stehen hat, durch die eine Abfrage ausgelöst würde... aber man weiß ja nie!
Grüße
Andreas
-
-
-
-
-