Problems with cookies for persistence and services

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

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

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

5.4.  The Cookie Header

   The user agent includes stored cookies in the Cookie HTTP request
   header.

   When the user agent generates an HTTP request, the user agent MUST
   NOT attach more than one Cookie header field.

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)

header=Cookie=JSESSIONID=Kz5Je0HO7hnerqhcvVNaXVpUkR8E_MDsLgcj18Ei.localhost; JSESSIONIDSSO=FWy49jHiViz-UYWy4nBXJhwGw7NCNVf2OygJy82g
header=Cookie=JSESSIONID=NO_pDGhF7yIRgWWEo667cUSzulU_FYQd-OYCg-cs.localhost

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

header=Cookie=JSESSIONID=Kz5Je0HO7hnerqhcvVNaXVpUkR8E_MDsLgcj18Ei.localhost; JSESSIONIDSSO=FWy49jHiViz-UYWy4nBXJhwGw7NCNVf2OygJy82g, JSESSIONID=Ze5aEtB1DgDf9CK06K1SJSyw6emMKbHQ5k8k3fPR.localhost

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

FWy49jHiViz-UYWy4nBXJhwGw7NCNVf2OygJy82g, JSESSIONID

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

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

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

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].

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
--
Sent from: http://discuss.orbeon.com/

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].

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


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

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].

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
--
Sent from: http://discuss.orbeon.com/

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].

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?

Alex

-----
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet
--
Sent from: http://discuss.orbeon.com/

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].

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?

Alex

-----
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet
--
Sent from: http://discuss.orbeon.com/

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].

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:

               URI=/persistence/cpf/crud/CPF/IMTEST-5580/form/form.xhtml
 characterEncoding=null
     contentLength=-1
       contentType=null
            cookie=JSESSIONID=-w4zN1Cx7msIK_SmiGvX0ne7Xmkzr5PmlBBUAeJ1.localhost
            cookie=JSESSIONIDSSO=63cBw4X_oSJsSi_KoaiJKAHM870PRoq0opAFN1fD, JSESSIONID
            header=Orbeon-For-Document-Id=2018080111
            header=Accept-Encoding=gzip,deflate
            header=If-Modified-Since=Wed, 01 Aug 2018 04:00:36 GMT
            header=Orbeon-Group=infomedix
            header=Orbeon-Credentials={"username":"system","groups":["infomedix"],"roles":[{"name":"infomedix"},{"name":"system"}],"organizations":[]}
            header=Connection=Keep-Alive
            header=Orbeon-Username=system
            header=Orbeon-Token=b5bee19513f2d0d9d860553a7d1e01f5cd43ce11
            header=Orbeon-Versioning=true
            header=Orbeon-Roles=infomedix
            header=Orbeon-Roles=system
            header=Cookie=JSESSIONID=f_RMAG6QzZBJ8BvdMOSY6OM0Cmmx6XgJ9RCKxX-v.localhost; JSESSIONIDSSO=63cBw4X_oSJsSi_KoaiJKAHM870PRoq0opAFN1fD, JSESSIONID
            header=Cookie=JSESSIONID=-w4zN1Cx7msIK_SmiGvX0ne7Xmkzr5PmlBBUAeJ1.localhost
            header=Cookie2=$Version=1
            header=Host=localhost:8080
            locale=[]
            method=GET
         parameter=document=2018080111
          protocol=HTTP/1.1
       queryString=document=2018080111
        remoteAddr=/127.0.0.1:51573
        remoteHost=localhost
            scheme=http
              host=localhost:8080
        serverPort=8080

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

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orbeon+unsubscribe@googlegroups.com.
To post to this group, send email to orbeon@googlegroups.com.

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"


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

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].

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

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

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].

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


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

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].

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

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

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

            header=Cookie=JSESSIONIDSSO=jIEqQ-kTedwXrvqm9CBACBg8QlCXzJKILwCftnaV, JSESSIONID=lDA5h47Pk_jrnIwAshNsQ7Ot269XyVSTR1mwYNEL.localhost

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

cookie=JSESSIONIDSSO=jIEqQ-kTedwXrvqm9CBACBg8QlCXzJKILwCftnaV, JSESSIONID

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

               URI=/infoapi/user/profile
 characterEncoding=null
     contentLength=-1
       contentType=[none]
            cookie=JSESSIONIDSSO=jIEqQ-kTedwXrvqm9CBACBg8QlCXzJKILwCftnaV, JSESSIONID
            header=Connection=Keep-Alive
            header=Orbeon-Token=5b4085e06896f374e8dec7a22f9e411a2b0d2105
            header=Accept-Encoding=gzip,deflate
            header=Content-Type=none
            header=Cookie=JSESSIONIDSSO=jIEqQ-kTedwXrvqm9CBACBg8QlCXzJKILwCftnaV, JSESSIONID=lDA5h47Pk_jrnIwAshNsQ7Ot269XyVSTR1mwYNEL.localhost
            header=Cookie2=$Version=1
            header=Host=localhost
            locale=[]
            method=GET
          protocol=HTTP/1.1
       queryString=
        remoteAddr=/127.0.0.1:55984
        remoteHost=localhost
            scheme=http
              host=localhost
        serverPort=80
--------------------------RESPONSE--------------------------
     contentLength=71
       contentType=text/html;charset=UTF-8
            cookie=JSESSIONIDSSO=null; domain=null; path=/
            header=Expires=0
            header=Cache-Control=no-cache, no-store, must-revalidate
            header=X-Powered-By=Undertow/1
            header=Set-Cookie=JSESSIONIDSSO=""; path=/; Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:00 GMT
            header=Server=WildFly/11
            header=Pragma=no-cache
            header=Date=Fri, 03 Aug 2018 08:33:29 GMT
            header=WWW-Authenticate=Basic realm="REST API authentication module"
            header=Content-Type=text/html;charset=UTF-8
            header=Content-Length=71
            status=401

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


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

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].

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

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

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].

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




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

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].

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.

request3 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
 

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

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orbeon+unsubscribe@googlegroups.com.
To post to this group, send email to orbeon@googlegroups.com.

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.

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

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].

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
--
Sent from: http://discuss.orbeon.com/

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].

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




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

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].

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
--
Sent from: http://discuss.orbeon.com/

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].