Add an exception so that JSON POST requests inside portal_resources don't fail

[djay]

fix for #59, plone.rest breaks uploading files in the plone theme editor

[tisto]

@djay thanks for your contribution! Could you please add a test that helps us understanding the issue? Please add a changelog entry as well, so we get a green build.

[tisto]

@djay we can not merge a pr without a changelog entry that causes the build to fail. I will have to close this issue if there is no further action.

[djay]

@displacedaussie any idea what the usecase for this PR was?

[djay]

@tisto it's to fix #59. We will add a test and look at the breaking tests

[coveralls]

Coverage increased (+0.02%) to 97.772% when pulling 9a025b3 on fix_portal_resources into 324ba38 on master.

[djay]

Most probably a blocker for plone/Products.CMFPlone#2177

[tisto]

@displacedaussie could you please elaborate why this is necessary here? I would like to keep the plone.rest test fixture as lightweight as possible.

[djay]

Otherwise portal_resources doesn't exist. And that is what plone.rest is messing with the traversal of.

[tisto]

@displacedaussie returning a page template on a JSON request violates the HTTP specs (content negotiation). If portal_resource is actually doing this should be fixed in Zope/Plone, not in plone.rest.

[djay]

I don't believe zope/plone is https://github.com/plone/plone.app.theming/blob/master/src/plone/app/theming/browser/themefile.py#L25.

[tisto]

@djay @displacedaussie I think we are fixing this on the wrong level. I understand why it is easier to do this fix in plone.rest instead of on Zope level. Though, Zope/Plone is clearly doing it wrong here IMHO. Did you attempt to try to fix this in Zope directly?

[tisto]

@buchi I would like to hear your opinion here as well if you have time ^^^.

[tisto]

@displacedaussie this is not a POST request. Are you sure this test fails without the fix?

[djay]

@tisto It does look like the test is not really testing the right thing but does indeed give a different result when the fix is not applied.

I believe the source of the request that is causing the problem is

https://github.com/plone/mockup/blob/master/mockup/patterns/upload/pattern.js

called from

https://github.com/plone/mockup/blob/master/mockup/patterns/filemanager/pattern.js

called from

https://github.com/plone/mockup/blob/master/mockup/patterns/thememapper/pattern.js#L319

and all that calls to

https://github.com/plone/plone.app.theming/blob/master/src/plone/app/theming/browser/themefile.py#L25

You can see it is returning a JSON. I think the source of the bug is that plone.rest is overriding this and returning its own JSON?

BTW, @displacedaussie doesn't work with plone anymore. @nngu6036 is new and finishing off this work.

[tisto]

@djay thanks!

https://github.com/plone/plone.app.theming/blob/master/src/plone/app/theming/browser/themefile.py#L25

sets Content-Type to "application/json" which is fine and should not affect plone.rest. The other resources you linked do not have a line that I could check.

Let's go step by step and create a failing test that shows the problem first, then we can discuss how to solve this.

@nngu6036 would you mind creating a new pull request with just a failing test that does the exact same HTTP request that the theme editor does? (you can just check the network tab of chrome and then copy the cURL.

[djay]

Haven't created a test yet but here is what the request looks like

General:
Request URL:http://localhost:8080/Plone/portal_resources/theme/asdsd/themeFileUpload?_authenticator=cdabc0f0a58dd5f5b910d36c2d91bd2452a94479
Request Method:POST
Status Code:200 OK
Remote Address:127.0.0.1:8080
Referrer Policy:no-referrer-when-downgrade

Response headers:
Content-Length:21
Content-Type:application/json
Date:Fri, 16 Feb 2018 08:11:20 GMT
Server:Zope/(2.13.26, python 2.7.14, darwin) ZServer/1.1
X-Frame-Options:SAMEORIGIN

Request headers:
Accept:application/json
Accept-Encoding:gzip, deflate, br
Accept-Language:en-US,en;q=0.9
Authorization:Basic YWRtaW46YWRtaW4=
Cache-Control:no-cache
Connection:keep-alive
Content-Length:2253194
Content-Type:multipart/form-data; boundary=----WebKitFormBoundarymOeiMFE1V2Acr015
Cookie:_pk_id.1.1fff=f9e2a914c3bc1362.1507226287.1.1507226468.1507226287.; __qca=P0-866781254-1511770439608; _ga=GA1.1.1561024462.1511770438
Host:localhost:8080
Origin:http://localhost:8080
Referer:http://localhost:8080/Plone/++theme++asdsd/@@theming-controlpanel-mapper
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36
X-Requested-With:XMLHttpRequest

Query string paramaters:
_authenticator:cdabc0f0a58dd5f5b910d36c2d91bd2452a94479

Request payload:
------WebKitFormBoundarymOeiMFE1V2Acr015
Content-Disposition: form-data; name="file"; filename="Screen Shot 2018-02-16 at 3.08.15 pm.png"
Content-Type: image/png


------WebKitFormBoundarymOeiMFE1V2Acr015--

Given the request content type is not application/json I suspect plone.rest should not affect it.

[petri]

Is merging this PR just a question of having a proper test, or is there still some need for discussion?

Presuming the latter, having read through the discussion so far, it seems to me that this is pretty straightforward. Since plone.rest intercepts publishing traversal to do its things, it is reasonable to assign a degree of responsibility on it to accommodate cases such as this (=helping fix broken theme file uploads that it's causing). It's already checking for a number of special cases anyway, so portal_resources is just one more.

Just to look at both sides of the question, the other option is, as far as I can see, implement IContentish support for everything that makes up the /portal_resources//theme/some-theme-name-here path, so that plone.rest would just happily stay out of the way. But that does not seem practical to me unless someone wants to step up for the task.

[tisto]

@petri plone.app.theming is using the accept header "application/json" and violates common HTTP and REST API best practices (replying with 200 OK for an error and sending an error or success message in the body if I am not mistaken) for a trivial call:

https://github.com/plone/plone.app.theming/blob/master/src/plone/app/theming/browser/themefile.py#L25

Fixing this in plone.app.theming is trivial and introducing a workaround in plone.rest is wrong in my opinion since it blesses violating common standards and best practices that plone.rest relies on. We can not add workarounds in plone.rest just because developers lack an understanding of the basics of HTTP and REST.

Therefore the quickest way to solve this issue is to fix plone.app.theming.

[tisto]

I will close this PR because it is not going to be merged into plone.rest. There is a plone.app.theming issue and this is how it should be fixed:

plone/plone.app.theming#165 (comment)

[mister-roboto]

@djay thanks for creating this Pull Request and help improve Plone!

To ensure that these changes do not break other parts of Plone, the Plone test suite matrix needs to pass.

Whenever you feel that the pull request is ready to be tested, either start all jenkins jobs pull requests by yourself, or simply add a comment in this pull request stating:

@jenkins-plone-org please run jobs

With this simple comment all the jobs will be started automatically.

Happy hacking!