Ich bekomme Flask-Admin nicht gesichert

Django, Flask, Bottle, WSGI, CGI…
Antworten
naheliegend
User
Beiträge: 439
Registriert: Mittwoch 8. August 2018, 16:42

Hallo,

irgendwie bekomme ich meinne flask-admin view (erreichbar unter /admin) nicht mit flask-security gesichert.

Code: Alles auswählen

from flask_security import roles_accepted, current_user
from flask_admin.contrib.sqla import ModelView
(...)
Dann erstelle ich mir eine Klasse. In diesem Fall sichere ich sogar doppelt ab:

Code: Alles auswählen

class RoleAdmin(ModelView):
    @roles_accepted('admin')
    def is_accessible(self):
        return current_user.has_role('admin')

Code: Alles auswählen

admin.add_view(RoleAdmin(Role, db.session))
Das merkwürdige ist, dass ich sogar selbst uneingeloggt die Tabellen in der /admin sehen kann. Es wird zwar angezeigt, dass ich keine permission habe, aber sie erscheinen trotzdem, was nicht gewünscht ist:

Bild


Was mache ich falsch?
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
einfachTobi
User
Beiträge: 491
Registriert: Mittwoch 13. November 2019, 08:38

Ich habe weder Ahnung von flask-admin noch von flask-security, aber es macht den Anschein, dass der Dekorator @roles_accepted dafür da ist Routen zu dekorieren. Du schützt ja jetzt die Funktion is_accessible davor von Nutzern, die nicht "admin" sind, ausgeführt zu werden.
Ich vermute stark, dass @roles_accepted('admin') bei einer Zeile die so oder so ähnlich lautet besser aufgehoben ist:

Code: Alles auswählen

class RoleAdmin(ModelView):
    @expose('/')
    @roles_accepted('admin')
    def admin_menu(self):
        return self.render("admin.html")
Benutzeravatar
noisefloor
User
Beiträge: 3843
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,

es ist zwar keine Antwort auf deine Frage, aber etwas, was mir generell zu deinen ganzen Fragen in den letzten Wochen auffällt:

IMHO solltest du für dich mal überlegen / prüfen, ob du nicht sinnvoller auf Django und seinen ganzheitlichen "batteries included" Ansatz wechselst. Nicht, weil Flask oder SQLAlchemy schlecht sind, aber viele deiner Probleme sind ja das Zusammenspiel der div. Module. Das hast du bei Django nicht, zumindest nicht bei den Modulen, die Djanog OOTB an Bord hast. Und was du machst ist ja unter Strich nichts anders als Flask + Module dahin zu basteln, was Django OOTB bietet.

Gruß, noisefloor
naheliegend
User
Beiträge: 439
Registriert: Mittwoch 8. August 2018, 16:42

Danke für die Hinweise. Ich habe meins jetzt auch zum Laufen bekommen, indem ich den decorator Einach entfernt habe.

Der Ansatz mit dem View ist auch nicht schlecht, aber man müsste für jedes Model, also für jeden Endpoint dann so ein requirement festlegen.

und @noisefloor: Ja, das habe ich jetzt auf die harte tour erfahren dürfen. Entweder bin ich zu dumm zum flasken, oder es ist generell eine Frickelgeschichte. Aber ich habe jetzt alles beieinander und werde das Ganze dann nochmal in Django bauen.
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
Benutzeravatar
noisefloor
User
Beiträge: 3843
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,
Entweder bin ich zu dumm zum flasken, oder es ist generell eine Frickelgeschichte.
Nee, ich denke letzteres. Wenn man X Module an eine Software (wie hier Flask) anflanscht, dann wird es irgendwann komplex. Hatte ich früher auch mal, und ich hatte "nur" Bottle + SQLAlchemy + WTForms. Der Wechsel auf Django hat für mich (als Hobbyprogrammierer) vieles einfacher gemacht.

Du kannst ja für Django alle möglichen Erweiterungen dazu installieren und die Komplexität steigern. Aber basierend auf deinen Fragen kommst du denke ich gut mit dem aus, was Django OOTB kann.

