Orbeon Forms community mailing list

orbeon connects to persistency differently for xml vs attachments

Classic

List

Threaded

3 messages Options

koenvdk

orbeon connects to persistency differently for xml vs attachments

Hi,

I've noticed something peculiar in the way orbeon forms talks to the persistency layer. I don't know if this could be a bug, or that maybe it has already changed in 4.0 (I'm using 3.9.1).

I've implemented my own persistency layer in Java, which runs on the same server as orbeon, but in a different context. For now, this app does not require authorization (but is protected from the outside by an apache load balancer). Authorization in Orbeon is turned on (but only using url-based protection in web.xml; so it's using the default header-based auth).

Now, when orbeon uses the persistency layer for 'regular' data (xml files), and I request the security info from the incoming request in my app, I get the expected result (I can get the Principal, the remoteUser, and I can use isUserInRole(), should I need to).

But when orbeon stores or retrieves a static resource, such as the logo for a form in the form builder, it does not send along the security information to the persistency layer. In fact, I've noticed (from reading the stored data.xml of form.xhtml) that the resource gets referred to in the form as an absolute url to the persistency layer. This is unfortunate, as it means I can't change the address of the persistency layer without invalidating existing forms. Note, I had the configure the persistency using an url starting with http://localhost:8080/etc. Using something relative did not work, as orbeon's url rewriting places its own context in front of relative urls (and using /../ had its own problems).

Anyway; the latter is, I think, the least of the problems. For me, at the moment, I think not getting the security related information in the case of attachments is the biggest problem. Can I circumvent this using configuration? Am I perhaps missing some security-stuff in my own persistency implementation?

Sincerely,

Koen Vanderkimpen

Connect:



	Overeenkomstig de bepalingen inzake de vertegenwoordiging van de vzw in haar statuten, kan enkel de gedelegeerde bestuurder, de algemeen directeur of zijn uitdrukkelijke lasthebber verbintenissen aangaan namens Smals. Indien dit bericht niet voor u bestemd is, verzoeken wij u dit onmiddellijk aan ons te melden en het bericht te vernietigen. Conformément aux dispositions relatives à la représentation de l'asbl dans ses statuts, seul l'administrateur délégué, le directeur général ou son mandataire exprès est habilité à souscrire des engagements au nom de Smals. Si ce message ne vous est pas destiné, nous vous prions de nous le signaler immédiatement et de détruire le message. According to the provisions regarding representation of the non profit association in its bylaws, only the chief executive officer, the general manager or his explicit agent can enter into engagements on behalf of Smals. If you are not the addressee of this message, we kindly ask you to signal this to us immediately and to delete the message.

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

Erik Bruchez

Re: orbeon connects to persistency differently for xml vs attachments

Administrator

Koen,

Since the request is an HTTP request, security information must somehow travel through the wire. I assume here that what is missing is the session id. Can you check that?

-Erik

On Mon, Jun 18, 2012 at 8:07 AM, <[hidden email]> wrote:

Hi,

I've noticed something peculiar in the way orbeon forms talks to the persistency layer. I don't know if this could be a bug, or that maybe it has already changed in 4.0 (I'm using 3.9.1).

I've implemented my own persistency layer in Java, which runs on the same server as orbeon, but in a different context. For now, this app does not require authorization (but is protected from the outside by an apache load balancer). Authorization in Orbeon is turned on (but only using url-based protection in web.xml; so it's using the default header-based auth).

Now, when orbeon uses the persistency layer for 'regular' data (xml files), and I request the security info from the incoming request in my app, I get the expected result (I can get the Principal, the remoteUser, and I can use isUserInRole(), should I need to).

But when orbeon stores or retrieves a static resource, such as the logo for a form in the form builder, it does not send along the security information to the persistency layer. In fact, I've noticed (from reading the stored data.xml of form.xhtml) that the resource gets referred to in the form as an absolute url to the persistency layer. This is unfortunate, as it means I can't change the address of the persistency layer without invalidating existing forms. Note, I had the configure the persistency using an url starting with http://localhost:8080/etc. Using something relative did not work, as orbeon's url rewriting places its own context in front of relative urls (and using /../ had its own problems).

Anyway; the latter is, I think, the least of the problems. For me, at the moment, I think not getting the security related information in the case of attachments is the biggest problem. Can I circumvent this using configuration? Am I perhaps missing some security-stuff in my own persistency implementation?

Sincerely,

Koen Vanderkimpen
Connect:

Overeenkomstig de bepalingen inzake de vertegenwoordiging van de vzw in haar statuten, kan enkel de gedelegeerde bestuurder, de algemeen directeur of zijn uitdrukkelijke lasthebber verbintenissen aangaan namens Smals.
Indien dit bericht niet voor u bestemd is, verzoeken wij u dit onmiddellijk aan ons te melden en het bericht te vernietigen.

Conformément aux dispositions relatives à la représentation de l'asbl dans ses statuts, seul l'administrateur délégué, le directeur général ou son mandataire exprès est habilité à souscrire des engagements au nom de Smals.
Si ce message ne vous est pas destiné, nous vous prions de nous le signaler immédiatement et de détruire le message.

According to the provisions regarding representation of the non profit association in its bylaws, only the chief executive officer, the general manager or his explicit agent can enter into engagements on behalf of Smals.
If you are not the addressee of this message, we kindly ask you to signal this to us immediately and to delete the message.

koenvdk

Re: Re: orbeon connects to persistency differently for xml vs attachments

Hi Eric,

After a request for our form cbpl/aanstalling-consulent/new, follows a request for the "form.xhtml" to our persistency layer, with the following headers (this is an excerpt from our logs):

