Re: [Zope-dev] protocol accesibility
Toby Dickenson wrote:
That's not been my experience, but maybe that How-To would help :-) Care to write it? ;-)
It is on my todo list
cool :-)
Protocol independence is not necessarily a good thing in this case. Different protocols have different capabilities.
The zope way of modelling different capabilities is through roles. The right way to achieve this is to allocate different roles based on protocol.
how do you do that? (refs to how-to's, docs, etc all good, just that I never knew you could do that :-)
You could do this today using LoginManager, which allows for roles to be *computed* during authentication. Give your users different roles depending on whether they use http or https. (
or ftp?
Indeed, I would be keen to see this feature in the standard user folder)
Maybe that's what I should haev said in my proposal ;-)
Note that protocol is not a key factor here: you might also trust them more if the socket connection comes from localhost.
very true
Can you explain *why* this is a problem? While I agree it's untidy, its only an untidyness seen by people who go looking for it.
Some people (or am I the only one ;-) don't really find that acceptable. The paranoid part of me also wants to know that it isn't possible to find this, as it should only be used by other stuff inside zope, why should stuff outside of zope get to play with it?
http://www.cbsnewyork.com/objectIds are left hanging out.
I propose securing the 'access contents information' permission, and you havent explained why this is flawed.
Securing the permission? perhaps you could explain that a bit more :-S
http://www.cbsnewyork.com/rubbish ain't none too nice either, likewise
That document has since been removed.
Nope, that's the point, it give a yucking Zope Error which lowers user confidence, rather than saying 'that page wasn't found, perhaps you'd like to look here or here', but, to be fair, that's because whoever built that site didn't bother to make standard_error_message useful (don't get me started on tacking tracebacks on the end of html generated by that page ;-)
I get an authentication dialog.... so?
Hit cancel. Again, a yucky Zope error rather than saying 'sorry, your username or password were wrong', or, in reference to this thread, not actually being _visible_ to this protocol at all. eg: should raise a 404, as standard_html_header should ;-) cheers, Chris
participants (1)
-
Chris Withers