Issue 242: add an @interfaces expandable endpoint

[erral]

See #242

[coveralls]

Coverage increased (+0.02%) to 96.583% when pulling 8b7f54c on issue-242-erral-interfaces into 88a6779 on master.

[coveralls]

Coverage increased (+0.02%) to 96.583% when pulling 8b7f54c on issue-242-erral-interfaces into 88a6779 on master.

[coveralls]

Coverage increased (+0.02%) to 96.583% when pulling 8b7f54c on issue-242-erral-interfaces into 88a6779 on master.

[buchi]

👍 LGTM

I wonder if exposing all those interface names publicly may lead to unwanted information disclosure.

[erral]

Yeah... during the training we wondered if we could restrict somehow the list of exposed interfaces, or at least set a list of known-good-set of interfaces, and expose just them...

[tisto]

@erral we usually try to add a short introduction to non-Plone devs what this documentation section is about. E.g. a short introduction what interfaces are, maybe with a link to the Plone docs.

[tisto]

@erral LGTM as well. Though, as @buchi said, the interfaces are currently not visible by anonymous users. Therefore we might have to think about this...

[erral]

I share your concerns about the public visibility of the interfaces. Nevertheless they are needed, at least to know the navigation contexts when the front-end wants to build the global navigation for instance.

@ebrehault any comment on this?

[coveralls]

Coverage increased (+0.02%) to 96.657% when pulling 5671b33 on issue-242-erral-interfaces into 8a84333 on master.

[coveralls]

Coverage increased (+0.3%) to 96.389% when pulling d855284 on issue-242-erral-interfaces into 41b9bf6 on master.

[tkimnguyen]

What would you recommend as a way of restricting who has access to this?

[jensens]

So, what is the problem with exposing?

Does exposing information about interfaces - and so about installed add-ons and other internals - give attackers hints about possible vulnerabilities outside of the core? But also FTI info and other endpoints expose that information.

I doubt it a problem, but I would love to hear opposing opinions.

[mauritsvanrees]

In PloneHotfix20161129 we removed the docstrings of lots of zope.interface methods and attributes to avoid 'publishing' them, that is making them available for browsers to call. See zopefoundation/Zope#81. In some cases they could really be used for potential harm (setting values), in others it was: better safe than sorry.

Just giving the name of interfaces should be fine. But it does give you info about an object that is useful for a UI but also for potential hackers.
So a way to whitelist some interfaces, or to completely disable this (return an empty list) for the security conscious would be good.

[jensens]

What is the state here? Do we want it or not? If not and hence there was no activity for a long time, I propose to close this PR within next two weeks. If you do not feel OK with this, please speak up and provide us a rough schedule.

[tisto]

@jensens it is something we definitely want. Though, there are lots of things to consider and to discuss. I'd prefer to keep it open. Maybe something that can be discussed at one of the next sprints this year...

[jensens]

This one got forgotten. Is it still valid or meanwhile superseded?

[erral]

I am closing this because the main reason for this, the navigation root thing, has been fixed using another endpoint. If we need to expose the interfaces in the future we can use this code as an inspiration, but we do not need this right now.