RE: [Zope-dev] SiteAccess improvements
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=InvalidInvalid 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
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 )
RE: [Zope-dev] SiteAccess improvements
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Lennart Regebro Sent: Saturday, November 24, 2001 7:00 PM To: [EMAIL PROTECTED]; 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 [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] 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 - [EMAIL PROTECTED] 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 ) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] SiteAccess improvements
Gary Poster writes: Hi. My main project right now is actually to build a VHM replacement for myself to solve some needs I had. . * I need the ability to store arbitrary properties for each virtual host. In particular, the correlary of my current work is to provide a CMFVirtualHost tool that stores a sub-portal title, sub-portal skin information, and other items. * I need the ability to have multiple domains point to the same folder, while ideally maintaining the arbitrary properties I expect these two requirements are already possible without any modification to VRM. Assume, your destination folder is I (for implementation) and you have configuation objects C1, C2, ... one for each of your virtual domains D1, D2, ... The configuration objects could be any object capable of holding the configuration information and inheriting from Acquisition.Implicit Then you rewrite your virtual domain URL for Di into VirtualHostBase/Di/Ci/I/VirtualHostRoot Due to the magic of acquisition, your should get the configuration into your implementing I. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] SiteAccess improvements
Gary Poster wrote: * I need the ability to store arbitrary properties for each virtual host. In particular, the correlary of my current work is to provide a CMFVirtualHost tool that stores a sub-portal title, sub-portal skin information, and other items. hmm.. I can see why you might want to do this. it's not clear to me that this is where it should be done. I'd submit that a SiteMonster like thing would be more appropriate, as skinnish things, imho, probably want to live where an appropriately delegated manager can get at them (the target folder, not the root folder/control panel) * I need the ability to have multiple domains point to the same folder, while ideally maintaining the arbitrary properties The current/enhanced VHM has this ability * while I'm at it, some regex capability seemed like a reasonable addition. I hope to come up with a clean UI way of doing regex substitutions (\1 etc.) as well: anythingNotWww.myhost.com tries to go to /myCMF/members/anythingNotWww, for instance. Well ... right now we just have subdomain globbing, so if you had two rules: *.myhost.com /myCMF/members/anythingNotWww www.myhost.com /myCMF/ you would get the behaviour you describe. I'm a bit leery of adding regexing as if you want complex behaviour, AccessRules already cover you. * also while I'm at it, it seems that making the management of the virtual hosts a little more zope-like would be nice. Here's where my inexperience may be become particularly obvious, but... I'm making this a VirtualHostFolder, similar to a acl_users folder except ordered (so you can tweak the order that the hosts are checked for a match). The VirtualHost objects it contains are not to be actual products but objects the way that Users.py defines users. The VirtualHostFolder is not an actual ObjectManager but just emulates one a bit a la an acl_users folder. Makes sense, especially if you want to extend their behavior as you mention above... I'm more of the assumtion that target folders will know their special behaviour, but I'm open on that one. Well, there's some thoughts. Like I implied, it's probably best to ignore my vaporware announcement; if I come up with anything not embarrassing I'll post it somewhere or other soon. Thanks- let me know what you come up with. imeme is cool btw. 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 - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] SiteAccess improvements
[EMAIL PROTECTED] wrote:
One thing that might be nice - and something I was planning on working on
relatively soon was a rewrite rule wizard to extend VHM to auto-write
rewrite rules for use with a front-end Apache/Squid; this would support
mod_rewrite and Pyredir (a python-based Squid redirector). The idea would
be that the rules could be copied by a site admin from their browser viewing
a VHM management page and pasted into Apache's httpd.conf or a Squid
redirector's conf file.
I actually want to see this happen as well! I was thinking I would ask
for an existing path to a configuration file, read that, and dump a diff
in the Zope dir, but your approach works too.
In the long run, if a registry of virtual host monsters is in the control
panel,
Out of curiosity, why do you want multiple VHM's?
and could be queried via XML-RPC, it seems an Apache module or Squid
redirector could be built or modified to make those servers use that data
automatically!
This sounds really cool. With both cases, I think one issue is how many
configuration possibilities there are. For example, with iMeme, our
apache says:
VirtualHost *
...
RewriteRule ^/(.*)
http://127.0.0.1:8080/VirtualHostBase/http/%{HTTP_HOST}:80/
$1 [L,P]
...
/VirtualHost
Which works for all the port 80 virtualhosting you want to do, so the
rest can stay in zope. Now, if you have specific, per-site apache
configuration needs past that point, you have to be smarter.
This is why i was thinking sniff the original config/supply a diff so
that you could do something intelligent- i.e. put the right rewrite
rules in the right VirtualHost directives - but I imagine there's limits
to how flexibly you could do things.
--
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 - [EMAIL PROTECTED]
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 )
Re: [Zope-dev] SiteAccess improvements
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] SiteAccess improvements
Hey. Thanks for your return thoughts. - Original Message - From: emf [EMAIL PROTECTED] Gary Poster wrote: * I need the ability to store arbitrary properties for each virtual host. In particular, the correlary of my current work is to provide a CMFVirtualHost tool that stores a sub-portal title, sub-portal skin information, and other items. hmm.. I can see why you might want to do this. it's not clear to me that this is where it should be done. I'd submit that a SiteMonster like thing would be more appropriate, as skinnish things, imho, probably want to live where an appropriately delegated manager can get at them (the target folder, not the root folder/control panel) Point taken. The biggest reason to do the CMF tool the way I describe is that a centralized CMF virtual host tool is easier for the skin tool to find. Also, the CMF tool, as a filter to my root Virtual Host properties, doesn't store any data itself (and presumable a SiteMonster would). Storing all the data, including CMF-specific data, in one place was meant to encourage data integrity. The drawback is potential overlap of variable names. I thought about doing a simple XML namespace naming convention solution, but rejected it on the grounds of overkill. All of this might still be the wrong decision, but I think it will work as planned and don't want to go back the drawing table again unless really necessary. Permissions are a sticky thing, I agree, that would be more easily handled if the host object were owned by the pertinent folder owner. I have a vague idea of somehow making permissions mirror the permissions of the mapped folder. Um...this is a bit of a and then a miracle occurrs planning moment. I'm fairly confident I can come up with a reasonable solution when I get there. heh. heh. * I need the ability to have multiple domains point to the same folder, while ideally maintaining the arbitrary properties The current/enhanced VHM has this ability Not exactly. The key is while ideally maintaining the arbitrary properties. This is really a matter of efficiency, which becomes particularly important when multiple properties get involved. Example: mysite.com, mysite.net, and mysite.org all direct to the same folder. They all have the same title, the same CMF skin options, the same everything. The current system requires three separate entries, which then would require manual maintenance of three sets of identical properties. Unnecessary, and error-prone. * while I'm at it, some regex capability seemed like a reasonable addition. I hope to come up with a clean UI way of doing regex substitutions (\1 etc.) as well: anythingNotWww.myhost.com tries to go to /myCMF/members/anythingNotWww, for instance. Well ... right now we just have subdomain globbing, so if you had two rules: *.myhost.com /myCMF/members/anythingNotWww www.myhost.com /myCMF/ you would get the behaviour you describe. I'm a bit leery of adding regexing as if you want complex behaviour, AccessRules already cover you. I hear you. It shouldn't be that hard to do, though. And my example was a poor one. Here's a better idea of why I mentioned regex group substitutions: CMF member folders: janedoe jackdoe joedoe jessiedoe Advertise to members: Have your own website at [your name].mysite.com! Be able to generically map any server other than www to the member CMF folder so that ^([^,]*)\.mysite\.com can map to (sorry, using Perl $1 for first match for simplicity) a root of /myCMF/Members/$1 Thus janedoe.mysite.com has a root of /myCMF/Members/janedoe. Same for the other member ids. idontexist.mysite.com would give an ugly error. Members that become clients can have their own mapping, so that they can have a personal skin * also while I'm at it, it seems that making the management of the virtual hosts a little more zope-like would be nice. Here's where my inexperience may be become particularly obvious, but... I'm making this a VirtualHostFolder, similar to a acl_users folder except ordered (so you can tweak the order that the hosts are checked for a match). The VirtualHost objects it contains are not to be actual products but objects the way that Users.py defines users. The VirtualHostFolder is not an actual ObjectManager but just emulates one a bit a la an acl_users folder. Makes sense, especially if you want to extend their behavior as you mention above... I'm more of the assumtion that target folders will know their special behaviour, but I'm open on that one. Again, data integrity and ease of connecting to other CMF tools were my deciding factors (not to mention that CMF likes tools, skins and content types as its main customization hooks). And again, it's just what I thought would work--permissions are a question. Thanks again for your thoughts. Now I better get cracking on it some more and close down Wizardry 8...tomorrow. ;-) Gary ___
