Das deutsche Python-Forum

Und bei `Messages` fehlt der Tabellenname.

Würde vorschlagen recht früh unittests schreiben. Dann sieht man schnell ob das Modell stimmt.

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.

Kannst du das mit der Rückrelation noch etwas ausführen? Was soll da konkret stehen?

@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.

@DasIch: Merci. Aber woher soll der User (bzw. meine Application) beim einloggen den Salt nehmen, wenn er nicht in der Tabelle abgelegt ist?

@meego: hier mal ein typisches Passwort von django:

Code: Alles auswählen

pbkdf2_sha256$100000$uQnpRoxmZyyM$4YDFEj3nK6MTBrC/7xrrTT1YlDVoueBhd3uptLRPJNc=

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.

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?

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.

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.

@Sirius:

Sirius3 hat geschrieben:@meego: hier mal ein typisches Passwort von django:
Code: Alles auswählen
pbkdf2_sha256$100000$uQnpRoxmZyyM$4YDFEj3nK6MTBrC/7xrrTT1YlDVoueBhd3uptLRPJNc=
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.

Da fehlt mir der kryptographische Kennerblick.

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.

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.

@sirius: Okay. Hier einmal ein Update:

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)

meego hat geschrieben:...
Da fehlt mir der kryptographische Kennerblick.
Aber warum müssten die Benutzer bei zwei Feldern das Passwort neu eingeben?

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

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

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

Was ist "was Fertiges"? Eine Bibliothek?

Hallo,

meego hat geschrieben:Was ist "was Fertiges"? Eine Bibliothek?

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 usw

Gruß, noisefloor

Aber ich denke, erst muss einmal das Datenbankdesign stehen.

@meego: Django hat schon eine Nutzerverwaltung integriert. Da müßtest Du also die User-Tabelle nur noch um die Felder erweitern, die Deine Member-Tabelle zusätzlich hat.

Sirius3: Hm. Und wie binde ich den ganzen Rest der DB an die an? Momentan würde ja nur SQLAlchemy die DB erzeugen.

@meego: Wenn man Django verwendet, dann verwendet man üblicherweise dessen ORM statt SQLAlchemy.

@BlackJack: Verstehe. Und was sagen Leute die beide ORMs kennen? Was performt besser? Was ist einfacher?

@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.

Das deutsche Python-Forum

Warum braucht es SQLAlchemy?

Re: Warum braucht es SQLAlchemy?

Re: Warum braucht es SQLAlchemy?

Re: Warum braucht es SQLAlchemy?

Re: Warum braucht es SQLAlchemy?

Re: Warum braucht es SQLAlchemy?

Re: Warum braucht es SQLAlchemy?

Re: Warum braucht es SQLAlchemy?

Re: Warum braucht es SQLAlchemy?

Re: Warum braucht es SQLAlchemy?

Re: Warum braucht es SQLAlchemy?

Re: Warum braucht es SQLAlchemy?

Re: Warum braucht es SQLAlchemy?

Re: Warum braucht es SQLAlchemy?

Re: Warum braucht es SQLAlchemy?

Re: Warum braucht es SQLAlchemy?

Re: Warum braucht es SQLAlchemy?

Re: Warum braucht es SQLAlchemy?

Re: Warum braucht es SQLAlchemy?

Re: Warum braucht es SQLAlchemy?

Re: Warum braucht es SQLAlchemy?