Konzeptfrage zu App-übergreifenden Login

Ich erstelle derzeit für unseren Verein eine Appübergreifende Corporate Anwendung. Sprich ein Teil besteht aus einer Desktop App und ein Teil aus einer Web App.

Die Desktop App will ich in C#.NET mit WPF programmieren und die Web App werde ich wohl vorübergehend in PHP proggen.
Nun, da ich die Membership Struktur mit ihren Vorteilen nutzen will, stellt sich mir nun die Frage ob ich den vorhanden MySqlMembershipProvider aus der MySql.Web.dll nutze und meine Apps an dieses DB-Schema anpasse, oder mir einen eigenen McnMembershipProvider schreibe der eine von mir benutzerdefinierte Schemata nutze.

Was würdet ihr vorschlagen?

Original von TheDarkRose

Ich erstelle derzeit für unseren Verein eine Appübergreifende Corporate Anwendung. Sprich ein Teil besteht aus einer Desktop App und ein Teil aus einer Web App.

Also ein Client und ein Server.

Die Desktop App will ich in C#.NET mit WPF programmieren und die Web App werde ich wohl vorübergehend in PHP proggen.

Warum PHP und nicht Client sowie Server mit .NET machen? Das hätte doch Vorteile bezüglich der Kommunikation oder der gemeinsamen Nutzung von Bibliotheken.

Nun, da ich die Membership Struktur mit ihren Vorteilen nutzen will, stellt sich mir nun die Frage ob ich den vorhanden MySqlMembershipProvider aus der MySql.Web.dll nutze und meine Apps an dieses DB-Schema anpasse, oder mir einen eigenen McnMembershipProvider schreibe der eine von mir benutzerdefinierte Schemata nutze.

Was würdet ihr vorschlagen?

"MySqlMembershipProvider" und "MySql.Web.dll" klingt nach .NET, was ihr nur beim Client einsetzen wollt. Heißt das der Client soll direkt mit der Datenbank kommunizieren und nicht mit dem Server? Wofür gibt es dann einen Server?

Ich würde dir vorschlagen den Aufwand abzuwägen. Ist es aufwendiger das Schema anzupassen oder einen MembershipProvider zu schreiben? Wenn nicht letzteres mit größerem Unterschied einfacher ist würde ich immer dazu tendieren meine Anwendungen so anzupassen, dass sie mit fertigen Lösungen zusammen funktionieren.

Nein, es sind ein Desktop Client und ein Web Client die direkt mit der DB kommunizieren. Fürs Web muss ich PHP verwenden, da ich keinen ASP.Net Server zur Verfügung habe.

Und wie regelst Du den Zugriff aus der Desktop Variante sicherheitstechnisch? Gibt es da so etwas wie virtuelle User in der Datenbank mit angepassten Zugriffsberechtigungen? Und alles ueber vordefinierte Views und Stored Procedures? - ich weiss nicht was und ob dergleichen ueberhaupt moeglich ist. Oder hast du das Thema Sicherheit bislang einfach ignoriert?

Direkten Datenbankzugriff mit den gleichen Berechtigungen fuer alle User in den Client zu packen waere jedoch absolut fatal... ausser eben, ist es read only.

Also für den MySQLMenbershipProvider habe ich einen eigenen User, der steht dementsprechend im ConnectionString.

Für die Benutzer wollte ich schon jeweils auch einen eigenen MySql Benutzer anlegen, mit den mindest rechten. Wie meinst du das mit den Views und Stored Procedures?

Naja wenn du einem User Zugriff auf eine Tabelle gibst, gibst du ihm ja Zugriff auf saemtliche Eintraege in der Tabelle... Wie regelst du, dass er nur sehen kann, was er sehen soll und nur schreiben kann, was er schreiben soll? Du kannst zwar in Mysql userbezogene Rechte verteilen, aber die feinste Granularitaet ist auf Tabellenbasis oder?

Du gibst uns ja keine Details ueber die Art deiner Applikation, daher kann man nur grob raten, aber in den meisten Beispielen, die mir in den Sinn kaemen, ist es ein Risiko und ziemlich fatal direkten Zugriff auf die Tabellen zu haben.

Ich hab keine Ahnung was ein "MembershipProvider" ist ;) Ist mir auch egal, es klingt nur insgesamt sicherheitstechnisch ziemlich kritisch. Aber das haengt natuerlich davon ab, was genau das Programm eigentlich tut und was in der Datenbank steht.

Stichwort: Views.

Stichwort: alles lesen.

Deshalb hab ich ja vorher schon von Views gesprochen. Aber Views speichern keine Daten, oder? Und ich frage mich schon wie lang das Ganze managebar bleibt.

Was ich eigentlich sagen will: Ausser in besonderen Ausnahmefaellen ist es imho nicht sinnvoll direkten Datenbankzugriff fuer die User zu erlauben. Da sollte irgendein Service zwischenhaengen.

Original von Kallisti

Du gibst uns ja keine Details ueber die Art deiner Applikation, daher kann man nur grob raten, aber in den meisten Beispielen, die mir in den Sinn kaemen, ist es ein Risiko und ziemlich fatal direkten Zugriff auf die Tabellen zu haben.

Es soll ne App werden, die die Mitglieder, Projekte und das Materiallager eines Verein verwaltet.

