Problems with cookies for persistence and services

[bwallis42]

We are running a recent build of 2018.1 but this was also the case in 2017.2.
We are running Orbeon and our persistence layer and other services in the
Wildfly 11 application server which utilises Undertow for the servlet
container, not Tomcat (and all running with Java JDK 8)

We are having authentication issues with our persistence layer calls and
with REST calls for HTTP Services within forms.

We have the following setting in our properties-local.xml



which is required for authentication to work for our persistence layer
implementation and also for calling services from within the forms.

The problem we are seeing is that we are getting two cookie headers in the
requests and also invalid values in the cookie headers.

According to RFC 6265


When orbeon calls our persistence layer we are seeing two cookie headers
like this (this is from the Wildfly server logging but we have verified this
using wireshark)



There are two JSESSIONID cookies and they are not the same value which
doesn't make sense to me.

and when an HTTP service from within the form is called we see either a
single header like this



or sometimes two cookie headers one of which has the second two cookies in
it.

Both these scenarios have two JSESSIONID cookies but the second one is
separated with a "," instead of a ";" so what happens is we get a
JSESSIONIDSSO value of


which doesn't work at all.


I think this is a bug in Orbeon. There should only ever be a single cookie
header in any request, the separator should be ";" and there should only
ever be one instance of each cookie.

thanks
brian wallis...


--
Sent from: http://discuss.orbeon.com/

[bwallis42]

(I just edited the post to fix the missing raw bits, I seem to have problems
getting them right!)

[Alessandro Vernet]

Hi Brian,

While trying to reproduce the issue you're describing, I noticed that we're
incorrectly adding the string "null as a prefix and suffix to the forwarded
cookie in case the properties below are not set (i.e. left empty).

oxf.http.forward-cookies.session.prefix
oxf.http.forward-cookies.session.suffix

I created issue #3648 (see link below), and fixed the problem, so the fix
will be in 2018.1, as well as 2017.2.3.

https://github.com/orbeon/orbeon-forms/issues/3648

However, what you're reporting here, having 2 `JSESSIONID`, is something
different. I am also seeing this, but didn't get to spend enough time
investigating this to figure why it is happening. I'll try to come back to
this later this week and will follow-up here when I have something new.

Alex

-----
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet

[bwallis42]

Hi Alex,
Any update on this issue? It is affecting one of our customer test
installations.

I'm not 100% sure this is causing the problem we are seeing but it is likely
that the extra JSESSIONID is the problem.

thanks,
brian...

[Alessandro Vernet]

Hi Brian,

Not yet, but it's on my list. From what I've seen, one of the 2 `JSESSIONID`
is the correct one, so you would hope that the app server picks it up and
ignores the other one, but it seems like it might not be the case with
WildFly, and there should be that "other" `JSESSIONID` anyway. I'll post an
update here when I get to do spend more time investigating this one.

Alex

-----
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet

[Alessandro Vernet]

Hi Brian,

I am looking at this again, and first reproduced it, but noticed I had the
browser send 2 `JSESSIONID`. Looking at the situation with the Chrome Dev
Tools, one was for `/orbeon` and the other for `/orbeon/` (notice the
additional slash at the end of the path). I'm not sure how I got to have
those 2 cookies, but after removing them and reloading the page, I have just
1 cookie in the browser:

<http://discuss.orbeon.com/file/t119778/Cookies_in_Chrome.png>

…and that cookie gets properly sent to the implementation of the persistence
API:

<http://discuss.orbeon.com/file/t119778/Headers_for_implementation_of_the_persistence_API.png>

As you can see, I am just using the built-in MySQL, but for this testing, so
it goes through a "real" HTTP request, I excluded the MySQL path from the
"internal paths" by setting the first property below. Also, instead of using
Wireshark, I used Charles (a proxy), so instructed Orbeon Forms to go
through that proxy with the following 2 properties.



So it doesn't look like I'm able to reproduce the issue. Are you getting 2
`JSESSIONID` if you follow the steps above? If not, but do in another
situation, how should I modify those steps to reproduce the issue?

[Alessandro Vernet]

Hi Brian,

Is this one still a current issue? If so, did you get a chance to check
that, if you manage to reproduce it, you don't have 2 `JSESSIONID` sent by
the browser?

[bwallis42]

