I can change the accessibility link to be behind login page through zmi: /portal_actions/site_actions/contact, but a user can still bypass login by going directly to the link site/contact-info. How can I prevent this?
Could you explain why you want to prevent people from using the contact form?
Could you explain why a website that is designed as intranet (workflow is intranet) needs the contact form to be public?
So that a user who was having issues authenticating had a direct way to ask for help?
So that in a scenario that you have not anticipated, a visitor can reach out to you?
In my my experience, this is a useful feature and the significant upside outweighs the trivial downside.
I have been asked to disable it by clients, and when I have been unable to dissuade them we have always ended up re-instating it for one reason or another.
1 Like
Thanks, that is what I was getting at (asking "why" instead of trying to immediately jump into a narrower "how").
At Wildcard we run some internal client sites that are shielded completely from the public. You have to log into the shield before being able to get to the site. That protects the entirety of the site, including all the other usually public views on a Plone/Castle site.
I wonder if https://docs.plone.org/develop/plone/views/browserviews.html#registering-a-view gives hints on how you could use ZCML to change the contact-info view's permission from
permission="zope2.Public"
(...though I don't immediately see what to change it to in permissions.zcml)
Or maybe you could customize contact-info.pt and add a tal:condition that the viewer is not anonymous.
Thank you. I'll try that.
In addition to the contact-info form, the following 'views' (not content items) are still publicly visible after selecting the intranet workflow for a plone 5 site: accessibility, search, site-errors (such as 404).
While you may be correct there are potential benefits for contact-info to remain accessible, it seems that for an intranet workflow there should be a straightforward way to prevent anonymous access to these views.
While we can create code to override perms for each view individually, this seems unwieldy. We're looking at https://github.com/collective/iw.rejectanonymous, but it doesn't claim plone 5 compatibility. Another option is implementing our single sign-on at the web-server proxy layer, but it just seems like a platform with as much flexibility as plone should provide a better solution for what seems an obvious use case.
1 Like
It's an interesting question: whether to make an intranet available on the public internet. You could argue that it makes it easier to access (without needing a VPN), encouraging its use, but then if it's easier to access, it's easier to jiggle the doorknobs and DDoS it.
I would think that if you are worried about someone seeing the accessibility page, search, contact form, then you should put the site inside your network / require a VPN or as you say (and as we have done) put it behind a proxy that requires authentication.
If you wanted to create a PLIP... 
Agreed.
I try not to monkey around too much with this part of the machinery of Plone, on the basis that it is a pretty secure system and my job is to not take the risk of breaking that security unless there is a very good justification - so I would definitely address this concern /outside/ Plone itself.
I understand the framework team's reluctance to include everything in core. It means more switches, settings, and complicated testing. At some point we have to agree that Plone core is just that: "core" features, not everything including the kitchen sink. When I look at Odoo, I'm reminded of Plone 10 years ago: super popular but also attempting to do everything, and doing it not so well.
That's your self call to action to port it? 
That's your self call to action to port it?
I'm not opposed to this (and we're investigating how difficult it might be)... more curious if the consensus is that this is the 'right' way to achieve our goal. I thought this might be a common use case for a plone-based intra/extra-net and hoped there may be an obvious way to globally require authentication. We'll need to ensure that whatever approach we use is very secure, so modifying low level zope calls may not be our best option.
@tkimnguyen I'm curious about the web proxy approach. If we go this route we'll likely implement apache mod_auth_cas as this is our current SSO platform. Do you use webserverauth (or similar) in plone to accept the logged in user from the proxy, implement a compatible SSO in plone, or just require an additional login?
I guess last question would be, could this be as simple as turning off aquire for all permissions granted to anonymous in plone? Anyone done this before?
@tkimnguyen IMO none of search, contact, accessibility etc should be built in. Part of the GSOC for customised listings and search is to make the capability of creating your own search and listings builtin without hard coding it inside plone. Contact form should either be removed or a similar function allow simple forms to be created should be built in. Accessibility makes no sense to be built in. In the very least it should a theme specific page as it is only relevant if you use the default theme. As soon as you customise the theme you can break any of those statements.
1 Like
We use nginx for almost everything and the only time we have used WebServerAuth was to support an edu client. Let me get answers to your other questions.
Maybe you could try it and let us know how it worked 