Entity-Object muss auf Client aktualisiert werden

[norbertbaum]

Hallo,
ich habe mal wieder ein Problem:

ich habe einen Client
- ich muss mich einloggen(pwd: norbert), also Nutzer - das komplette Nutzer-Entity-Object wird dann auf dem Client gespeichert, da ich es öfters brauch
- jetzt ändere ich mein passwort(pwd: baum), geändertes Passwort wird auch in die DB geschrieben

- jetzt logge ich mich mit einem 2. client und dem geänderten Passwort ein -geht ale sperfekt!

Aber jetzt kommt langsam das Problem:
- auf client 2 ändere ich das Passwort wieder zurück(pwd: norbert)
- wenn ich jetzt auf dem client 1 das passwort ändern will, kommt der Fehler!
da Client 1 hat ja noch als Altes Passwort in seinem Entity-Object "baum", aber es ist ja schon wieder "norbert"

also ist auf client 1 "ein altes entity-object"


Ich hoffe ihr könnt mir folgen!
also kurz gesagt, unterschiedlicher Datenbestand auf den Cients

Lösung?
jedes mal vorher manuell das object vom server holen und gucken ob sich was verändert hat?
oder andere Ideen?


Vielen Dank

 

[maki]

Client - Server

Warum muss der Client Dinge wie das Passwort wissen und halten?

 

[norbertbaum]

es geht um eine Projektverwaltungssoftware (Studienzwecke!)
und wenn ich ein neues Projekt anlege, müsste ich dem sagen, welcher Nutzer es angelegt hat

deswegen halte ich mir das Nutzerobject auf dem CLient, in dem auch das Passwort steht

oder nur die ID halten und dann vor aktionen erst das Entityobject anhand der ID holen?


ich dachte ja JPA macht so was automatisch *keine ahnung hab*


danke

 

[maki]

und wenn ich ein neues Projekt anlege, müsste ich dem sagen, welcher Nutzer es angelegt hat

Das ist ok.

deswegen halte ich mir das Nutzerobject auf dem CLient, in
dem auch das Passwort steht

Das ist nicht ok.

Das Passwort sollte nicht in der Entität mitdrinnen sein imho, aus Sicherheitsgründen.
Das ist eine Seite des Problems.
Die andere:
Anscheinend authentifiziert der Client den Benutzer, das ist grundlegend falsch.
So etwas sollte nur das Backend machen, so was wie ein Service der sich nur um die Authentifizierung kümmert, als Parameter username und pw hat und als rückgabewert ein Client Objekt (ohne pw) zurückgibt, oder eine Exception wirft.

 

[norbertbaum]

naja
ich habe n SessionBean die mein NutzerEnitity verwaltet
dort habe ich n login-Methode
die prüft ob der MD5 wert von der eingabe der selbe ist wie in der DB
wenn ja - NutzerObject zurück geben...

ich meine ist ja allgemein, das ich objekte local auf dem client speichere oder immer nur IDs und dann das aktuelle Object holen?


was passiert wenn 1 kunde von 2clients bearbeitet wird?
- auch ein Fehler...

 

[maki]

>> ich habe n SessionBean die mein NutzerEnitity verwaltet

Na dann ist doch (fast) alles in Ordnung.

WIchtig ist, das deine SessionBean eben nur den Namen und das Passwort als Parameter nimmt, nicht die Entity selbst.

>> was passiert wenn 1 kunde von 2clients bearbeitet wird?
Locking:
http://martinfowler.com/eaaCatalog/optimisticOfflineLock.html
http://martinfowler.com/eaaCatalog/pessimisticOfflineLock.html

 

[norbertbaum]

genau das ich ja das Problem...
ich dachte mir um große Parameterlisten mir zu esparen, das ich immer an die SessionBeans das Komplette Object über gebe und nicht 2Strings

Ich schaue mir dann gleich mal die Links an

also Login über 2Strings machen? und als Rückgabe dann das Nutzerobject? oder nur die ID und dann die ID in der Software speicher und dann immer anhand der ID, immer an der Stelle wo es gebraucht wird, holen?

 

[maki]

>> also Login über 2Strings machen? und als Rückgabe dann das Nutzerobject?

Ja.

Ein Login ist ein Login, ist was spezielles.

Ähnliches gilt imho für Passwort Änderungen, dann braucht der Client das PW (alt und neu) auch nicht speichern, sondern nur durchreichen.

 

[Guest]

okay

ich hatte mir so eine Mühe gemacht, nur Objecte hin und her zuschicken