Hi Alex,
I still have the problem with the bad cookie string (full request dump
below) in the requests to our persistence layer.

I would like to try your latest build in case the fix you have has made some
difference. Do you have a recent 2018.1 PE snapshot build available.

thanks,
brian...

The headers of the query:

[bwallis42]

I've also noticed a couple of other things required for this to happen

The problem does not occur if the browser is running on the same host as the
server, i.e. using http://localhost/... for the URL. It only happens when
the browser is on a different workstation and is using the hostname/IP in
the URL.

The problem only seems to occur when the form includes a REST call via a
HTTP service and Action populating a dataset -- but it doesn't seem to
matter if this is called or not, it fails prior to the call. It fails on the
first call to our persistence layer as it is passing the wrong value for
JSESSIONIDSSO, the one with the added ", JSESSIONID"

[Erik Bruchez]

Brian,

Here is a link to the latest 2018.1 snapshot build:


https://s3.amazonaws.com/orbeon-builds/orbeon/orbeon-forms-pe/2179/2179.2/build/distrib/orbeon-2018.1.201808012219-PE.zip

-Erik

[bwallis42]

I think I might be confused about the settings required for the persistence
API and cookies.

I have this set currently


So this is saying to forward both the JSESSIONID and the JSESSIONIDSSO
cookies. These would be the cookies that are in the initiating request to
orbeon sent from the browser. Correct?

I suspect that I don't want the JSESSIONID cookie since it is the cookie
identifying the session between the browser and the orbeon war. My
persistence API calls are from the orbeon war to one or more of our
application wars. This will not (and cannot) use the session identified by
JSESSIONID. That session is maintained inside the container for the orbeon
war and is not shared with the application war. We don't share sessions
between wars, they are all different and contain application (war) specific
data.

I think all I want is the JSESSIONIDSSO cookie that identifies the
authorised user independently of the individual sessions with a variety of
wars. Setting it with just the JSESSIONIDSSO cookie for forwarding does seem
to work.

I also have noticed that our server, when the persistence API is called with
only the JSESSIONIDSSO cookie, includes a set-cookie header in the response
with a JSESSIONID value. This does not seem to be kept and used for
subsequent requests to our persistence API.

Should your client layer that is used to make the persistence calls be
keeping the JSESSIONID cookies and sending them back in subsequent requests?
It would be a little more efficient that way I think.

thanks
brian...

[bwallis42]

So, I'm running the 2018.1.201808012219-PE version and have a form with a
simple http service defined in it. This http service requires authentication
and we are using JSESSIONIDSSO for that so I have defined the cookie
forwarding with this



The service I am calling is co-located with our persistence API and is
running in the same wildfly 11 server as orbeon is. The service is in a
different war from orbeon and from our application so it requires its own
session hence we only want to send the JSESSIONIDSSO cookie to it, the
JSESSIONID of the incoming request to orbeon is not valid for this other
war.

When I click on the test button in the service definition I see the
following in the request headers



Note the comma separator. This results in a cookie value of



which is not a valid value for the SSO session, the first part is but the
addition of the ", JSESSIONID" makes it invalid.

I think this is the cause of the problems I am seeing. I think orbeon is not
separating multiple cookies in a request correctly. The standard at
https://tools.ietf.org/html/rfc6265#section-4.2.1 does show a ';' as the
separator. Of course this has changed over the years, rfc2109 allowed commas
as did rfc2965 but rfc6265 us definite about allowing only ';' separators.

I think the web server used in wildfly, undertow, is not backward compatible
to the earlier RFCs and is not allowing cookie values in incoming requests
to have ',' separators. There is probably not a lot I can do about that at
the moment. I'll find their ticket system and submit a bug/request and see
what happens.

But in the meantime, can orbeon just use ';' for the separator or is that
out of your control.

thanks,
brian...



The full request/response is

[bwallis42]

I just edited the last post to add back in the raw text parts. This mailing
list web interface seems to keep loosing any raw sections I add in the
initial post. No idea why, it used to work quite well.

brian...

[bwallis42]

Update, I have a reply from the undertow mailing list.

This is a feature (allowing comma separators) that has been recently added
and first appeared in wildfly 12. Pity, I'm running 11.

Their ticket and explanation is at
https://issues.jboss.org/browse/UNDERTOW-1163 and mentions a particular
sequence of usage of older apache httpclient libraries (3.x) and using
apache mod_proxy. This does seem to match my circumstances. I may be able to
avoid the mod_proxy usage so I'll try that and see if it circumvents the
problem for the moment.

Is orbeon using httpclient 3.x and if so would it be possible to update to
HttpClient 4.1 for the 2018.1 release? I've no idea of what compatibility
issues this might raise. It is not a drop in replacement but the task of
updating is described in a number of articles such as
http://blog.teamextension.com/migrating-from-httpclient-3-1-to-4-0-34

thanks, brian...

[bwallis42]

Update (this is the third time I've posted this reply, not sure what happened
to the last two)

thanks, brian...

[bwallis42]

Update, I have a reply from the undertow mailing list.

This is a feature (allowing comma separators) that has been recently added
and first appeared in wildfly 12. Pity, I'm running 11.

Their ticket and explanation is at
https://issues.jboss.org/browse/UNDERTOW-1163 and mentions a particular
sequence of usage of older apache httpclient libraries (3.x) and using
apache mod_proxy. This does seem to match my circumstances. I may be able to
avoid the mod_proxy usage so I'll try that and see if it circumvents the
problem for the moment.

Is orbeon using httpclient 3.x and if so would it be possible to update to
HttpClient 4.1 for the 2018.1 release? I've no idea of what compatibility
issues this might raise. It is not a drop in replacement but the task of
updating is described in a number of articles such as
http://blog.teamextension.com/migrating-from-httpclient-3-1-to-4-0-34

thanks, brian...

[bwallis42]

thanks, brian...

[bwallis42]

Hi Alex, Erik,
I would really appreciate some help with this authentication problem we
are having. I am currently running version 2018.1.201808012219 PE and am
having no end of problems with authentication to our persistence
implementation.

My summary of what I think the issue is follows:


First, I note that you are using the newer version 4 Apache HttpClient
library (4.3.5?) so I shouldn't be seeing commas in the cookie strings if
that library is handling the cookies.


I am seeing three http requests occuring when I access a form in our
application. These happen in the order request1 -> request2 -> request3 ->
response3 -> response2 -> response1


request1

The initial request from the browser is to

GET /orbeon/fr/CPF/IMTEST-5580/view/201808132?print=true

with a cookie header containing two cookies (this is one line as seen in
wireshark)

Cookie: JSESSIONID=HZE4X8B-pQ6bGBlUGF55oI2vIOB4lfakCh9ETGIA.localhost;
JSESSIONIDSSO=VElK9KxBIfgilSc6ag-elciBNb5j6cGexULbCpjM

request2

The next seems to be internal from orbeon to orbeon (I thought you had
eliminated those internal http requests?)

GET
/orbeon/fr/service/persistence/crud/CPF/IMTEST-5580/form/form.xhtml?document=201808132

but this has two cookie headers and a cookie2 header

Cookie: JSESSIONIDSSO=VElK9KxBIfgilSc6ag-elciBNb5j6cGexULbCpjM
Cookie: JSESSIONID=rQm9SiQw1Y_UD6_MaVtTEmyN9MJrbfV7922CICVv.localhost
Cookie2: $Version=1

but so far so good, the JSESSIONIDSSO value is correct.
The next call is to our persistence api

request3

GET /persistence/cpf/crud/CPF/IMTEST-5580/form/form.xhtml?document=201808132

and it has the following cookie header in it

Cookie: JSESSIONIDSSO=iDZVfyD3JwLXu86gzNcKyr73gii6XPWdptqIo6iD

Note that this is the wrong JSESSIONIDSSO value, it should be the same as
the one in the first and second requests.

response3


Unauthorized 401 and has a set-cookie to clear the JSESSIONIDSSO cookie

response2


Also Unauthorized 401 and also has a set-cookie to clear the JSESSIONIDSSO
cookie. Interestingly it has a set-cookie to set a JSESSIONID cookie that
includes of the value of the JSESSIONIDSSO cookie seen in request3. Why?

response1


Forbidden 403. No cookie action.

questions


1) Where did this JSESSIONIDSSO value come from? Note that it is the first
part of the value of the JSESSIONID cookie that is returned by the second
GET request (set-cookie) above but note that the response is generated after
this third request has returned.

2) Why is there the intermediate http request? (second request) Can it be
eliminated?

Analysis?


