Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removed the docstring from methods to avoid publishing them [6.0] #3282

Merged
merged 1 commit into from
Jun 21, 2021

Conversation

mauritsvanrees
Copy link
Member

@mister-roboto

This comment has been minimized.

@mauritsvanrees
Copy link
Member Author

@jenkins-plone-org please run jobs

@mauritsvanrees mauritsvanrees mentioned this pull request Jun 18, 2021
34 tasks
@icemac
Copy link

icemac commented Jun 21, 2021

Why not make the methods private by using @security.private? There is zopefoundation/Zope#774 – which is not yet implemented – but it would break this code again.

@gforcada
Copy link
Member

At least for Plone 6 and Zope 5 that would be the perfect timing for doing such a breaking change, otherwise we would have to wait until Plone 7 and Zope 6? 😅 that would be far too long IMHO

@jensens
Copy link
Member

jensens commented Jun 21, 2021

Why not make the methods private by using @security.private?

I think the idea of the PloneTool is to provide functionality to be used in untrusted templates, but are not meant to be directly published. Well, overall today one would write this different.

There are probably multiple places to improve here.

@mauritsvanrees
Copy link
Member Author

I think the idea of the PloneTool is to provide functionality to be used in untrusted templates, but are not meant to be directly published. Well, overall today one would write this different.

Indeed. Untrusted code should be able to call these. But they should not be available at a url, because that would make reflected XSS easy. @security.public without a docstring currently makes this combination possible.

I think this is a valid use case, which would break when docstrings are not required anymore. That does seem the right direction though. And the use case gets less important, because less code is in skins these days. So we could choose to tighten the security in Plone 6, in preparation for stricter handling in Zope. Maybe start saying that doing things in skins is deprecated, and people should move to browser views and resources. (But Plone itself still uses a few skin folders.) That is a wider discussion though, not something for a random PR.

Anyway, for now I think the changes in this PR are fine. Can someone approve?

@gforcada The checks expect a Jenkins Plone 6.0 Python 3.6 job, but this is not supported, so it can be ignored. Do you think this would be fixed by calling "Re-create GitHub commit hooks" on https://jenkins.plone.org/roboto/ ? It is probably safe to try, and I can do that.

@gforcada
Copy link
Member

@mauritsvanrees no not there, that's on the mr.roboto configuration: plone/mr.roboto#81 I will check why 3.6 is still expected for 6.0

@gforcada
Copy link
Member

I see that the configuration looks fine, so it might be a bug on mr.roboto? 🤔

@jensens
Copy link
Member

jensens commented Jun 21, 2021

Didn't we dropped Python 3.6 for Plone 6.0?

@mauritsvanrees
Copy link
Member Author

Didn't we dropped Python 3.6 for Plone 6.0?

Yes we did. Well, officially this is still pending an okay from the framework team. But when we sat with a few people a month or two ago to fix some Jenkins stuff, we removed 3.6 from the checks already. (Could be reactivated if the framework team decides otherwise.)

So the point now is that it is strange that 3.6 is still in the checks here.

I have called the "Re-create GitHub commit hooks" command from mr.roboto, to see if that fixes it. It is still running, because it needs to touch a lot of repositories. I see it is also adding hooks to some Guillotina repositories. I hope that is okay.

Ah, it seems finished, no further logs are coming in. Nothing has changed in this PR, but perhaps in a fresh PR it will work correctly.

Anyway, this PR is approved, I will merge.

@gforcada
Copy link
Member

@mauritsvanrees the hooks are to make repositories (not PR) to mr.roboto, so that whenever an action happens in a repository mr.roboto knows about it, it has nothing to do with which jobs a PR is expected to run 😅

The code for that is https://github.com/plone/mr.roboto/blob/3fd95d071d62f30caf6d55028767cedbde651439/src/mr.roboto/src/mr/roboto/subscriber.py#L375 (I think 😅 I had only a brief look at the code in 2 seconds)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants