Orbeon 4 and authentication & authorization

Dear everybody,

I'm suffering of second degree frustration.

In our setup we have the form, which talks to a servlet called filter
talking to eXist. Filter does a different things, including xsl transforming
documents both at GET and PUT requests (for instance, changing block level
markup to and from HTML respectively, adding xml:id to elements lacking it, filling in the
audit trails and revision histories etc.)

We have Apache in front of the whole, acting as a proxy using AJP. Tomcat
authentication is disabled and Apache does all of that, allowing GET requests
to both filter and orbeon, but use authentication base for PUT and POST to
both applications. In Orbeon 3.9 all credentials are correctly sent to Apache
who forward them to the filter servlet.

We are now about to migrate our MerMEId package [1] from Orbeon 3.9 to 4. In doing
that we've run into a problem I've not been able to solve.

    Services and eXist are now protected [sic!]; could that explain it?

according to a tweet I got from a kind person at orbeon[2]. The wiki describes
a method to reset Orbeon's use of web resources to compatibility mode[3], but
using that doesn't work for us.

What does "protected" mean?

Any attempt to save content returns HTTP status from apache  401, but orbeon
does not respond and the required credentials are not forwarded or not being sent.

Sorry if my mail is a bit annoyed.

Sigfrid

Notes
-----
1. http://labs.kb.dk/editor/
2. https://twitter.com/orbeon/status/312255731950833664
3. http://bit.ly/14dVkdO


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

Hi Sigfrid,

My apologies for the late response! And for the second degree frustration ;). So, you were saying that now with 4.0 your save ends with a 401. As mentioned in that tweet you're referring to, I would first recommend you try disabling the new service protection in 4.0, to see if this is what's causing the problem. Adding the following two properties should do it:

    <property as="xs:string"  processor-name="oxf:page-flow" name="service-public-methods"  value="GET HEAD POST PUT DELETE"/>
    <property as="xs:string"  processor-name="oxf:page-flow" name="page-public-methods"     value="GET HEAD POST PUT DELETE"/>

I am not recommending you go in production with this, but just test to see if this is the cause of the problem. Have you tried? You're saying that "that doesn't work for us": does it mean you tried and it doesn't change anything, or that you just wouldn't like to go to production with those properties?

Alex