It is this second request that seems to cause the problems as it is
including two cookie headers which the most recent http RFC 6265 explicitly
prohibits. At some point inside orbeon or one of the libraries or appserver
these two cookie headers are turned into a comma separated single cookie
header. Which is what RFC 7230 says you can do with multiple headers but
which RFC 6265 says you cannot do for the cookie header.

This is confusing. Any help you can give me would be most welcome.

thanks,
brian wallis

[bwallis42]

The last test I did (above) was with the oxf.http.forward-cookies value of
"JSESSIONIDSSO". I've just tried again with this set to "JSESSIONID
JSESSIONIDSSO".

My persistence layer does not want that JSESSIONID as it is for the session
between the browser and the orbeon app whereas my persistence layer is in a
different app and requires its own session. JSESSIONIDSSO represents the
user's authentication status and should be all that is required.

But that said, it seems to work better with JSESSIONID included as it
doesn't muck up the JSESSIONIDSSO cookie.

I also don't see the intermediate request (request2 above) when I add
JSESSIONID to the forward-cookies list, I just have request1 and request3,
i.e. it goes straight to my persistence after the view form request to
orbeon.

request2 is different and has multiple cookie headers and two values for
JSESSIONID, it looks like this (below, again from wireshark)

Since I don't need or use JSESSIONID the fact that there are two doesn't
matter, what I do get in this case is the correct value for JSESSIONIDSSO so
it works in this simple case but the handling of the multiple cookie headers
and multiple JSESSIONID values is not standard and breaks sometimes
depending on apache/ssl configurations and what versions of http libraries
are used.

Is it correct for me to configure oxf.http.forward-cookies with just
JSESSIONIDSSO? Should it work? I don't need the other session cookie.


GET /persistence/cpf/crud/CPF/IMTEST-5580/form/form.xhtml?document=201808132
HTTP/1.1
Orbeon-Versioning: true
Orbeon-Roles: infomedix
Orbeon-Roles: system
If-Modified-Since: Tue, 14 Aug 2018 22:51:39 GMT
Orbeon-Credentials:
{"username":"system","groups":["infomedix"],"roles":[{"name":"infomedix"},{"name":"system"}],"organizations":[]}
Cookie: JSESSIONID=bsrWzXmquMbl2TQrZXJ5lsQGwjO801YlFYxE5qhw.localhost;
JSESSIONIDSSO=Vcxe-9gHtJ9l4sF19wsfut_OXvKkldIUJsLwy30Z
Orbeon-For-Document-Id: 201808132
Orbeon-Username: system
Orbeon-Token: a8340a29b8b02f7afc1a81fda517c2197f43d910
Orbeon-Group: infomedix
Host: localhost:8080
Connection: Keep-Alive
Cookie: JSESSIONID=LgRFfwgi_wxmwhRU-YmNaNfk2gWjzmOCDCKrM5kd.localhost
Cookie2: $Version=1
Accept-Encoding: gzip,deflate

[bwallis42]

Fixed a typo above, said "request2 is different and has multiple cookie
headers" where I should have said "request3 is different and has multiple
cookie headers". Of course "request3" is the second request in this
scenario.

[Alessandro Vernet]

Hi Brian,

(My apologies for the lack of responsiveness in the past few weeks; I was
travelling, which made keeping up with email even more a of a challenge!)

We are using HttpClient 4.3.5. I'm not surprised that forwarding the
`JSESSIONID`doesn't happen with the first request, as the first request from
the browser most likely doesn't have a `JSESSIONID` (and if it does, it
might be an obsolete one, which will be changed in the response). But do you
need the actual `JSESSIONID` used by the browser to be forwarded to the
service? Or do you just need Orbeon Forms to maintain a session with the
service, so the service knows the query is coming from the same caller? If
the latter, you shouldn't need to forward the `JSESSIONID`; Orbeon Forms
should maintain a session with the callee out-of-the-box, as a browser
would.

Does this help, or am I misunderstanding the situation?

Alex

-----
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet

[bwallis42]

Hi Alex,
I summarised what I think the issues is in a basecamp message.

You are correct, we don't want the JSESSIONID cookie forwarded and so don't
want to put it in oxf.http.forward-cookies. That should only contain
JSESSIONIDSSO.

