Answers to: REST API and JSESSIONID

Comment by SupportIvyTeam on SupportIvyTeam's answer

SupportIvyTeam — Fri, 11 Oct 2019 05:32:11 -0400

Do it directly in ivy.yaml in the configuration folder, yes this should also work in designer.

Comment by Stelt0 on SupportIvyTeam's answer

Stelt0 — Wed, 09 Oct 2019 09:19:24 -0400

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

Answer by SupportIvyTeam

SupportIvyTeam — Wed, 09 Oct 2019 05:05:09 -0400

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:

Session:
  RenewIdOnLogin: false

With the follwowing code you can get the current http session id:

Ivy.request().getSession().getHttpSessionIdentifier();

Comment by Reguel Wermelinger on Stelt0's answer

Reguel Wermelinger — Tue, 08 Oct 2019 03:57:12 -0400

Some documentation to start with valves can be found here : https://developer.axonivy.com/doc/latest/engine-guide/integration/web-application-firewall.html

Comment by Reguel Wermelinger on Stelt0's answer

Reguel Wermelinger — Tue, 08 Oct 2019 03:56:12 -0400

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.

Answer by Stelt0

Stelt0 — Mon, 07 Oct 2019 06:25:30 -0400

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:

create project myapp with two REST endpoints (require authentication) (/ivy/api/myapp/loginCall and /ivy/api/myapp/checkCurrentUser); in both of them just log Ivy.session().getSessionUserName()
create user -> allan:allan
add this code snippet as index2.html and place it in \AxonIvyDesigner7.4.0\webapps\ivy
test it on http://localhost:8081/ivy/index2.html (clean cache/session first)

html:

<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Test</title>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js"></script>
<script>

    function loginCall() {
    var authToken = btoa('allan:allan'); //user and passowrd

    return $.ajax({
      url: "/ivy/api/myapp/loginCall",
      type: 'GET',
      headers:{
            'X-Requested-By': 'myapp',
            'Content-Type':'application/json',
            'Authorization': 'Basic ' + authToken
        },
      dataType: 'json'
    });
  }

  function checkProfile() {

    return $.ajax({
      url: "/ivy/api/myapp/checkCurrentUser",
      type: 'GET',
      headers:{
            'X-Requested-By': 'myapp',
            'Content-Type':'application/json'
        },
      dataType: 'json'
    });
  }

  $(document).ready(function() {

      loginCall()
      .done(function() {
        checkProfile()
          .done(function(response) {

          }).fail(function() {

          });
      }).fail(function() {

      });


  });

</script>
</head>

<body>
check F12
</body>

</html>

BR, Yordan

Comment by Stelt0 on Reguel Wermelinger's answer

Stelt0 — Fri, 04 Oct 2019 09:36:59 -0400

Hi Reguel,

Its an excellent hint! Ill try it out and will let you know.

BR, Yordan

Answer by Reguel Wermelinger

Reguel Wermelinger — Fri, 04 Oct 2019 02:11:02 -0400

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 ContainerRequestFilter for the IVY Rest stack.

Currently auth and session handling is done in : ch.ivyteam.ivy.webserver.internal.rest.security.ApplicationSessionRequestFilter

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 @Provider annotation on the class body. See https://answers.axonivy.com/questions/3412/how-can-i-use-jax-rs-containerrequestfilter-responsefilter-for-my-jax-rs-resources

...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.

Comment by Stelt0 on Stelt0's question

Stelt0 — Thu, 03 Oct 2019 10:41:59 -0400

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

Comment by Reguel Wermelinger on Stelt0's question

Reguel Wermelinger — Thu, 03 Oct 2019 10:14:35 -0400

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?

Comment by SupportIvyTeam on Stelt0's answer

SupportIvyTeam — Tue, 01 Oct 2019 08:14:14 -0400

Means this code runs on the proxy? I do not see your complete use case. How do you share then the JSESSION Cookie with the browser? Please share Code as Text and not as Image, thanks.

Comment by SupportIvyTeam on Stelt0's question

SupportIvyTeam — Tue, 01 Oct 2019 02:47:58 -0400

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...