WebService, was darf der Client alles sehen

[Generic1]

Hallo,

ich hätte nochmal eine Frage zu WebServices. Der WebService meiner Applikation bietet alle Methoden um einen Client für meine Applikation zu schreiben, sprich wenn ich die verschiedenen MEethoden des WS aufrufe bekomme ich die verschiedenen Results zurück -> so wie halt eine WS funktionieren soll.

Was ich jetzt machen möchte ist, dass verschiedene User/Clients verschiedene Sachen sehen dürfen.
z.B.: darf User1 einen Button sehen, den User2 nicht sehen darf. Da stell ich mir jetzt die Frage, wie ich das mit einem WS im Backend machen kann.

Mein Ansatz wäre jetzt der gewesen, dass ich in den Objekten, die vom WS zurückgegeben werden, ein Flag hab und je nachdem, ob dieses Flag auf true oder false ist, wird etwas am Client angezeigt oder auch nicht -> ich bin aber leider nicht zu 100% überzeugt von diesem Ansatz,
Wie würdet ihr das machen?

lg
Generic1

 

[Generic1]

Mir würde es auch schon reichen, wenn vielleicht jemand einen Vorschlag in diese Richtung machen könnte, ich weiß nämlich momentan nicht, wie ich das Problem lösen kann.
lg

 

[reibi]

Hi

Möchte vorher wissen um was für einen Webservice es sich handelt ... SOAP-Webservice?
Bist Du derjenige der den Service schreibt, oder nur derjenige der in konsumiert, oder testhalber beides?

 

[Generic1]

Hi

Möchte vorher wissen um was für einen Webservice es sich handelt ... SOAP-Webservice?
Bist Du derjenige der den Service schreibt, oder nur derjenige der in konsumiert, oder testhalber beides?

Also es handelt sich um SOAP-Webservice und ich bin derjenige der die WSDL schreibt, ich hab also grundsätzlich auf alles Einfluss.
Mir ist nur nicht klar, wie ich den Client sagen soll, was dieser Sehen darf und was nicht (wie oben beschrieben -> den einen Button schon, den anderen nicht usw.)

 

[reibi]

Also Du musst eine Authentifizierung einbauen. Serverseitig; der Client darf davon nichts wissen. Wenn ein Client der nicht authentifiziert ist zugreifen will, gibts ne Exception "Nicht genügend Rechte"

Das mit Deinem Button musst DU natürlich im Client lösen.
Kann ich mir Dein Problem ähnlich wie ein CMS vorstellen? Also es gibt "Normale User" und "Admins"?

 

[mvitz]

Du vermischst in diesem Falle zwei Schichten (Service und GUI). Ob der Button angezeigt werden kann/darf/soll ist Sache der GUI und nicht deines Services.

Spontan fallen mir nur eine Möglichkeit ein:
Der User deines Webservices muss sich authentifizieren und ein SecurityToken bei jedem Aufruf mitschicken. Wenn der Aufrufer nicht die passenden Rechte hat, schmeißt dein Webservice eine Exception.

Kombinieren könntest du dann noch eine Methode, mit der jemand abfragen kann, welche Rechte der aktuelle Nutzer hat, bzw. welche Methoden er ausführen darf.

 

[brauner1990]

Könntest du vlt die User in Gruppen zusammenfassen?

Wenn ja, ist dies nur ein einfaches Rechtekonzept wo du sozusagen auf Bereiche Rechte gibst oder nimmst.

Aber grundsätzlich ist es immer eine true - false - Flag abfrage ... sei es jetzt in der Bedinung mit mehreren Möglichkeiten des true/false, aber immer ein if...

 

[Generic1]

>> Kann ich mir Dein Problem ähnlich wie ein CMS vorstellen? Also es gibt "Normale User" und "Admins"?

Ja, so ähnlich, es gibt einen "root", der darf alles und es gibt dann Benutzer, die man in der Applikation anlegen kann und denen kann man dann Privilegien zuordnen.

 

[reibi]

Ich würde es einfach halten: Wie oben besprochen muss Dein Webservice mit dieser Security umgehen und der client sollte darauf reagieren.

Ist der Client ne Webapp oder n FatClient?
Gibt es unterschiedliche Konsumenten(andere Institutionen) oder benutzt Du Webservices nur als Punkt-zu-Punktverbindung(1 zu 1)
Bist Du der einzige der ein Client zum Service baut?

 

[Generic1]

Ich würde es einfach halten: Wie oben besprochen muss Dein Webservice mit dieser Security umgehen und der client sollte darauf reagieren.

Ist der Client ne Webapp oder n FatClient?
Gibt es unterschiedliche Konsumenten(andere Institutionen) oder benutzt Du Webservices nur als Punkt-zu-Punktverbindung(1 zu 1)
Bist Du der einzige der ein Client zum Service baut?

Also ich bin der einzige der einen Client für den WS schreibt und es besteht eine 1:1 Verbindung.
Der Client wird in Adobe Flex programmiert.
lg

 

[reibi]

Also Dein einziger Client kümmert sich ja um das UI, ja

Bau doch in den Webservice eine Methode ein die so aussieht:

zB:
boolean isAdmin(int userID);

Der Webservice prüft "hinten" ab ob es sich um einen solchen handelt oder nicht und liefert Dir true oder false zurück.
je nach dem ob es sich um einen "Normalen user" oder einen Admin handelt baust Du das UI unterschiedlich auf ... Der Aufbau des UI ist ausschliesslich Sache des Clients.

Gruss

 

[Generic1]

Also Dein einziger Client kümmert sich ja um das UI, ja

Bau doch in den Webservice eine Methode ein die so aussieht:

zB:
boolean isAdmin(int userID);

Der Webservice prüft "hinten" ab ob es sich um einen solchen handelt oder nicht und liefert Dir true oder false zurück.
je nach dem ob es sich um einen "Normalen user" oder einen Admin handelt baust Du das UI unterschiedlich auf ... Der Aufbau des UI ist ausschliesslich Sache des Clients.

Gruss

Dieser Ansatz ist etwas schwierig, da ich verschiedenen User anlegen kann und die dann auch verschiedene Rechte haben.

 

[brauner1990]

Dieser Ansatz ist etwas schwierig, da ich verschiedenen User anlegen kann und die dann auch verschiedene Rechte haben.

