Secure persistence API access

I want to pass the current user credentials when accessing an implementation of the persistence API. I was wondering what is the recommended way of doing this?

I see that there are a couple of request parameters, orbeon-username and orbeon-token on the calls to the persistence API.

orbeon-token: 1d6087d6eab20c2930b8774eb25f4c6ae650ae71
orbeon-username: system

I logged in as a user named "system" so that one is obvious but what is the other value? It isn't the session ID as far as I can tell. My web session with Orbeon has two cookies:

JSESSIONIDSSO: 098D3EED5FF25103698274D8F7805FBE
JSESSIONID: F96456823D8BC1E1AC2EFC4E49953C78

so it isn't one of these values. These cookies are not passed on the calls to the persistence API so I cannot use them to validate the session (in other cases where we have server to server calls over HTTP we pass the JSESSIONIDSSO cookie to allow sharing of the current user session).

Is there a way I can use the "orbeon-token" value to validate that the user is what "orbeon-username" says they are?

thanks,
brian wallis...

The Orbeon-Token header is a randomly-generated token generated by Orbeon. It is used so that when Orbeon performs an HTTP request to itself, the destination knows it comes from Orbeon and not an external, non-trusted party.

This token is not useful for anybody but Orbeon itself.

With Orbeon Forms 4.7, which gets rid of internal requests, it is even of less use, except to protect request to the internal eXist database.

You should be able to forward the session cookies with this property:

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

-Erik

Using the "oxf.http.forward-cookies" property doesn't seem to work for the persistence API, no cookies to be seen in the requests. It does work OK for xf:submission requests in a form, I tested various combinations.

Should this setting be working for the persistence API REST calls? I need this to work to get the authentication going.

Interestingly, if you set oxf.http.forward-cookies to the empty string "" in properties-local.xml then it gets the default value of "JSESSIONID JSESSIONIDSSO", I had to set it to a random value, "xxx", to turn it off.

> Using the "oxf.http.forward-cookies" property doesn't seem to work for the persistence API

It seem that the persistence proxy doesn't follow that setting:

    http://goo.gl/vT6LwV

This said, headers/cookies forwarding is tricky, and probably something to be discouraged.

On a first access with an initially non-existing session, for example, we cannot forward the JSESSIONID cookie. So we try to guess the cookie value, and this doesn't work with all containers.

> Interestingly, if you set oxf.http.forward-cookies to the empty string "" in properties-local.xml then it gets the default value of "JSESSIONID JSESSIONIDSSO", I had to set it to a random value, "xxx", to turn it off.

Thanks, this got fixed not long ago:

    https://github.com/orbeon/orbeon-forms/commit/ced06531bb51a6d81f93625d40fb01c11ec9cbc8

-Erik

Erik Bruchez wrote

> Using the "oxf.http.forward-cookies" property doesn't seem to work for the persistence API

It seem that the persistence proxy doesn't follow that setting:

    http://goo.gl/vT6LwV

This said, headers/cookies forwarding is tricky, and probably something to be discouraged.

On a first access with an initially non-existing session, for example, we cannot forward the JSESSIONID cookie. So we try to guess the cookie value, and this doesn't work with all containers.

I know these issues well, it is something our application has to deal with and we have it working quite well including ajax calls and session timeouts using JSESSIONIDSSO rather than JSESSIONID. It is not ideal but it is all we have for the moment.

So can the FormRunnerPersistenceProxy be fixed to forward the cookies? We don't have any other option to know who is making the persistence call and it is essential that we know on who's behalf the the call is being made. I could probably find some other workaround but forwarding JSESSIONIDSSO has proved to be a reasonable solution in our case.

thanks
brian...

I added an RFE:

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

-Erik

This issue is now fixed. The fix will be in Orbeon Forms 4.9.

-Erik