But if we configure it that way our persistence call is passed the wrong
value for JSESSIONIDSSO and so cannot be authenticated. With this
configuration we also seem to get an additional HTTP request from orbeon to
orbeon
(http://localhost:8080/orbeon/fr/service/persistence/crud/CPF/IMTEST-5580/form/form.xhtml?document=201808132)
prior to the request to our persistence layer.

If I instead configure oxf.http.forward-cookies to include JSESSIONID and
JSESSIONIDSSO then the intermediate request is not seen and the correct
JSESSIONIDSSO value is seen at our persistence layer. But in this case there
still is a problem with that request as it contains multiple Cookie headers
and multiple JSESSIONID values These cause other issues so it is still not
ideal. This configuration also seems to break Http Service requests from our
forms (they need the same JSESSIONIDSSO value to be authenticated).

thanks,
brian...

[Alessandro Vernet]

Hi Brian,

As a workaround, could you try using the following, that is without
mentioning `JSESSIONID` and using a dummy name as the first cookie to
forward.

<property as="xs:string" name="oxf.http.forward-cookies" value="DUMMY
JSESSIONIDSSO"/>

You'll let me know if this works for you.

Alex

-----
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet

[bwallis42]

Hi Alex,
I still get the bad cookie string if I use "DUMMY JSESSIONIDSSO" as the
value of oxf.http.forward-cookies. It is still attempting to send a
JSESSIONID cookie.

brian...

[Alessandro Vernet]

Hi Brian,

When using `DUMMY JSESSIONIDSSO`, what cookies exactly are being sent by
Orbeon Forms on the first and on subsequent requests? On my side:

1. First query
1.1. Request: Cookie: JSESSIONIDSSO=123 (with the value being received by
Orbeon Forms)
1.2. Response: Set-Cookie: JSESSIONID=abc (different from the `JSESSIONID`
between the browser and Orbeon Forms)

2. Subsequent queries
2.1. Request with 2 Cookie headers: Cookie: JSESSIONIDSSO=123 and Cookie:
JSESSIONID=abc
2.2. Response: no cookie set

Are you seeing something different?

Alex

-----
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet

[bwallis42]

Hi Alex,
I must have done something wrong the first time I tried it. I've checked
my configuration and restarted and tested and it is now working as you
describe.

I can also confirm that this is working correctly for http session requests
in the form. The first one uses just the JSESSIONIDSSO cookie and gets a
setcookie for JSESSIONID in the response and that cookie is used in
subsequent requests.

But, there is a problem. It is not working when I have two different users
logged in. I am still trying to get to the bottom of this but and will post
my results once I work out what is happening.

thanks,
brian...

[bwallis42]

The problem seems to be the return of the "," in the cookie header in a
request for the second user to access the form. This is accompanied by an
extra request as well.

Instead of requesting the from directly from our persistence API
/persistence/cpf/crud/CPF/IMTEST-5580/form/form.xhtml
it seems to make a request to orbeon first
/orbeon/fr/service/persistence/crud/CPF/IMTEST-5580/form/form.xhtml
which is then forwarding the request to our API.

The user account where it works does not have this intermediate request. It
is in this intermedia request that has the cookie header with the ','
separator in it.

What I see for the user who first accesses the form successfully are the
following requests (with relevant headers)

URI=/orbeon/fr/CPF/IMTEST-5580/view/201808234

cookie=JSESSIONID=goaYDR1Us_D674NSOj9CVNMkZLEZikEPDhSpU45G.localhost
cookie=JSESSIONIDSSO=5gmD1LXRbXwlqVl5sYiVdkdsxR2gvFDeD3UetnUq

header=Cookie=JSESSIONID=goaYDR1Us_D674NSOj9CVNMkZLEZikEPDhSpU45G.localhost;
JSESSIONIDSSO=5gmD1LXRbXwlqVl5sYiVdkdsxR2gvFDeD3UetnUq
method=GET
Response:
status=200

URI=/persistence/cpf/crud/CPF/IMTEST-5580/form/form.xhtml

cookie=JSESSIONID=fDisuvOtseTTjAexY5-dLENZqKIDGXy901_fsDge.localhost
cookie=JSESSIONIDSSO=5gmD1LXRbXwlqVl5sYiVdkdsxR2gvFDeD3UetnUq

header=Cookie=JSESSIONIDSSO=5gmD1LXRbXwlqVl5sYiVdkdsxR2gvFDeD3UetnUq

header=Cookie=JSESSIONID=fDisuvOtseTTjAexY5-dLENZqKIDGXy901_fsDge.localhost
method=GET
Response:
status=200

URI=/persistence/cpf/crud/CPF/IMTEST-5580/data/201808234/data.xml

cookie=JSESSIONID=fDisuvOtseTTjAexY5-dLENZqKIDGXy901_fsDge.localhost
cookie=JSESSIONIDSSO=5gmD1LXRbXwlqVl5sYiVdkdsxR2gvFDeD3UetnUq

header=Cookie=JSESSIONIDSSO=5gmD1LXRbXwlqVl5sYiVdkdsxR2gvFDeD3UetnUq

header=Cookie=JSESSIONID=fDisuvOtseTTjAexY5-dLENZqKIDGXy901_fsDge.localhost
method=GET
Response:
status=200


but for the other user I get these requests and the request fails. You can
see that there is the additional request to /orbeon/fr/service/persistence
and it is there that the cookies are being mucked up. The ',' separated
cookie header ends up with a JSESSIONIDSSO cookie value with ' ,JSESSIONID'
appended to it and this is passed on to our persistence layer where it fails
to authenticate.

URI=/orbeon/fr/CPF/IMTEST-5580/view/201808234

cookie=JSESSIONID=S8OxRabqld0GWPV65q8BoEDaXjAj45k2rDoKMJt7.localhost
cookie=JSESSIONIDSSO=b2WWTihX3K03VgHGDAmgaecKdii607tGcVcJGbN2

header=Cookie=JSESSIONID=S8OxRabqld0GWPV65q8BoEDaXjAj45k2rDoKMJt7.localhost;
JSESSIONIDSSO=b2WWTihX3K03VgHGDAmgaecKdii607tGcVcJGbN2
method=GET
Response:
status=403

URI=/orbeon/fr/service/persistence/crud/CPF/IMTEST-5580/form/form.xhtml
cookie=JSESSIONIDSSO=b2WWTihX3K03VgHGDAmgaecKdii607tGcVcJGbN2,
JSESSIONID

header=Cookie=JSESSIONIDSSO=b2WWTihX3K03VgHGDAmgaecKdii607tGcVcJGbN2,
JSESSIONID=iQC_8alVjS-qeWU1RI-kmAnC7Uk4YMDLNn3-UIvp.localhost
method=GET
Response:

cookie=JSESSIONID=eCk_T65L-9yTnRS5KI5-xt2zxXOzL7mAFFKum5qe.localhost;
domain=null; path=/orbeon
cookie=JSESSIONIDSSO=null; domain=null; path=/

header=Set-Cookie=JSESSIONID=eCk_T65L-9yTnRS5KI5-xt2zxXOzL7mAFFKum5qe.localhost;
path=/orbeon
header=Set-Cookie=JSESSIONIDSSO=""; path=/; Max-Age=0;
Expires=Thu, 01-Jan-1970 00:00:00 GMT
status=401

URI=/persistence/cpf/crud/CPF/IMTEST-5580/form/form.xhtml
cookie=JSESSIONIDSSO=b2WWTihX3K03VgHGDAmgaecKdii607tGcVcJGbN2,
JSESSIONID

header=Cookie=JSESSIONIDSSO=b2WWTihX3K03VgHGDAmgaecKdii607tGcVcJGbN2,
JSESSIONID
method=GET
Response:
cookie=JSESSIONIDSSO=null; domain=null; path=/
header=Set-Cookie=JSESSIONIDSSO=""; path=/; Max-Age=0;
Expires=Thu, 01-Jan-1970 00:00:00 GMT
status=401

[Alessandro Vernet]

Hi Brian,

If I understand this properly, in the case that works, in the second query,
the `JSESSIONID` is sent in the same Cookie header.

Works:
cookie=JSESSIONID=fDisuvOtseTTjAexY5-dLENZqKIDGXy901_fsDge.localhost
cookie=JSESSIONIDSSO=5gmD1LXRbXwlqVl5sYiVdkdsxR2gvFDeD3UetnUq

Fails:
header=Cookie=JSESSIONIDSSO=b2WWTihX3K03VgHGDAmgaecKdii607tGcVcJGbN2,
JSESSIONID=iQC_8alVjS-qeWU1RI-kmAnC7Uk4YMDLNn3-UIvp.localhost

And as you noted, in the failing case, a coma is used to separate the
cookies. It would be fine to have multiple headers specified in the same
Cookie header, but a semicolon should be used as a separator (see link
below).

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cookie

Now, how can I reproduce this? What would I need to do to be in the second
instead of the first case?

Alex

-----
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet

[bwallis42]

Hi Alex,
Yes, you've got it right. That is what is happening. The ',' versus ';' is
an issue caused by the earlier http standards allowing either but the most
recent (but some years ago) version removing the ',' as a valid separator.

So, how to reproduce it.

For me it is now only happening when I have two users from two different
browsers logging in and viewing a form. The first user to access a
particular form works fine. The second user gets an error.

The requests issued by orbeon to retrieve the form for the second user are
different from the first user's requests.

The first user requests to view the form are:

/orbeon/fr/CPF/IMTEST-5580/view/201808234
/persistence/cpf/crud/CPF/IMTEST-5580/form/form.xhtml
/persistence/cpf/crud/CPF/IMTEST-5580/data/201808234/data.xml

The requests for the second user viewing the same form are:

/orbeon/fr/CPF/IMTEST-5580/view/201808234
*/orbeon/fr/service/persistence/crud/CPF/IMTEST-5580/form/form.xhtml*
/persistence/cpf/crud/CPF/IMTEST-5580/form/form.xhtml

There should be a request for the form data but since the form template
fetch has failed that isn't issued.

The problem is in the second request which includes the cookie header with
multiple cookies separated by a comma. This request doesn't occur for the
first user so there is no cookie problem

I can reproduce this on our system by using two browsers logged in as
different users and accessing the same form. Can you do something similar in
your system? It doesn't look like it is related to our persistence API
implementation but I suppose that might be possible.

thanks
brian...

[bwallis42]

Hi Alex,
I have just gone back to testing this using the latest build you gave me
yesterday (2018.1.201808291755-PE) and the problem seems to be gone as long
as I use the dummy value in oxf.http.forward-cookies. e.g.

<property as="xs:string" name="oxf.http.forward-cookies" value= "DUMMY
JSESSIONIDSSO" />

If I don't use the DUMMY value it does still seem to muck up the cookie
values on the first request to my persistence layer after a login as
described earlier.

What I see is the value of JSESSIONIDSSO passed in in the first request to
my persistence layer, a request to /persistence, is the JSESSIONID value
set in the preceding initial request to /orbeon to view the form.

The set cookie response header for the /orbeon GET request is

Set-Cookie=JSESSIONID=R44mpagCxlWNyjCwrBKZX6jJkMTQKmzF5M5VPh7F.localhost;
path=/orbeon

and the cookie passed to the GET request to /persistence is

Cookie=JSESSIONIDSSO=R44mpagCxlWNyjCwrBKZX6jJkMTQKmzF5M5VPh7F

which has got the .localhost stripped off it.

Anyway, the workaround is good so this is not so much of a problem for us
now.

thanks,

[Alessandro Vernet]

Hi Brian,

I'm glad adding `DUMMY` as the first cookie in `oxf.http.forward-cookies`
solves that issue as well. If you don't want to forward the `JSESSIONID`
from the browser to the service but want to forward other cookies, this is
anyway the only way to do it right now. So what you're doing is correct as
things stand right now, and you can definitely keep that config.

Now, without it, I'm not sure why there would be a difference between the
"first" and "second" user. You were saying that you see a request to
`/orbeon/fr/service/persistence/crud/CPF/IMTEST-5580/form/form.xhtml` for
the second user, and I imagine that you're using Wireshark. This means that
the request goes over HTTP, and isn't done internally, which shouldn't be
the case. I'll keep an eye open to see if I can reproduce this while testing
things out.

Alex

-----
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet

[bwallis42]

Yes, I saw an intermediate request via localhost to /orbeon/fr/service/..

Not a problem for the moment with the DUMMY cookie value.

thanks
brian...

[Alessandro Vernet]

Hi Brian,

I'm still wondering what could have caused that query to
`/orbeon/fr/service` to go over HTTP instead of being done as an internal
request. As mentioned earlier, I'll keep eye open to see if I notice
anything similar while testing.

Alex

-----
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet

[bwallis42]

Hi Alex,
Re-activating a very old issue.... (running 2018.1.2)

We are now getting this problem in production at two sites. As described
above but it is occurring when we make rest calls from forms using HTTP
Services.

Our config has the following in it



So, as before, we don't want the JSESSIONID cookie passed through but we do
want JSESSIONIDSSO.

We define an HTTP Service to http://act-e2e/infoapi/user/profile with no
http auth selected and click the test button and get a result. The logging
from wildfly is



which looks good. We click the test button a second time and we get a 401
and this logging:



Note in the second set of logging we have the following for the cookies:



whereas the first request, before a session was created, is



With only one cookie and no ',' in it.

It is a bit hard to give a test case as it requires a service to call that
is using JSESSIONIDSSO for authentication.

Do we know where the ", $Version=1" is coming from , that is what is
breaking the second request.

[bwallis42]

(see edited version of first post for included 'raw' sections with logs)

[Alessandro Vernet]

Hi Brian,

In the second request, I also see that the `JSESSIONID` is passed, which I
don't think you want. This is why we set the `oxf.http.forward-cookies` to
`DUMMY JSESSIONIDSSO`. Do you still have that property set? If so, do you
see why `JSESSIONID` would be passed?

Regarding the `$Version=1` attribute, according to RFC 2109, "the value of
the cookie-version attribute must be the value from the Version attribute,
if any, of the corresponding Set-Cookie response header". See section 4.3.4
on the page linked below. Now, Orbeon Forms doesn't receive the
`Set-Cookie`, but forwards the cookie from the `Cookie` header. Still, it is
strange to see that `$Version=1` in the 2nd request, but not the 1st one.
Are you sure that this is what is breaking the 2nd request?

https://tools.ietf.org/html/rfc2109

‑Alex

-----
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet

[bwallis42]

Hi Alex,
I haven't traced the actual web traffic but am in the process of looking
for that now. I am pretty sure it is this additional thing in the cookie but
will try to confirm that.
I have no idea why the JSESSIONID is ending up in the cookie the second time
around. Our configuration is

<property as="xs:string" name="oxf.http.forward-cookies" value= "DUMMY
JSESSIONIDSSO" />

Which should exclude any JSESSIONID being passed through. I'm thinking that
the underlying HTTP package in Orbeon is adding that to the request. Does it
do session caching for REST requests made from the form?

I don't think this JSESSIONID is the same one as used for the browser
session with Orbeon but I will check that also.

I note that the tracing suggests that the $Version is included after the
cookie value but RFC2109 definition shows that if there is a $Version
included it should precede the cookie value. It can also use a ',' or a ';'
as a separator from the value.

I'll post my findings of what is actually sent between Orbeon and our
application for the two REST calls.

[bwallis42]

Hi Alex,
So, I think I've found the root cause of this issue. Not an Orbeon
problem. It looks like a bug in Apache's mod_headers module. We frontend
our application with apache (2.4) and proxy requests through to our
application server.

The mod_headers module is merging the two cookie headers in the request into
a single cookie header and it is comma separating them. This is what our
application server is seeing and breaking on.

According the the RFCs for the cookies (RFC-6265) this is not a valid cookie
header but it seems it is not that uncommon and works a lot of the time.

A workaround is to put a header rewrite directive in the apache
configuration

RequestHeader edit* Cookie , ;

which replaces the "," with ";" after it was merged into the one header.

thanks
brian...

[Alessandro Vernet]

Hi Brian,

> Which should exclude any JSESSIONID being passed through. I'm thinking
> that
> the underlying HTTP package in Orbeon is adding that to the request. Does
> it
> do session caching for REST requests made from the form?

> I don't think this JSESSIONID is the same one as used for the browser
> session with Orbeon but I will check that also.

Mmh… OK, so that `JSESSIONID` might be the one set by the service, and yes,
Orbeon Forms is behaving like a browser, so if it makes 2 requests and the
first response sets a cookie, then the second request will send that cookie,
to maintain the session. So this might explain it, and if this is indeed
what is happening, then it's OK.

> So, I think I've found the root cause of this issue. Not an Orbeon
> problem. It looks like a bug in Apache's mod_headers module.

Great, I'm glad you found what the problem was, and thank you for sharing
this and the workaround.

‑Alex

-----
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet