reuse_cookies option did not work for JakartaEE applications

[rsoika]

I am running the Docker image collabora/code:6.4.8.4. I want to use it from a JavaEE/JakartaEE application. My java application uses standard authentication and creates the standard cookie JSESSIONID.

I expected if I set

<reuse_cookies type="bool" default="false">true</reuse_cookies>

this would provide the JSESSIONID cookie in every request the collabora instance sends to my WOPI host. But this is not the case.

For example the url for the WOPI CheckFileInfo request looks like this one:

http://imixs-app:8080/api/wopi/6f003f41-4dd2-4cfb-89fc-ccdd08ca3e30/files/test.odt?reuse_cookies=JSESSIONID%3D0vSvgchueqXN-VV9le4jmg7_rXIMHqDIo2KYkKOC.dec106728a3a

The cookie becomes part of the URL but is not provided in the header. This behaviour seems to be independent form the reuse_cookies option.

Don't wonder why I used in this example no 'access_token' . I removed it to make the URL more clear. I deed I need to work with a custom access_token to secure the communication. But reusing the JSESSIONID would be much more elegant.

To Reproduce Steps to reproduce the behavior:

1. Run a WOPI Host in JakaraEE
2. set the option reuse_cookies=true
3. Provide a JSESSIONID
4. Requests from collabora against the WOPI Host did not include the Cookie in the header

Expected behavior The JSESSIONID should be part of the header and not the URL

Actual behavior The JSESSIONID becomes part the the request URL

[rsoika]

Another issue I observed concerning the cookies is that if I use the access_token, than the cokies will become part of the access_token in the quey string starting with a ? instead of a &

For example the URL from a POST request form the Wopi client looks this:

....wopi/6f003f41-4dd2-4cfb-89fc-ccdd08ca3e30/files/test.odt?access_token=xxxxxxxxxxx?reuse_cookies=JSESSIONID%3D0vSvgchueqXN-VV9le4jmg7_rXIMHqDIo2KYkKOC.dec106728a3a

it should be:

....wopi/6f003f41-4dd2-4cfb-89fc-ccdd08ca3e30/files/test.odt?access_token=xxxxxxxxxxx&reuse_cookies=JSESSIONID%3D0vSvgchueqXN-VV9le4jmg7_rXIMHqDIo2KYkKOC.dec106728a3a

?reuse_cookies

instead of

&reuse_cookies

[kendy]

@rsoika: At some stage, we had an integrator who wanted to do the same thing - reuse the JSESSIONID. But in the end it lead to so much trouble that they retracted the approach, and returned to implementing the access_token without any need for a cookie.

I'd recommend you to do the same; I'm afraid you are on your own with this approach :-( But if you make it to work - patches will be appreciated of course!

[kendy]

@rsoika: Regarding the other problem, I believe it was sorted out just recently by commit 8f4fd370c575c65e62ed4ff6a5f55e3b22c9e33a .

[rsoika]

@kendy : yes the commit https://github.com/CollaboraOnline/online/commit/8f4fd370c575c65e62ed4ff6a5f55e3b22c9e33a is definitely very important! This helps a lot to separate multiple query params wen using Java Jax-RS API - This is perfect!

But as you argued in your first comment, I came to the same result. The reuse of the JSESSIONID generates other problems (e.g. multiple Browser Tabs with the same document opened)

So I agree with your recommendation to use a session/view specific unique access token. It makes the integration with JakartaEE more robust

1. JakartaEE Web App generates its own User/Session specific JSESSIONID (as usual)
2. The Web App generates a view/browser-tab unique access token for the current user (we generate a JWT with userid and user display name in a conversation scoped CDI Bean)
3. The access token is transferred to the Wopi Client as recommanded
4. Each POST request form the Wopi Client includes the access token in the query String (currently with the ugly additional cookie params)
5. The Web APP can store the document data distinct to the specific user Session/Page-View
6. The CDI Frontend Controller can access the document data in the current conversation scope

I have documented the solution in our wopi-adapter project on github.

I always searched for a simple solution but now I must admit that also my solution is not obviously for a new comer. I tried to give an integration example in my blog. Maybe this can help some others community members.

[rsoika]

@kendy : can you please take a look at my new issue #2380 ? After investing several hours I think the reuse_cookie topic affects more parts.

I wonder why NextCloud/OwnCloud did not stumble into this issue?