Hi Ivy Team, Is there a way to get the JSESSIONID (or the whole cookie itself) of the logged in user ? I want to build a rest method which is authenticating the user. I need to return the cookie, so that next requests are authenticated BR, Yordan asked 30.09.2019 at 03:58 Stelt0 |
Hi Yordan I can now reproduce your problem and see your use case! I think we have a bug there because on login we change the session id and we then do not map the correct session. As workaround you could disable RenewIdOnLogin like this in ivy.yaml:
With the follwowing code you can get the current http session id:
answered 09.10.2019 at 05:05 SupportIvyTeam ♦♦ Hi, Can I test this on the Designer ? Is it equivalent if I configure it in app-designer.yaml ? if I set log the getHttpSessionIdentifier and getSessionUserName in the two requests I get again the same behavior Ivy.log().info(Ivy.request().getSession().getHttpSessionIdentifier()); Ivy.log().info(Ivy.session().getSessionUserName()); BR, Yordan
(09.10.2019 at 09:19)
Stelt0
Do it directly in ivy.yaml in the configuration folder, yes this should also work in designer.
(11.10.2019 at 05:32)
SupportIvyTeam ♦♦
|
Hi Reguel, I was able to add Authorization Basic header before ApplicationSessionRequestFilter. In result, the session of the user was changed based on this header. However, the returned cookie form this request, is still not valid for the next calls ... ) the second call is authenticated as Developer) I assume that this is a bug. Here how you can reproduce it:
html:
BR, Yordan answered 07.10.2019 at 06:25 Stelt0 Reguel Werme... ♦♦ Hi Yordan. Glad to hear on your success on providing a custom request filter to transform headers. Currently I do not have the time do drive further analysis why the session is not overtaken. But I'm confident that you can find the cause quickly by using a class decompiler + debugger to analyse the execution of our ApplicationSessionRequestFilter. The tracing on which terms the existing session are overtaken should be easy to see in there. If nothing works. You could try to handle the issue in a global tomcat Valve : which is in charge not only for the rest stack, but for the whole webserver.
(08.10.2019 at 03:56)
Reguel Werme... ♦♦
Some documentation to start with valves can be found here : https://developer.axonivy.com/doc/latest/engine-guide/integration/web-application-firewall.html
(08.10.2019 at 03:57)
Reguel Werme... ♦♦
|
If setting up a BASIC_AUTH header on client side is the main issues I think it should be possible to solve this in an additional Currently auth and session handling is done in : The request filter comes with a priority (in this case: 1'000). Therefore, it should be possible to provide an additional request filter that can change the request just before the default filter is executed. Your custom filter could compensate the inabilities of the real client > transform form params into http_basic auth headers. To setup your custom filter as general extension for the ivyEngine REST stack you have to add the ...just an idea: I did not check it with an example. PS: be aware that big improvements from 7.4 REST stack have been ported back to the 7.0 LTS train recently. So ensure that you work with the latest hotfix version to benefit of the extension capabilities mentioned here. answered 04.10.2019 at 02:11 Reguel Werme... ♦♦ Hi Reguel, It BR, Yordan
(04.10.2019 at 09:36)
Stelt0
|
Once you sign in you will be able to subscribe for any updates here
By RSS:Markdown Basics
Tags:
Asked: 30.09.2019 at 03:58
Seen: 6,757 times
Last updated: 11.10.2019 at 08:05
If the client is in the browser the JSESSIONID works for both the web and the rest stack. But this is transparent and you have nothing to configure. Generally it is not possible to get the JSESSION cookie, this would be a security risk. But that I can give you a concrete answer you have to explane exactly what is your usecase...
If you design the API to only allow normal users : the login will automatically be done based on the HTTP_BASIC auth headers. What value do you have if you can enforce to send it as POST and handle auth on your own?
Hi Reguel,
The client application (browser) cannot be modified to send basic auth header. it sends user and password and It works only with cookie after that.
And the problem I have with Axon.Ivy is that if a REST method has @PermitAll it automatically creates a session and the returns a cookie for this session (and not for the user which I`m trying to login)
Basically, the question is -> How to do a REST method which is login a user and returns back cookie for for it
BR, Yordan