Welche Rechte "Arten" gibt es den? Nur rwx? Wenn ja wäre ja die Linux Variante / FTP Variante ne gute Lösung. Halt mir Owner, Group, Other und dann Read Write Execute ne gute Idee? dann kannste dir die Dinger sehr Variabel aufbauen. 777, 555, usw., hier (http://thomas-becker.de/chmod.htm#2)ist das Prinzip welche ich meine gut beschrieben.

 

[reibi]

Also was auf jeden klar ist, ist das in den Webservice nur Daten reingehören und nicht Deine UIs oder Teile davon wie Knöpfe.

Webservices wurden eigentlich dafür mal erfunden das es einen anbieter gibt und viele Konsumenten. Der Anbieter kennt seine Konsumenten auch nicht.
Dieses Prinzip wurde dann mit dem großen SOA-Hype ausgehebelt; warum auch immer.// (wahrscheinlich dass Projektleiter mit SOAPUI kucken können was alles über die Leitung geht)
In diesem Umfeld gibt es weniger konsumenten(1 bis wenige abzählbare) und die Ersteller kennen sich auch noch, oder sind eh die selben Personen.
Das ist ja bei Dir auch so ...oder?

Deine Logik wie Du Die UI aussehen lässt, gehört natürlich in den Client und nicht in den Webservice, das ist immer so.
Wie Du Deine Rechte in Zusammenhang mit Deinem Webservice baust gibts mehrere Ansätze
- True/False zurückgeben mit Methode "isAdmin()"
- Exception werfen, mit Message "Nicht genügen Rechte"
- Unterschiedliche Anzahl von Daten zurückliefern
Was da n guter oder schlechter Ansatz ist kommt vor allem auf Dein Projekt an und hängt vom Architekturdesign ab.


Ansätze für mehr als 2 STufen(Admin, Benutzer) wo die Benutzer verschiedenen Gruppen angehören können, kann man zB mit einem LDAP-Server prima realisieren. Weiss nich ob das für Dein Projekt eventuell zu viel wird.

Gruss

 

[Generic1]

LDAP ist sicher zu viel Aufwand, bei mir schauts so aus, dass die User und die Rechte der User in der DB schon gespeichert sind, ich muss das "nur" am Client realisieren, das z.B.: user A das eine sehen darf und user B das eine nicht, dafür aber das andere usw.
Da wird es wohl am besten sein, dass ich jedes mal vor einem WS - Methoden- Aufruf eine Methode "boolean allowed(CurrentUser)" bzw. "String whatIsAllowed(CurrentUser)" aufrufe und zurückgekomme, was dieser User alles darf.
Wie seht ihr das?

 

[reibi]

Da wird es wohl am besten sein, dass ich jedes mal vor einem WS - Methoden- Aufruf eine Methode "boolean allowed(CurrentUser)" bzw. "String whatIsAllowed(CurrentUser)" aufrufe und zurückgekomme, was dieser User alles darf.?

Jep so kannstes machen.
Ich, persönlich, würde es aber folgenderweise machen(anders):

Gründsätzlich:
Der Client weiss auf jeden Fall welche Rollen es gibt zB(normaler User, bereichsChef, Admin SuperAdmin usw.); warscheinlich gibts bei Dir nur 2 Rollen(normaler Benutzer, Admin)

Wenn die Session erstellt wird, würde ich den Webservice fragen, welche Rolle der User hat und damit arbeiten. Die Rolle ist dem client solange bekannt, solange die Session läuft. Ist die Session abgelaufen oder der User meldet sich ab ist auch die (clientseitig gespeicherte)Rolle hinfällig. Meldet sich ein neuer User an, läuft das wieder genau so.

Der Unterschied zu Deiner Variante ist der, dass der client nur einen einzigen Aufruf macht um die Rolle festzustellen; er speichert diese dann zwischen.
So wie ich Dich verstanden habe, würdest Du bei jeder aktion einen Webserviceaufruf machen. Das würde ich vermeiden


Gruss

 

[Generic1]

OK, das hab ich verstanden und klingt auch ziemlich plausibel.
Was ich noch nicht versteh ist, was die Session in diesem Context ist - meinst du damit, dass die Session beim ersten Aufruf des WebService erzeugt wird?
lg

 

[reibi]

Was ich noch nicht versteh ist, was die Session in diesem Context ist - meinst du damit, dass die Session beim ersten Aufruf des WebService erzeugt wird?

Nee mein ich nicht. Ich meine die Session des Clients.

Ist der Client ne Webapp oder n FatClient?

Diese Frage hast Du mir noch nicht beantwortet.
Wenn ich weiss wie das laufen soll kann ichs Dir besser erklären

Gruss ;-)

 

[Generic1]

Der Client ist eine Adobe Flex Applikation, also eine RIA.
lg

 

[reibi]

Ich hab noch nie einen client mit Flex gemacht, aber das läuft über ne Website richtig? Ist also in nem Server drin(Tomcat, Apache 2 ?) Verhält sich somit wie eine Website richtig?

Also immer wenn sich am "FlexClient" ein Benutzer anmeldet(Session wird eröffnet), wird gleich danach die Rolle per Webservice abgefragt und im "Flexclient zwischengespeichert" . Solange der Benutzer am client angemeldet ist, solange speichert der client die rolle. Wenn der Benutzer auf abmelden drückt, ist die Session beendet.