<<<<<
2012-08-10 15:51:19,795 - Headers:
- cookie : JSESSIONID=37F0DE4BD74F640ED6AE91C05AC4914C; JSESSIONIDSSO=CD0D2D23F683219CE15C83ABC66AE4D2
- host : localhost:8080
- connection : Keep-Alive
- cookie2 : $Version=1

- Http method called: GET
- request Path: /crud/cbpl/aanstelling-consulent/form/form.xhtml
2012-08-10 15:51:19,898 INFO Timing - GET /crud/cbpl/aanstelling-consulent/form/form.xhtml duration: 104
2012-08-10 15:51:19,899 INFO Timing - Average since Wed Aug 08 10:40:28 CEST 2012: 423
>>>>>

A bit later, we get a request for a picture in the form:
<<<<<
2012-08-10 15:51:46,626 - Headers:
- host : localhost:8080
- connection : Keep-Alive

- Http method called: GET
- request Path: /crud/orbeon/builder/data/cb62d11d5bafb489d828b42e7a2b9db4/6e9a0d8dd04c828524f0b197d203f294.jpg
2012-08-10 15:51:46,943 INFO Timing - GET /complex/crud/orbeon/builder/data/cb62d11d5bafb489d828b42e7a2b9db4/6e9a0d8dd04c828524f0b197d203f294.jpg duration: 317
2012-08-10 15:51:46,944 INFO Timing - Average since Tue Aug 07 13:46:57 CEST 2012: 327
>>>>>

So no, I don't get the session id for the second request, which is definitely related to the first, as both resources are needed to show the form on screen. is this normal?
Also, as you can see, there are no orbeon-username and orbeon-role headers anywhere. I do get these headers when I get a request for a "data.xml", but even then they are empty. Why does this seem so random? :-)

(I can, however, get the username via Java's request.getUserPrincipal(); (we are using single sign on).)

Sincerely,

Koen Vanderkimpen
Research/Recherche/Onderzoek

Connect:

From: Erik Bruchez <[hidden email]>
To: [hidden email]
Date: 19/06/2012 07:35
Subject: [ops-users] Re: orbeon connects to persistency differently for xml vs attachments
Sent by: [hidden email]

Koen,

Since the request is an HTTP request, security information must somehow travel through the wire. I assume here that what is missing is the session id. Can you check that?

-Erik

On Mon, Jun 18, 2012 at 8:07 AM, <Koen.Vanderkimpen@...> wrote:
Hi,

I've noticed something peculiar in the way orbeon forms talks to the persistency layer. I don't know if this could be a bug, or that maybe it has already changed in 4.0 (I'm using 3.9.1).

I've implemented my own persistency layer in Java, which runs on the same server as orbeon, but in a different context. For now, this app does not require authorization (but is protected from the outside by an apache load balancer). Authorization in Orbeon is turned on (but only using url-based protection in web.xml; so it's using the default header-based auth).

Now, when orbeon uses the persistency layer for 'regular' data (xml files), and I request the security info from the incoming request in my app, I get the expected result (I can get the Principal, the remoteUser, and I can use isUserInRole(), should I need to).

But when orbeon stores or retrieves a static resource, such as the logo for a form in the form builder, it does not send along the security information to the persistency layer. In fact, I've noticed (from reading the stored data.xml of form.xhtml) that the resource gets referred to in the form as an absolute url to the persistency layer. This is unfortunate, as it means I can't change the address of the persistency layer without invalidating existing forms. Note, I had the configure the persistency using an url starting with http://localhost:8080/etc. Using something relative did not work, as orbeon's url rewriting places its own context in front of relative urls (and using /../ had its own problems).

Anyway; the latter is, I think, the least of the problems. For me, at the moment, I think not getting the security related information in the case of attachments is the biggest problem. Can I circumvent this using configuration? Am I perhaps missing some security-stuff in my own persistency implementation?

Sincerely,

Koen Vanderkimpen

Connect:



	Overeenkomstig de bepalingen inzake de vertegenwoordiging van de vzw in haar statuten, kan enkel de gedelegeerde bestuurder, de algemeen directeur of zijn uitdrukkelijke lasthebber verbintenissen aangaan namens Smals. Indien dit bericht niet voor u bestemd is, verzoeken wij u dit onmiddellijk aan ons te melden en het bericht te vernietigen. Conformément aux dispositions relatives à la représentation de l'asbl dans ses statuts, seul l'administrateur délégué, le directeur général ou son mandataire exprès est habilité à souscrire des engagements au nom de Smals. Si ce message ne vous est pas destiné, nous vous prions de nous le signaler immédiatement et de détruire le message. According to the provisions regarding representation of the non profit association in its bylaws, only the chief executive officer, the general manager or his explicit agent can enter into engagements on behalf of Smals. If you are not the addressee of this message, we kindly ask you to signal this to us immediately and to delete the message.

-- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe:[hidden email]For general help:[hidden email]OW2 mailing lists service home page:http://www.ow2.org/wws



	Overeenkomstig de bepalingen inzake de vertegenwoordiging van de vzw in haar statuten, kan enkel de gedelegeerde bestuurder, de algemeen directeur of zijn uitdrukkelijke lasthebber verbintenissen aangaan namens Smals. Indien dit bericht niet voor u bestemd is, verzoeken wij u dit onmiddellijk aan ons te melden en het bericht te vernietigen. Conformément aux dispositions relatives à la représentation de l'asbl dans ses statuts, seul l'administrateur délégué, le directeur général ou son mandataire exprès est habilité à souscrire des engagements au nom de Smals. Si ce message ne vous est pas destiné, nous vous prions de nous le signaler immédiatement et de détruire le message. According to the provisions regarding representation of the non profit association in its bylaws, only the chief executive officer, the general manager or his explicit agent can enter into engagements on behalf of Smals. If you are not the addressee of this message, we kindly ask you to signal this to us immediately and to delete the message.