und beim PWD-Ändern
client oder Serverseitig gucken ob das eingegeben alte-PWD mit dem PWD aus der DB übereinstimmt?

also methode:

public boolean pwdChange(String alt, String neu) //in Session
{
//und dann hier ob altes PWD das selbe ist wie in der DB?
}

 

[norbertbaum]

verdammt net eingeloggt gewesen, also das oben is von mir...

 

[maki]

und beim PWD-Ändern
client oder Serverseitig gucken ob das eingegeben alte-PWD mit dem PWD aus der DB übereinstimmt?

Solche Dinge immer den Server machen lassen.

Stell dir einfach mal vor, du müsstest einen komplett neuen Client schreiben, zB. einen Kommandozeilen Client.

Welche Funktionalität müsstest du nochmals schreiben?
Die Funkionalität gehört dann in den Server.

Zumindest beim Thinclient.

 

[norbertbaum]

OKAY
also kurz gesagt
die daten von der GUI nehmen und an die SessionBean Methoden übergeben...
die ganzen IF-Abfragen etc...alles Serverseitig?

und wie sage ich dem Client ob es geklappt hat oder nicht
also zB der Login
über Exceptions (NutzerNoLoginException)? oder über Boolean?


danke dir für deine ganze Mühe bis jetzt

 

[maki]

>> die daten von der GUI nehmen und an die SessionBean Methoden übergeben

Nur dass wir uns richtig verstehen, Entities sind gar nciht schlecht um Daten zu ändern.
Jedoch ist ein PW ändern ein anderer UseCase als zB ein neues Projekt anlegen oder ein bestehendes ändern.
Deine Services sollten immer grobgranulare Schnittstellen haben und viele Parameter sind nie gut.
Die Anwendungsfälle sollten ziemlich gut anhand der Schnittstellen zu erkennen sein.

>> die ganzen IF-Abfragen etc...alles Serverseitig?
Validierung müssen auf jedenfall Serverseitig gemacht werden, im Client können dann auch noch Validierung stattfinden.
Ist leider mit Redundanz verbunden, dem Anfang allen übels.


Exception vs. Boolean

Könnte man jetzt Diskutieren, im Fehlerfall will man dem User meist den Grund präsentieren.
Auf der anderen Seite sind eigene Exceptions immer mit Aufwand und zusätzlicher Komplexität verbunden.
Manche machen das mit (komplexen) Rückgabewerten, wie einst in C.
Andere behaupten dass Exceptions besser sind.

Denke dass es da auf den konkreten Fall ankommt.

 

[norbertbaum]

das es verschiedene UseCases sind, ist mir klar...

ok ich gucke mal wie weit ich das zeug serverseitig bekomme...

login ist schon serverseitig
jetzt wird nur noch der username und das Passwort als char[] übergeben
der rest passiert in der Methode von NutzerBean
Sollte der Login erfolgreich sein, so wird mir das NutzerObject zurück gebene, wo das Passwort "" ist
das ist doch ok?

sollte der Login fehlschlagen kommt n Exceptionen und diese Exceptionen fange ich auf dem Client und gebe über n JOptionenPane n ausgabe auf dem Client


Validierungen
wir haben zZ das schon validiert wird, wenn man das EditFeld verlässt (InputVerifier) darf das trotzdem auf dem Client bleiben?



mit dem Login habe ich ja jetzt kapiert
aber jetzt noch mal n größeres Beispiel

ich will einen neuen Nutzer eintragen
- InputVerifier greifen schon beim verlassen der felder
- dann hole ich mir über JNDI meine NutzerBean
- neue Nutzer-Object
- schreibe mit den ganzen Setter die Eingaben dort rein
- beim Attribute Gruppe:
- neues Gruppe-Entityobeject
- setName (Gruppenname aus Combobox)
- dann gruppeBean.findByName(gruppe) //damit suche ich mir das Gruppe Entity raus
- ODER hier auch nur einen String mit dem gruppennamen übergeben und dann gruppenobecjt zurück geben?
- dann wird das gruppenObecjt auf nutzer.setGruppe(gruppe) gepackt

- if(username != "" && mail != "")
- try nutzerBean.create(nutzer)
- catch NutzerInsertException - Fehler beim Eintragen....
- else - Vollständig ausfüllen




Ich hoffe das ist jetzt nicht zuviel für n Sonntag
also das Einzige was mir einfällt ist das mit gruppe.findByName(String) auslagern, also nur den String schicken und nicht mit Object...

danke dir