Was das bessere Verständnis ist es aber gar nicht so verkehrt, wenn man sich das erst mal mit Flask + Erweiterungen zusammen fummelt. Hilft ja letztendlich auch z.B. bei Django, wenn man versteht, wie was warum wo zusammen spielt.

Gruß, noisefloor
naheliegend
User
Beiträge: 439
Registriert: Mittwoch 8. August 2018, 16:42

Was halt schade ist, dass irgendwann irgendwelche Erweiterungen nicht mehr maintained werden, wie Flask-Securty und sich dann Leute darauf aufbauend eine neue Erweiterung bauen (Flask-Security-Too).

Oder Flask-Bootstrap und Bootstrap-Flask. Oder es gibt viele Erweiterungen, die irgendwie das selbe können, aber irgendwie auch nicht. Flask-Login, Flask-Security, Flask-Principal, ...


ich bin jetzt mit:
-Flask
-Flask-Security-Too
-Flask-SQLAlchemy
-Flask-Migrate
-Bootstrap-Flask
-Flask-Admin
-Flask-WTF
-Flask-Mail

unterwegs.
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
nezzcarth
User
Beiträge: 1632
Registriert: Samstag 16. April 2011, 12:47

naheliegend hat geschrieben: Sonntag 14. März 2021, 08:22 Was halt schade ist, dass irgendwann irgendwelche Erweiterungen nicht mehr maintained werden
Das Problem hat man in der Softwareentwicklung bei der Auswahl von Komponenten ja generell und in sicherheitskritischen Bereichen wie der Webentwicklung noch mal besonders. Auch bei der Verwendung von Django kommt man meistens nicht komplett ohne externe Pakete aus; das fängt oft schon beim Datenbanktreiber an. Man braucht vielleicht nur weniger davon, als bei einem Framework wie Flask, das stärker auf externe Pakete setzt. Daher ist es aus meiner Sicht wichtig, sich bei der Auswahl von externen Bibliotheken für Webanwendungen vor der Entscheidung immer ein bisschen darüber zu erkundigen, was man sich da "reinholt". Zum Beispiel schaue ich immer darauf, wie lange eine Bibliothek schon existiert, wann es die letzte Änderung gab, unter welcher Lizenz sie steht und wie viele Sterne sie auf Github hat. Das kann natürlich nur als Anhaltspunkt für eine grobe Einschätzung dienen.
naheliegend
User
Beiträge: 439
Registriert: Mittwoch 8. August 2018, 16:42

nezzcarth hat geschrieben: Sonntag 14. März 2021, 12:59
naheliegend hat geschrieben: Sonntag 14. März 2021, 08:22 Was halt schade ist, dass irgendwann irgendwelche Erweiterungen nicht mehr maintained werden
Das Problem hat man in der Softwareentwicklung bei der Auswahl von Komponenten ja generell und in sicherheitskritischen Bereichen wie der Webentwicklung noch mal besonders. Auch bei der Verwendung von Django kommt man meistens nicht komplett ohne externe Pakete aus; das fängt oft schon beim Datenbanktreiber an. Man braucht vielleicht nur weniger davon, als bei einem Framework wie Flask, das stärker auf externe Pakete setzt. Daher ist es aus meiner Sicht wichtig, sich bei der Auswahl von externen Bibliotheken für Webanwendungen vor der Entscheidung immer ein bisschen darüber zu erkundigen, was man sich da "reinholt". Zum Beispiel schaue ich immer darauf, wie lange eine Bibliothek schon existiert, wann es die letzte Änderung gab, unter welcher Lizenz sie steht und wie viele Sterne sie auf Github hat. Das kann natürlich nur als Anhaltspunkt für eine grobe Einschätzung dienen.
Danke für deine Einschätzung.

Das Ding ist, man kann den Leuten ja auch gar nicht böse sein, weil das im Grunde code/Arbeit für free ist und ich selbst das so nie hinbekommen hätte.
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
Antworten