Weshalb ist den der direkte Zugriff auf die Datenbank so kritisch?

Normalerweise hast du Einschränkungen, welche Daten welcher Benutzer bearbeiten darf. Bei Browsergames sollte z.B. jeder Benutzer nur seine eigenen Benutzerdaten bearbeiten oder sehen (alleine schon des Datenschutzes wegen). AFAIK kann allerdings kein DBMS die Zugriffsrechte auf kleinere Granulate als Tabellen geben (d.h. du kannst nur sagen, dass User X Tabelle Y lesen & schreiben darf, dann aber komplett und nicht nur einzelne Datensätze).

Wenn du den DB-Zugriff direkt vom Client aus regelst, loggt sich der Client auch direkt in die DB ein (d.h. User und Passwort müssen auf dem Client gespeichert werden). Mit ein wenig Suchen bekommt man diese Daten schnell raus und dann kann jemand mit ein wenig krimineller Energie eine ganze Menge Unsinn machen, weil er sich dann die SQL-Statements ja selbst ausdenken kann.

Generell gilt im Web: Alles was vom Client kommt ist böse und muss auf Validität gepfüft werden. Bei der direkten Kommunikation des Clients mit dem Persistenzspeicher ist diese Prüfung unglaublich kompliziert bis gar nicht möglich. Dabei ist egal, ob der Client nun ein Browser oder eine Standalone-Anwendung ist.

Ich finde, der Client sollte doof sein. Er fragt einen Server ab, und der gibt ihm das Ergebnis (XML? JSON? MirEgalWie?) zurück. Der Server regelt die Sichtbarkeiten - und der Client hat zu keinem Zeitpunkt Zugriff auf sicherheitsrelevante, aber für ihn unerlaubte Daten. Im übrigen könnte man auch überlegen, bestimmte Dinge über SSL zu erledigen - ich denke da an Zahlungsdaten wie Kreditkarte/Kontonummer..

Der ConnectionString ist im Programm verschlüsselt gepseichert.

Die beschränkung im Programm selbst kann ja nicht umgangen werden.

Original von knalli

Ich finde, der Client sollte doof sein. Er fragt einen Server ab, und der gibt ihm das Ergebnis (XML? JSON? MirEgalWie?) zurück. Der Server regelt die Sichtbarkeiten - und der Client hat zu keinem Zeitpunkt auf sicherheitsrelevante Daten. Im übrigen könnte man auch überlegen, bestimmte Dinge über SSL zu erledigen - ich denke da an Zahlungsdaten wie Kreditkarte/Kontonummer..

Ja nur ist das mit dem Server realisieren etwas blöd. Sind dann wieder zwei unterschiedliche APIs - sprich in unteschiedlichen Sprachen programmiert.

Und WCF kann ich leider nicht verwenden da in Mono nicht unterstützt.

Original von TheDarkRose

Der ConnectionString ist im Programm verschlüsselt gepseichert.

Die beschränkung im Programm selbst kann ja nicht umgangen werden.

Und? Wenn es verwendet werden soll, muss es auch entschluesselt werden koennen. Insofern nur Security by Obscurity, also wertlos.

Original von knalli

Ich finde, der Client sollte doof sein. Er fragt einen Server ab, und der gibt ihm das Ergebnis (XML? JSON? MirEgalWie?) zurück. Der Server regelt die Sichtbarkeiten - und der Client hat zu keinem Zeitpunkt auf sicherheitsrelevante Daten. Im übrigen könnte man auch überlegen, bestimmte Dinge über SSL zu erledigen - ich denke da an Zahlungsdaten wie Kreditkarte/Kontonummer..

Ja nur ist das mit dem Server realisieren etwas blöd. Sind dann wieder zwei unterschiedliche APIs - sprich in unteschiedlichen Sprachen programmiert.

Und WCF kann ich leider nicht verwenden da in Mono nicht unterstützt.

Tjo, du kommst aber um einen Webservice nicht herum. Alles andere waere wirklich grob fahrlaessig. Wenn du dir nicht den entsprechenden Server leisten moechtest, laeuft das eben auf zwei Sprachen hinaus - die du ja fuer den webclient eh braeuchtest.

Wieso sind zwei APIs "sprich zwei unterschiedliche Sprachen"? Und wieso überhaupt 2 Apis? Wie wäre es mit einem Webservice (ähm, ich habe keine Ahnung, ob es sowas schon fertig in Mono gibt, würd mich aber wundern, wenn nicht)?

SOAP ist in Mono integriert. Das habe ich letztens gerade auch nachgeschaut. Wenn er allerdings seine Webanwendung in PHP schreiben will, ist es doch schöner auch den Webservice in PHP zu schreiben. Wenn man die Browser- und Webservice- Schnittstelle schön aufeinander abstimmt, kann man sicher einen großen Teil des Codes für beides verwenden.

Was spricht denn gegen CGI, oder vielleicht sogar einem eingebetteten Webserver? Dann kann er die Serverseite (Webanwendung und Webservice) auch ohne asp.net komplett in C# schreiben.

> Und WCF kann ich leider nicht verwenden da in Mono nicht unterstützt.

Evtl mit dem Mono-Unterprojekt 'olive' ?