Response says forbidden on Jackrabbit >= 2.12.4 about jackalope-jackrabbit HOT 21 CLOSED

yay, 1.3.0 is now tagged!

from jackalope-jackrabbit.

we noticed issues with newest jackrabbit versions - the version number sounds familiar to me... CSRF and forbidden could indeed be related. you would need to dig through the transport to see if we do anything at all about CSRF atm - i'd think we don't.

from jackalope-jackrabbit.

Do you have any resources where that would have been done? Can't find any jackrabbit documentation about that. So I don't have an idea what I should be looking at 😕

from jackalope-jackrabbit.

from jackalope-jackrabbit.

i have the same error jackrabbit 2.13.4
hope we / jackrabbit can fix this soon.
ok this work as workaround
http://stackoverflow.com/questions/18331871/apache-jackrabbit-throws-403-in-webdav-anonymous-access

from jackalope-jackrabbit.

I just tried to find out where I have to put the CSRF token, but I have no idea... I have used wireshark to compare the requests sent from the jackrabbit client itself (java -jar jackrabbit-standalone-2.12.5.jar --cli http://localhost:8080/server) and the doctrine phpcr shell for a simple ls command.

What came to my mind is that there were different HTTP methods used (phpcr-shell used POST whereby jackrabbit client used GET), and that the one from the phpcr-shell had a content type of application/x-www-form-urlencoded whereby the jackrabbit client didn't set a content type at all.

Tried to only change that, and got something that looks like a correct response:

    {":jcr:mixinTypes":"Name","jcr:mixinTypes":["rep:AccessControllable"],":jcr:primaryType":"Name","jcr:primaryType":"rep:root","jcr:system":{},"rep:policy":{}}

However, I got the following error message on the phpcr-shell:

[Symfony\Component\Debug\Exception\ContextErrorException] Notice: Undefined property: stdClass::$nodes

Which might be because there are no nodes at all currently, and the shell doesn't seem to handle that. However, that didn't make other commands to work, so it's probably a harder task to fix that :-/

UPDATE: Just for reference, I was changing this stuff at this line and two lines over that.

from jackalope-jackrabbit.

you could try to ask the jackrabbit developers what changed. the more precise you can pinpoint between which versions this starts failing, the better chance of somebody finding out why. with that information we might find out what we should do on our end.

from jackalope-jackrabbit.

I've written a mail to the users mailing list of jackrabbit, I'll update the information here as soon as I get any new information.

from jackalope-jackrabbit.

Jackrabbit's CSRF protection affects any write request that could come from an HTML form, that is method==POST and content type is any of the HTML form content types.

There is no CSRF token support in Jackrabbit.

The simplest possible fix probably is to include a Referer header field (referencing the server itself).

from jackalope-jackrabbit.

@danrot did you have a chance to try the Referer header?

from jackalope-jackrabbit.

Not yet... I am afraid that there are some places to touch... But at least it should only be the Client class, right?

from jackalope-jackrabbit.

from jackalope-jackrabbit.

Can't we close this issue, since the linked PR fixed it?

from jackalope-jackrabbit.

yep, we can \o/

from jackalope-jackrabbit.

@dbu : this PR is not in the version 1.2.2 , when will be release the 1.2.3, thank's ?

from jackalope-jackrabbit.

i am about to release 1.3 but there is some regression that popped up and has to be fixed before i can release.

from jackalope-jackrabbit.

Ok, so It's 2019 we have legacy project with jackrabbit version 2.8.0 on production and I've tried to ship it through docker for local/dev environment for further work in this project.

I couldn't find version 2.8.0 on the server http://apache-mirror.rbc.ru/pub/apache/jackrabbit/ so I've used 2.8.10 but at the end using phpcr-shell I've experienced the same error mentioned in this github therad.

I thought that It was something with php library (half of the day wasted for nothing) but at the end It turned out that after building docker image with production jar file (2.8.0) solved the problem.

To make long story short: In my case It turned out that you shouldn't assume that jackrabbit team is really testing very well their code and they definitely can introduce breaking changes with patch update according SEMVER.

from jackalope-jackrabbit.

thanks for the report. yeah unfortunately the jackrabbit people seem to not care all that much about the http stack of jackrabbit :-(
glad you found a solution that works for you.

from jackalope-jackrabbit.

Sorry, that is BS.

The change for JCR-4009 was addressing a CVE - a security issue. I also think that we've been clear about what needs to be fixed in the client to continue working.

Also, past (and outdated) releases are still available, just read what the downloads page says, and you'll find them at http://archive.apache.org/dist/jackrabbit/.

Finally, please be aware of http://jackrabbit.apache.org/jcr/jackrabbit-roadmap.html - there will be no updates for 2.8 after Spring 2020, so it would really good to move to a version which is not that ancient.

from jackalope-jackrabbit.

sorry @reschke i did not read up on the history of this ticket. you are right, while this is breaking things, it was necessary for security reasons.

from jackalope-jackrabbit.

ack and thanks for clarifying.

from jackalope-jackrabbit.