Problems with cookies for persistence and services

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


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

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


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

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

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



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

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

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


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

(and now editing to add back in the raw text that posting requests seems to loose!)

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

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

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

2019-12-13 14:41:21,397 159573062 DEBUG [default I/O-4] undertow.request - Matched prefix path /infoapi for path /infoapi/user/profile
2019-12-13 14:41:21,397 159573062 DEBUG [Unknown] request.security - Security constraints for request /infoapi/user/profile are [SingleConstraintMatch{emptyRoleSemantic=PERMIT, requiredRoles=[**]}]
2019-12-13 14:41:21,397 159573062 DEBUG [Unknown] request.security - Authenticating required for request HttpServerExchange{ GET /infoapi/user/profile request {Connection=[Keep-Alive], Orbeon-Token=[afd4120faad40760c81bf1dccc8972bf84eb75cb], Accept-Encoding=[gzip,deflate], Cookie=[JSESSIONIDSSO=aG7HG-cfiLqOSAfCHL2ouKTb2h6oNHAJd4gkl4aH], Host=[act-e2e]} response {X-Powered-By=[Undertow/1], Server=[WildFly/11]}}
2019-12-13 14:41:21,397 159573062 DEBUG [Unknown] request.security - Setting authentication required for exchange HttpServerExchange{ GET /infoapi/user/profile request {Connection=[Keep-Alive], Orbeon-Token=[afd4120faad40760c81bf1dccc8972bf84eb75cb], Accept-Encoding=[gzip,deflate], Cookie=[JSESSIONIDSSO=aG7HG-cfiLqOSAfCHL2ouKTb2h6oNHAJd4gkl4aH], Host=[act-e2e]} response {X-Powered-By=[Undertow/1], Server=[WildFly/11]}}
2019-12-13 14:41:21,397 159573062 DEBUG [Unknown] request.security - Attempting to authenticate HttpServerExchange{ GET /infoapi/user/profile request {Connection=[Keep-Alive], Orbeon-Token=[afd4120faad40760c81bf1dccc8972bf84eb75cb], Accept-Encoding=[gzip,deflate], Cookie=[JSESSIONIDSSO=aG7HG-cfiLqOSAfCHL2ouKTb2h6oNHAJd4gkl4aH], Host=[act-e2e]} response {Expires=[0], Cache-Control=[no-cache, no-store, must-revalidate], X-Powered-By=[Undertow/1], Server=[WildFly/11], Pragma=[no-cache]}}, authentication required: true
2019-12-13 14:41:21,399 159573064 DEBUG [Unknown] undertow.session - Created session with id CHJDiUc4UMQVCkYmHI43Me0E40yHOlIpqN-jrFbi for exchange HttpServerExchange{ GET /infoapi/user/profile request {Connection=[Keep-Alive], Orbeon-Token=[afd4120faad40760c81bf1dccc8972bf84eb75cb], Accept-Encoding=[gzip,deflate], Cookie=[JSESSIONIDSSO=aG7HG-cfiLqOSAfCHL2ouKTb2h6oNHAJd4gkl4aH], Host=[act-e2e]} response {Expires=[0], Cache-Control=[no-cache, no-store, must-revalidate], X-Powered-By=[Undertow/1], Server=[WildFly/11], Pragma=[no-cache]}}
2019-12-13 14:41:21,399 159573064 DEBUG [Unknown] request.security - Authenticated as infomedix, roles [infomedix]
2019-12-13 14:41:21,400 159573065 DEBUG [Unknown] request.security - Authentication outcome was AUTHENTICATED with method io.undertow.servlet.handlers.security.ServletSingleSignOnAuthenticationMechanism@5e5cb880 for HttpServerExchange{ GET /infoapi/user/profile request {Connection=[Keep-Alive], Orbeon-Token=[afd4120faad40760c81bf1dccc8972bf84eb75cb], Accept-Encoding=[gzip,deflate], Cookie=[JSESSIONIDSSO=aG7HG-cfiLqOSAfCHL2ouKTb2h6oNHAJd4gkl4aH], Host=[act-e2e]} response {Expires=[0], Cache-Control=[no-cache, no-store, must-revalidate], X-Powered-By=[Undertow/1], Server=[WildFly/11], Pragma=[no-cache]}}
2019-12-13 14:41:21,400 159573065 DEBUG [Unknown] request.security - Authentication result was AUTHENTICATED for HttpServerExchange{ GET /infoapi/user/profile request {Connection=[Keep-Alive], Orbeon-Token=[afd4120faad40760c81bf1dccc8972bf84eb75cb], Accept-Encoding=[gzip,deflate], Cookie=[JSESSIONIDSSO=aG7HG-cfiLqOSAfCHL2ouKTb2h6oNHAJd4gkl4aH], Host=[act-e2e]} response {Expires=[0], Cache-Control=[no-cache, no-store, must-revalidate], X-Powered-By=[Undertow/1], Server=[WildFly/11], Pragma=[no-cache]}}

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

