REST API in Plone 5.2

I saw was removed from the list of blockers, so I re-add it.

seems to me the Framework Team thinks this is not serious, but I strongly disagree.

what are the thoughts of the Security Team?

@tisto replied here

@hvelarde as said many many times already, I don't get your point. Plone 5.2 ships with plone.restapi. If you want to use it, you should deploy it properly and make it available under "/api". You will have classic Plone and plone.restapi completely separated and there is no way in the world you can poison your cache.

I am happy to add a deployment best-practices section to the plone.restapi docs if that helps. We are using plone.restapi in production since its pre-alpha state and we never ran into that problem, because we always deploy it under /api and do not mix up things. The issue you are describing is super complex to solve, there is no general agreement what to do and the simple solution is just to follow best practices when it comes to deploying REST APIs.

1 Like

I don't consider that a reply at all; please read the issue and try to understand it.

I know it's not easy, but kicking the can down the road is not an option now the REST API is part of the Plone core and the package is being distributed with Plone 5.2.

Yes, please, that would help. I would have no idea how to do this. Based on reading the issue a while ago, I expected that the solution would be to add a traversal hook or whatever in plone.restapi so that it answers on /api. Preferably at the same time it would not answer on any other url.
Now it sounds like you want admins to solve this in nginx/apache. Maybe by redirecting all json traffic to /api? But wouldn't that break json calls to non-plone-restapi stuff?

1 Like

Adding a traversal hook to is actually the way to go I think. This has been on my todo list since quite a while. It would also make debugging easier because you can see the actual requests right in the browser and you don't need to use curl.

I don't want to start an argument here because Hector is a super nice guy in person. Truth is though that his behavior regarding that issue reduces my motivation to work on it (in my very limited free time) to zero.

This issue is and never was a blocker.

Regarding existing calls. I would keep the content negotiation part of in place. You can use both content negotiation and the /api hook to trigger

I created an issue in the issue tracker:

Please let's try to keep the technical discussion there.

1 Like