Hello, There's a very nearly "orphaned proposal": http://dev.zope.org/Wikis/DevSite/Proposals/SiteAccessUsuabilityImprovements iMeme has already done some work towards these goals with "SiteAccessEnhanced": http://www.zope.org/Members/sfm/SiteAccessEnhanced I am taking over this effort, and I have some near-term "goals outlined": http://dev.zope.org/Wikis/DevSite/Proposals/SiteAccessProposedSolutions I intend to deliver the VHM improvements before the AccessRule improvements. Please give feedback on this proposal, and let me know what I need to do to move this into the project phase. Thanks, -- ethan mindlace fremen | iMeme - The most full featured Zope Host http://mindlace.net | Root, ZEO, MySQL, Mailman, Unlimited Domains iMeme Partner | http://iMeme.net "It is our desire to remain what we are that limits us. -- Project 2501"
I haven't been very deep down into site access things, mainly because I get confused each time I try to set up a SiteRoot. :-) So it may be that some of the features I'd like are already availiable, but that I just didn't know. :-) Anyway, this is what I would like: The virtual hosts of Zope is managed from the Control Panel and not from several objects in several directories. This would mean that if you enter incorrect information, you don't have to reboot the server with SUPPRESS_SITEROOT=1 set in the environment to fix the stupid errors you made, you just go into the Control Panel and fix it.It also means that a customer of a web hotel can't fiddle around with his own SiteRoot. God eh? :-) This Control Panel thingy should also have a possibility to turn on and off individual virtual host mappings without removing the settings, as well as a global on/off. Hope these ideas are useful. ----- Original Message ----- From: "emf" <mindlace@imeme.net> To: <zope-dev@zope.org>; <evan@zope.com> Sent: Saturday, November 24, 2001 9:13 AM Subject: [Zope-dev] SiteAccess improvements
Hello,
There's a very nearly "orphaned proposal":
http://dev.zope.org/Wikis/DevSite/Proposals/SiteAccessUsuabilityImprovements
iMeme has already done some work towards these goals with "SiteAccessEnhanced": http://www.zope.org/Members/sfm/SiteAccessEnhanced
I am taking over this effort, and I have some near-term "goals outlined": http://dev.zope.org/Wikis/DevSite/Proposals/SiteAccessProposedSolutions
I intend to deliver the VHM improvements before the AccessRule
improvements.
Please give feedback on this proposal, and let me know what I need to do to move this into the project phase.
I like this point. SiteAccess should kick an error if you do something stupid, but not lock you out of the ZMI. Maybe, "authenticated" gets a 'manage' wrapper(header/footer) around the AccessRule <dtml-unless "REQUEST.path[0][:6]=='manage' or REQUEST.path[-1][:6]=='manage'"> ...the AccessRule </dtml-unless> -Trevor
-----Original Message----- From: zope-dev-admin@zope.org [mailto:zope-dev-admin@zope.org]On Behalf Of Lennart Regebro Sent: Saturday, November 24, 2001 7:00 PM To: zope-dev@zope.org; emf Subject: Re: [Zope-dev] SiteAccess improvements
I haven't been very deep down into site access things, mainly because I get confused each time I try to set up a SiteRoot. :-) So it may be that some of the features I'd like are already availiable, but that I just didn't know. :-)
Anyway, this is what I would like:
The virtual hosts of Zope is managed from the Control Panel and not from several objects in several directories. This would mean that if you enter incorrect information, you don't have to reboot the server with SUPPRESS_SITEROOT=1 set in the environment to fix the stupid errors you made, you just go into the Control Panel and fix it.It also means that a customer of a web hotel can't fiddle around with his own SiteRoot. God eh? :-) This Control Panel thingy should also have a possibility to turn on and off individual virtual host mappings without removing the settings, as well as a global on/off.
Hope these ideas are useful.
----- Original Message ----- From: "emf" <mindlace@imeme.net> To: <zope-dev@zope.org>; <evan@zope.com> Sent: Saturday, November 24, 2001 9:13 AM Subject: [Zope-dev] SiteAccess improvements
Hello,
There's a very nearly "orphaned proposal":
http://dev.zope.org/Wikis/DevSite/Proposals/SiteAccessUsuabilityIm provements
iMeme has already done some work towards these goals with "SiteAccessEnhanced": http://www.zope.org/Members/sfm/SiteAccessEnhanced
I am taking over this effort, and I have some near-term "goals outlined": http://dev.zope.org/Wikis/DevSite/Proposals/SiteAccessProposedSolutions
I intend to deliver the VHM improvements before the AccessRule improvements.
Please give feedback on this proposal, and let me know what I need to do to move this into the project phase.
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Hi!
I haven't been very deep down into site access things, mainly because I get confused each time I try to set up a SiteRoot. :-) So it may be that some of the features I'd like are already availiable, but that I just didn't know. :-)
Anyway, this is what I would like:
The virtual hosts of Zope is managed from the Control Panel and not from several objects in several directories. This would mean that if you enter incorrect information, you don't have to reboot the server with SUPPRESS_SITEROOT=1 set in the environment to fix the stupid errors you made, you just go into the Control Panel and fix it.It also means that a customer of a web hotel can't fiddle around with his own SiteRoot. God eh? :-) This Control Panel thingy should also have a possibility to turn on and off individual virtual host mappings without removing the settings, as well as a global on/off.
Basically this is possible using our VirtualSiteRoot Product, which can be found at http://www.zope.org/Members/comlounge/ It does not actually install the config in the control panel but in the parent directory. It also lets you setup different roots for management and public access. So it's e.g. possible to use the management screens via https:// and the public access is still working via http://. Also included is some plugin mechanism e.g. for automatically inserting session ids in the URL. cheers, Christian -- COM.lounge http://comlounge.net/ communication & design info@comlounge.net
I'd love to comment, but I can't read it due to the Omni font bug at zope.org... (http://collector.zope.org/Zope/26)
From: emf <mindlace@imeme.net>
I am taking over this effort, and I have some near-term "goals outlined": http://dev.zope.org/Wikis/DevSite/Proposals/SiteAccessProposedSolutions
I just had a thread about SiteAccess that resulted with Dieter suggesting I rewrite SiteAccess as an External Method to get around security limitations.
The security context is set after URL traversal. At least, it is not easy to set it before. This prevents the manipulation of session variables. In my case, I am using embedded session variables and writing it to a database.
So, based on my current requirement, I request to put more security options in SiteAccess, to allow AccessRules to be used during URL traversal. Allow the Security tab context to apply to AccessRules, so they can be executed by "Anonymous User". my $.02. -Trevor
-----Original Message----- From: zope-dev-admin@zope.org [mailto:zope-dev-admin@zope.org]On Behalf Of emf Sent: Saturday, November 24, 2001 3:13 AM To: zope-dev@zope.org; evan@zope.com Subject: [Zope-dev] SiteAccess improvements
Hello,
There's a very nearly "orphaned proposal": http://dev.zope.org/Wikis/DevSite/Proposals/SiteAccessUsuabilityIm provements
iMeme has already done some work towards these goals with "SiteAccessEnhanced": http://www.zope.org/Members/sfm/SiteAccessEnhanced
I am taking over this effort, and I have some near-term "goals outlined": http://dev.zope.org/Wikis/DevSite/Proposals/SiteAccessProposedSolutions
I intend to deliver the VHM improvements before the AccessRule improvements.
Please give feedback on this proposal, and let me know what I need to do to move this into the project phase.
Thanks, -- ethan mindlace fremen | iMeme - The most full featured Zope Host http://mindlace.net | Root, ZEO, MySQL, Mailman, Unlimited Domains iMeme Partner | http://iMeme.net "It is our desire to remain what we are that limits us. -- Project 2501"
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Trevor Toenjes wrote:
This prevents the manipulation of session variables. In my case, I am using embedded session variables and writing it to a database.
So, based on my current requirement, I request to put more security options in SiteAccess, to allow AccessRules to be used during URL traversal. Allow the Security tab context to apply to AccessRules, so they can be executed by "Anonymous User".
I didn't see that thread. I'm not sure how you can get what you want- the whole idea of access rules is that they apply before traversal. What do you want to happen during traversal? -- ethan mindlace fremen | iMeme - The most full featured Zope Host http://mindlace.net | Root, ZEO, MySQL, Mailman, Unlimited Domains iMeme Partner | http://iMeme.net "It is our desire to remain what we are that limits us. -- Project 2501"
What do you want to happen during traversal? Evan's Embedded Session Values is his suggested use of SiteAccess2 http://www.zope.org/Members/4am/SiteAccess2/otheruse
I simply need to add a <dtml-var smallscript>(writing to a database) after a valid SessionID is set. However, 'smallscript' cannot be executed from the AccessRule because security is not set yet. The user gets a Zope login prompt and then a Site Error An error was encountered while publishing this resource. Unauthorized You are not authorized to access the_database "AccessRule" with ***smallscript*** <dtml-let stack="REQUEST['TraversalRequestNameStack']"> Don't intercept management requests <dtml-unless "stack[0][:6]=='manage'"> Is the next path segment a positive integer? <dtml-if "_.int(stack[-1])>0"> Save it and remove it from the path <dtml-call "REQUEST.set('SessionID', stack.pop())"> Add it back into the logical path <dtml-call "REQUEST.setVirtualRoot(REQUEST.steps+[SessionID])"> *** <dtml-var smallscript> *** <dtml-else> <dtml-raise type="Invalid">Invalid Session ID!</dtml-raise> </dtml-if> </dtml-unless> </dtml-let> For example purposes, this is 'smallscript': <dtml-call "the_database.setRow(sessID=_.render(SessionID), timestamp='time', IP=_.render(REMOTE_ADDR))"> -Trevor
participants (5)
-
cs＠comlounge.net -
emf -
Lennart Regebro -
marc lindahl -
Trevor Toenjes