2019-12-13 14:41:22,642 159574307 DEBUG [default I/O-4] undertow.request - Matched prefix path /infoapi for path /infoapi/user/profile
2019-12-13 14:41:22,642 159574307 DEBUG [Unknown] request.security - Security constraints for request /infoapi/user/profile are [SingleConstraintMatch{emptyRoleSemantic=PERMIT, requiredRoles=[**]}]
2019-12-13 14:41:22,643 159574308 DEBUG [Unknown] request.security - Authenticating required for request HttpServerExchange{ GET /infoapi/user/profile request {Connection=[Keep-Alive], Orbeon-Token=[afd4120faad40760c81bf1dccc8972bf84eb75cb], Accept-Encoding=[gzip,deflate], Cookie=[JSESSIONIDSSO=aG7HG-cfiLqOSAfCHL2ouKTb2h6oNHAJd4gkl4aH, $Version=1; JSESSIONID="CHJDiUc4UMQVCkYmHI43Me0E40yHOlIpqN-jrFbi.primary:cpf-server"; $Path="/infoapi"], Cookie2=[$Version=1], Host=[act-e2e]} response {X-Powered-By=[Undertow/1], Server=[WildFly/11]}}
2019-12-13 14:41:22,643 159574308 DEBUG [Unknown] request.security - Setting authentication required for exchange HttpServerExchange{ GET /infoapi/user/profile request {Connection=[Keep-Alive], Orbeon-Token=[afd4120faad40760c81bf1dccc8972bf84eb75cb], Accept-Encoding=[gzip,deflate], Cookie=[JSESSIONIDSSO=aG7HG-cfiLqOSAfCHL2ouKTb2h6oNHAJd4gkl4aH, $Version=1; JSESSIONID="CHJDiUc4UMQVCkYmHI43Me0E40yHOlIpqN-jrFbi.primary:cpf-server"; $Path="/infoapi"], Cookie2=[$Version=1], Host=[act-e2e]} response {X-Powered-By=[Undertow/1], Server=[WildFly/11]}}
2019-12-13 14:41:22,643 159574308 DEBUG [Unknown] request.security - Attempting to authenticate HttpServerExchange{ GET /infoapi/user/profile request {Connection=[Keep-Alive], Orbeon-Token=[afd4120faad40760c81bf1dccc8972bf84eb75cb], Accept-Encoding=[gzip,deflate], Cookie=[JSESSIONIDSSO=aG7HG-cfiLqOSAfCHL2ouKTb2h6oNHAJd4gkl4aH, $Version=1; JSESSIONID="CHJDiUc4UMQVCkYmHI43Me0E40yHOlIpqN-jrFbi.primary:cpf-server"; $Path="/infoapi"], Cookie2=[$Version=1], Host=[act-e2e]} response {Expires=[0], Cache-Control=[no-cache, no-store, must-revalidate], X-Powered-By=[Undertow/1], Server=[WildFly/11], Pragma=[no-cache]}}, authentication required: true
2019-12-13 14:41:22,643 159574308 DEBUG [Unknown] request.security - Authentication outcome was NOT_ATTEMPTED with method io.undertow.servlet.handlers.security.ServletSingleSignOnAuthenticationMechanism@5e5cb880 for HttpServerExchange{ GET /infoapi/user/profile request {Connection=[Keep-Alive], Orbeon-Token=[afd4120faad40760c81bf1dccc8972bf84eb75cb], Accept-Encoding=[gzip,deflate], Cookie=[JSESSIONIDSSO=aG7HG-cfiLqOSAfCHL2ouKTb2h6oNHAJd4gkl4aH, $Version=1; JSESSIONID="CHJDiUc4UMQVCkYmHI43Me0E40yHOlIpqN-jrFbi.primary:cpf-server"; $Path="/infoapi"], Cookie2=[$Version=1], Host=[act-e2e]} response {Expires=[0], Cache-Control=[no-cache, no-store, must-revalidate], X-Powered-By=[Undertow/1], Server=[WildFly/11], Pragma=[no-cache]}}
2019-12-13 14:41:22,643 159574308 DEBUG [Unknown] request.security - Authentication outcome was NOT_ATTEMPTED with method io.undertow.security.impl.BasicAuthenticationMechanism@7a867338 for HttpServerExchange{ GET /infoapi/user/profile request {Connection=[Keep-Alive], Orbeon-Token=[afd4120faad40760c81bf1dccc8972bf84eb75cb], Accept-Encoding=[gzip,deflate], Cookie=[JSESSIONIDSSO=aG7HG-cfiLqOSAfCHL2ouKTb2h6oNHAJd4gkl4aH, $Version=1; JSESSIONID="CHJDiUc4UMQVCkYmHI43Me0E40yHOlIpqN-jrFbi.primary:cpf-server"; $Path="/infoapi"], Cookie2=[$Version=1], Host=[act-e2e]} response {Expires=[0], Cache-Control=[no-cache, no-store, must-revalidate], X-Powered-By=[Undertow/1], Server=[WildFly/11], Pragma=[no-cache]}}
2019-12-13 14:41:22,643 159574308 DEBUG [Unknown] request.security - Sending authentication challenge for HttpServerExchange{ GET /infoapi/user/profile request {Connection=[Keep-Alive], Orbeon-Token=[afd4120faad40760c81bf1dccc8972bf84eb75cb], Accept-Encoding=[gzip,deflate], Cookie=[JSESSIONIDSSO=aG7HG-cfiLqOSAfCHL2ouKTb2h6oNHAJd4gkl4aH, $Version=1; JSESSIONID="CHJDiUc4UMQVCkYmHI43Me0E40yHOlIpqN-jrFbi.primary:cpf-server"; $Path="/infoapi"], Cookie2=[$Version=1], Host=[act-e2e]} response {Expires=[0], Cache-Control=[no-cache, no-store, must-revalidate], X-Powered-By=[Undertow/1], Server=[WildFly/11], Pragma=[no-cache]}}
2019-12-13 14:41:22,643 159574308 DEBUG [Unknown] request.security - Sending basic auth challenge Basic realm="REST API authentication module" for HttpServerExchange{ GET /infoapi/user/profile request {Connection=[Keep-Alive], Orbeon-Token=[afd4120faad40760c81bf1dccc8972bf84eb75cb], Accept-Encoding=[gzip,deflate], Cookie=[JSESSIONIDSSO=aG7HG-cfiLqOSAfCHL2ouKTb2h6oNHAJd4gkl4aH, $Version=1; JSESSIONID="CHJDiUc4UMQVCkYmHI43Me0E40yHOlIpqN-jrFbi.primary:cpf-server"; $Path="/infoapi"], Cookie2=[$Version=1], Host=[act-e2e]} response {Expires=[0], WWW-Authenticate=[Basic realm="REST API authentication module"], Cache-Control=[no-cache, no-store, must-revalidate], X-Powered-By=[Undertow/1], Server=[WildFly/11], Pragma=[no-cache]}}
2019-12-13 14:41:22,643 159574308 DEBUG [Unknown] request.security - Authentication result was CHALLENGE_SENT for HttpServerExchange{ GET /infoapi/user/profile request {Connection=[Keep-Alive], Orbeon-Token=[afd4120faad40760c81bf1dccc8972bf84eb75cb], Accept-Encoding=[gzip,deflate], Cookie=[JSESSIONIDSSO=aG7HG-cfiLqOSAfCHL2ouKTb2h6oNHAJd4gkl4aH, $Version=1; JSESSIONID="CHJDiUc4UMQVCkYmHI43Me0E40yHOlIpqN-jrFbi.primary:cpf-server"; $Path="/infoapi"], Cookie2=[$Version=1], Host=[act-e2e]} response {Expires=[0], WWW-Authenticate=[Basic realm="REST API authentication module"], Cache-Control=[no-cache, no-store, must-revalidate], X-Powered-By=[Undertow/1], Server=[WildFly/11], Pragma=[no-cache]}}

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

JSESSIONIDSSO=aG7HG-cfiLqOSAfCHL2ouKTb2h6oNHAJd4gkl4aH, $Version=1; JSESSIONID="CHJDiUc4UMQVCkYmHI43Me0E40yHOlIpqN-jrFbi.primary:cpf-server"; $Path="/infoapi"

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

JSESSIONIDSSO=aG7HG-cfiLqOSAfCHL2ouKTb2h6oNHAJd4gkl4aH

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?  This is what is breaking the second request.

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 orbeon+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/orbeon/1576221689342-0.post%40n4.nabble.com.

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

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/orbeon/1576222897769-0.post%40n4.nabble.com.

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
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/orbeon/1576542670536-0.post%40n4.nabble.com.

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.


--
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 view this discussion on the web visit https://groups.google.com/d/msgid/orbeon/1576636334913-0.post%40n4.nabble.com.

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


--
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 view this discussion on the web visit https://groups.google.com/d/msgid/orbeon/1576737149614-0.post%40n4.nabble.com.

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
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/orbeon/1576796624098-0.post%40n4.nabble.com.