[KT2L] Das mit Vaadin UI und der HTTP Session

Eigentlich sollte bei einem Refresh im Browser alles weggeworfen werden und es fängt von vorne an. Das ist so auch der Standart wenn man Vaadin nutzt. Genauer wird sogar bei Wechsel der Seite (Routing) immer alles neu geladen. Navigierst du zurück, ist alles weg. Nachteil des Verhaltens ist, dass man keine echte Anwendung bauen kann in der der Status einer Seite, die gerade nicht zu sehen ist, bestehen bleibt. Blöd wenn man z.B. ein Log oder zwei Logs laufen hat und dann mal was anderes schauen will. Huch, Log weg.

Deshalb wurde bei KT2L auf die Fähigkeit verzichtet die Session `serializable` zu halten und somit stateless auf mehreren Instanzen bereit zu stellen: Einmal an einer Instanz angemeldet, musst du dort auch bleiben, sonst ist deine Anwendung weg. Vorteil: im Hintergrund kann die Anwendung schön weiter arbeiten, Logs und Events sammeln,  damit die Ansicht aktuell bleibt.

Solange im Browser nicht 'Refresh' gedrückt wird ist alles gut. Leider hat sich der Teil mit dem Refresh auf der aktuellen Seite auch als problematisch herausgestellt. Im Grunde wird bei jedem Refresh die Session und die Vaadin UI neu erstellt. Bei schwachen Verbindungen kann da schon mal ein Refresh passieren, ohne das man das will. Schwups Anwendung beendet und von vorne.

Zum Glück kann man das umstellen und die Session bei einem Refresh wird nicht mehr gelöscht. Aber auch das hat seine Haken. Denn die Vaadin UI wird schon gelöscht und eine Neue erstellt. Das bedeutet bei jedem Refresh wird jede Referenz auf das UI-Objekt ungültig. Es werden Events geworfen für `Detatch` und `Attach` der UI. Und bei `Detach` können nun auch die Ressourcen (z.B. Log-Watch)  nicht mehr freigegeben werden.

Aber alles halb so schlimm. Wichtig: Bei jeder Aktion, immer, die UI neu holen. Leider kann es passieren das die UI gerade ungültig ist. ggf. sollte das noch abgefangen werden. 

Leider läuft die HTTP Session normalerweise so 180 Minuten.  Wenn im Hintergrund jede Menge Resourcen für die Anwendung gebraucht werden kann das ein Problem werden. Deshalb muss die HTTP Session auf eine viel kürzere Zeit, z.B. 10 Minuten reduziert werden.

Doch jetzt das nächste Problem in der Kette: Ist der User 10 Minuten inaktiv stirbt die aktuelle HTTP Session. Und nun? Die Lösung ist eine Session-Timeout-Benachrichtigung. Sie wird 60 Sekunden vor dem Ende der HTTP Session aktiv und zeigt einen Dialog an 'Achtung die Session läuft gleich ab ...'. Und wenn der Dialog het einen 'Session verlängern' Knopf. Erscheint die Nachricht kann mit JavaScript im Browser der Knopf automatisiert aktiviert werden und so wird die Session automatisch verlängert.

Diese Lösung ermöglicht es die Session zu behalten solange die Anwendung im Browser offen ist und der Browser auch reagiert (z.B. der Rechner nicht eingeschlafen ist). Ausserdem werden Resource innerhalb von 10 Minuten weggeräumt, ist der user nicht mehr da. Und es wird immer wieder kurz ein Dialog angezeigt, wenn der User die Anwendung nicht mehr Bedient. 

Problem gelöst!

Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Sonatype Nexus fails with random "peer not authenticated" errors behind ingress

 After installing nexus3 server in a kubernetes environment in the first view everything looks good. Server is running an accessible from the world. Users and roles are defined and working. But already in the first hours of working with the repository there are problems. The trick was retry the failed activity and everything went ok. It turned out that heavy activities failed a lot of times and a lot of retries have to be done to finish the tasks. Annoying if a release deploy failed. You need to increase the version number every time. There were a few support in the internet for the problems most of the time handling SSL problems between maven and nexus. But it did not fix the problem. It looks like maven and the used http library wagon have got problems with pooled connections if using ingress (a test with a standalone installation did not show the problem)  - The 'deep' reason is not really clear for me, need to invest more time for it. The solution is to deny wagon to use p...
Mehr anzeigen

[mhus lib] Reorg in generation 7 nearly finished

 The generation 7 shows massive reorganisations and reimplementations. After renaming repository names (moved the 'cherry' prefix to 'mhus') the reorg is finished and the sources are ready for a more stable generation 8. Generation 8 will add new features to work with none OSGi services in cloud environments. Actual changes: cherry-reactiive -> mhus-reactive cherry-vault -> mhus-vault cherry-web -> mhus-web mhus-osgi-cluster -> mhus-cluster
Mehr anzeigen

[mhus lib] Implemented Bearer JWS tokens

 mhus now supports bearer tokens for authentication. I used the project jjwt to implement the tokens and added dependencies of the current version 0.11.2. The token is implemented to be used with apache shiro. A new service JwtProvider implements creation and reading of the tokens. The keys if not exists will be created and stored in the keychain. Private and public keys in separate key sources. In this way the public keys can be published to other nodes. A new interface BearerRealm must be used to mark realms with Bearer support. Using the interface a token can be created from the realm implementation. You should use the AccessUtil to create tokens. The authentication is already implemented in rest and micro calls. Via rest a node '/jwt_token' can be used to create a token - expires after one hour - and use it as authentication. To use jjwt with osgi I as forced to create a port project. First the 'feature' character of the bundles is not supported in the current felix...
Mehr anzeigen