Warum braucht es SQLAlchemy?
Kannst du das mit der Rückrelation noch etwas ausführen? Was soll da konkret stehen?jerch hat geschrieben:@meego:
fast richtig - das `id_messages = Column(Integer, ForeignKey('message.id'))` in User macht keinen Sinn, statt dessen ist es sinnvoll, in User 2 (Rück-)Relationen anzulegen - eine für empfangene und eine für gesendete Nachrichten.
@BlackJack: Danke.
EMail Addressen können 254 Zeichen lang sein. Password hash und Salt sollten zusammen in einem String sein, so verhalten sich zumindest alle Hashing Algorithmen die man nutzen kann um sicher Passwörter zu speichern.
@meego: hier mal ein typisches Passwort von django:
Du siehst, es besteht aus mehreren Teilen: Hash-Algorithmus, Iterationen, Salt, Passwort.
Das hat den Vorteil, dass man das Verfahren austauschen kann, um es sicherer zu machen, ohne dass alle Nutzer ihre Passwörter neu eingeben müssen.
Code: Alles auswählen
pbkdf2_sha256$100000$uQnpRoxmZyyM$4YDFEj3nK6MTBrC/7xrrTT1YlDVoueBhd3uptLRPJNc=
Das hat den Vorteil, dass man das Verfahren austauschen kann, um es sicherer zu machen, ohne dass alle Nutzer ihre Passwörter neu eingeben müssen.
Der Salt wird schon in der Tabelle abgelegt bloß nicht in einer eigenen Spalte. Davon abgesehen gibt es ja noch mehr als nur Hash und Salt, wie z.B. Kostenfaktoren. Aufgrund der großen Unterschiede zwischen existierenden Algorithmen und solchen die noch kommen werden macht es keinen Sinn auf soetwas im Datenbankschema einzugehen.meego hat geschrieben:@DasIch: Merci. Aber woher soll der User (bzw. meine Application) beim einloggen den Salt nehmen, wenn er nicht in der Tabelle abgelegt ist?
Hab's hier gesehen:
Link
Also nur ein Feld, wo hinter dem Hash der Salt einfach angehängt und auch von dort ausgelesen wird?
Da stellt sich die Frage, wie die empfohlene Tabelle für Facebook-Logins: remote_source_users (user_id:integer, remote_source_id:string, remote_source:string)
mit meiner users Tabelle zu verknüpfen ist. Wenn sich einer über FB anmeldet wird in remote_source_users ein Datensatz erstellt, aber was passiert in Users? Mir ist das Prinzip nicht ganz klar.
Link
Also nur ein Feld, wo hinter dem Hash der Salt einfach angehängt und auch von dort ausgelesen wird?
Da stellt sich die Frage, wie die empfohlene Tabelle für Facebook-Logins: remote_source_users (user_id:integer, remote_source_id:string, remote_source:string)
mit meiner users Tabelle zu verknüpfen ist. Wenn sich einer über FB anmeldet wird in remote_source_users ein Datensatz erstellt, aber was passiert in Users? Mir ist das Prinzip nicht ganz klar.
@Sirius:
Aber warum müssten die Benutzer bei zwei Feldern das Passwort neu eingeben?
Da fehlt mir der kryptographische Kennerblick.Sirius3 hat geschrieben:@meego: hier mal ein typisches Passwort von django:Du siehst, es besteht aus mehreren Teilen: Hash-Algorithmus, Iterationen, Salt, Passwort.Code: Alles auswählen
pbkdf2_sha256$100000$uQnpRoxmZyyM$4YDFEj3nK6MTBrC/7xrrTT1YlDVoueBhd3uptLRPJNc=
Das hat den Vorteil, dass man das Verfahren austauschen kann, um es sicherer zu machen, ohne dass alle Nutzer ihre Passwörter neu eingeben müssen.
Aber warum müssten die Benutzer bei zwei Feldern das Passwort neu eingeben?
@meego: Du hast in Deinem Design nicht vorgesehen, dass sich der Hash-Algorithmus ändern kann. Vielleicht gibt es andere Algorithmen, die andere Parameter brauchen. Kurz, Dein Design ist unnötig kompliziert und unflexibel.
@sirius: Okay. Hier einmal ein Update:Sirius3 hat geschrieben:@meego: Du hast in Deinem Design nicht vorgesehen, dass sich der Hash-Algorithmus ändern kann. Vielleicht gibt es andere Algorithmen, die andere Parameter brauchen. Kurz, Dein Design ist unnötig kompliziert und unflexibel.
Code: Alles auswählen
class Member(Base):
__tablename__ = 'member'
#Columns for the table user
id = Column(Integer, primary_key=True)
first_name = Column(String(80))
last_name = Column(String(80))
email = Column(String(255), index=True)
street = Column(String(80))
plz = Column(String(40))
city = Column(String(80))
password_salt_hash = Column(String(500))
selfdescription = Column(String(500))
verified = Column(Boolean)
created = Column(TIMESTAMP)
deleted = Column(TIMESTAMP)
Wenn Du Dich damit nicht auskennst, spricht das ganz stark dafür, was Fertiges zu nehmen. Das Problem ist schon zigmal vor Dir gelöst und auf Fehler abgeklopft worden, z.B. in Djangomeego hat geschrieben:...
Da fehlt mir der kryptographische Kennerblick.
Aber warum müssten die Benutzer bei zwei Feldern das Passwort neu eingeben?
Wie man Relationen und deren Rückbindungen erstellt, findest Du in der SQLAlchemy-Dokumentation http://docs.sqlalchemy.org/en/rel_1_0/o ... ne-to-many
Was ist "was Fertiges"? Eine Bibliothek?jerch hat geschrieben:Wenn Du Dich damit nicht auskennst, spricht das ganz stark dafür, was Fertiges zu nehmen. Das Problem ist schon zigmal vor Dir gelöst und auf Fehler abgeklopft worden, z.B. in Django
- noisefloor
- User
- Beiträge: 3857
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
Gruß, noisefloor
Ja - bzw. ein fertiges Framework wie Django. Das hat die Benutzerverwaltung inkl. Gruppen, zugehöriger Methoden und Dekoratoren bereits an Bord. Und das ganze dann auch noch integriert mit einem ORM, Template Engine, Form Framework, URL-Routing usw uswmeego hat geschrieben:Was ist "was Fertiges"? Eine Bibliothek?
Gruß, noisefloor
@meego: Wenn man Django verwendet, dann verwendet man üblicherweise dessen ORM statt SQLAlchemy.
@meego: Ich würde sagen das Django-ORM ist einfacher, aber dafür halt auch nicht so flexibel. Aber weder das noch die Performance ist hier IMHO die Frage sondern ob man Django nutzen möchte oder nicht, denn wenn man Django nutzt, braucht man IMHO schon einen guten Grund nicht dessen ORM zu verwenden sondern etwas anderes was nicht so gut integriert ist. Django ist ein Gesamtpaket bei dem die einzelnen Teile gut ineinandergreifen. SA würde ich da nur nutzen wenn man bereits eine Datenbankanbindung auf SA-Basis hat und die Portierung scheut, oder wenn man bereits eine Datenbank vorliegen hat die sich mit dem Django-ORM gar nicht oder nur mit Mühe abbilden lässt.