![]() > Hotkey 'Enter' for Formattedfield in GridHeader But it doesn't get called when the tab is closed or when the browser is closed/killed, correct? You don't get that. (.question via mail - answered through forum.) HttpSessionListenerDelegator is called when the session is closed (e.g. The dialog session provides corresponding listeners for getting notified when it is closed. The "Dialog Session" is an abstraction - which internally maps to the http-session in "URL"-tracking scenarios and which internall maps the the internal dialog session on "COOKIE"-tracking scenarios. And just as side info: please always use the "Dialog Session" if you want to refer to the "session of the tab". (Why is it not closed "with the last brower tab"? Because the jsessionid-cookie remains on client side - so any new tab would again reference the http-session). The dialog session is closed when closing the tab. When using session mode "COOKIE": Then several browser tabs share the same http session - each browser tab belongs to one internal dialog session. In this case the listener is called when closing the tab. When using session mode "URL": Then one browser tab is associated with one http-session. > HttpSessionListenerDelegator - when called Or how can I throw out an http session without the client wanting to reload immediately? For example: HttpSessionAccess.getCurrentDialogSession().invalidate("/logout") Understandable? Is there any way we can do this with existing resources? Do we have to somehow pack this into two round trips. What it would take would be to invalidate the http session and redirect to our logout URL. The invalidate leads to a reload of the client and ignores other triggers/actions in this round trip!? That's why our logout doesn't work. The trigger doesn't trigger and I suspect because of the invalidate. HttpSessionAccess.getCurrentDialogSession().invalidate() The code with the trigger for the component looks like this Code: We called this logout via a clientredirecturl component on the workplace.jsp (this is the layer below our outermost JSP). Spring then makes a call to the identity provider. To log out of the SAML identity provider, we use spring with the endpoint /logout in our own context. We just want to install the SAML logout and encounter a "flow problem". (.from mail request that is responded through the forum) We are currently rebuilding our SAML implementation. Of course invalidating the http session will also affect other browser tabs that are started in parallel to the one that you start the invalidation from. In the closing of the dialog session you embed the code to close the http-session (I assume you work with session-tracking "COOKIE", so there is a http session spanning one or more browser tabs, and there is one dialog session per browser tab. Due to the re-direct the client will notify the server that the current dialog session (the one that belongs to your browser-tab) is closed. You send the redirect in a valid session. HttpSessionAccess.getCurrentDialogSession().addListener(new void reactOnClosed() Public void onButtonAction( event)įinal HttpSession sessionToBeClosed = HttpSessionAccess.getCurrentHttpSession() > Redirect to other page for logout + invalidate session Would it be possible to include this header in the first request? Only in the further requests are the response headers also filled with the eclnt-httpsessionid. We would also like to use load balancing, but we noticed that the session ID is only directly in the HTML for the first response Code: (.copied from mail request, which is responded through the forum.) We are currently working on the migration from docker to kubernetes. > Response header parameter "eclnt-httpsessionid" Please also consider the usage of COOKIE based session tracking, then load balancers have no problem at all. In general load balancers automatically use the session-id also in the case of URL-based session-trackig. The change is available withn this week's update (somewhere this later afternoon). ![]() we did add the header parameter also for the ".risc" request which starts the client processing. ![]() Super(dispatcher) // Response header parameter "eclnt-httpsessionid" Public Xxx(IWorkpageDispatcher dispatcher) Public class Xxx extends WorkpageDispatchedPageBean Hi Marcel, the dispatcher that you pick from. Is it possible that the session is closed by session timeout (web.xml definition of duration.)? This also is in hamorny with "happends randomly". You are working with the top-dispatcher, so the only chance that this one is destroyed is, that the session is closed. Hi Marcel, yes, the destroy method is the only one to set it back to "null". > WorkPageDispatcher returns null WorkpageContainer Enterprise Client Community Search Recent Topics Member Listing Back to home page Register / Login
0 Comments
Leave a Reply. |