"Jay, Dylan" wrote: > There has to be some way round that. Is the REMOTE_USER variable still pased > in even if zope isn't in remote user mode? Couldn't a user folder be > implemented to use it? nope. REMOTE_USER is passed when the web server (IIS in our case) has done the *authentication* and said: "ok, REMOTE_USER is the name of the user coming in, and he's ok". then, zope just has to do *authorization*: "does this user whose name is given has the correct role to acces that ressource?"
> > please elaborate: you mean that when access to > > http://iis.host.com/zope_anonymous.pcgi/protected_resource is > > forbidden, > > zope automatically redirect the user to > > http://iis.host.com/zope_protected.pcgi/protected_resource? > Yes, that's exactly what I mean. Hum, this is an idea to explore further. this is interesting. and no, jcNTUserFolder does not do that right now. > I guess what I'm talking about is a user folder implementation that uses the > REMOTE_USER variable and contructs a user object around that. It assumes > that IIS has done it's job and the this REMOTE_USER is allowed in. this is exactly the default behavior. > It looks to see if it's seen this user before. If not it creates the user with some > default role. this is interesting. in the default implementation, if the remote user does not exist in the acl_users, it is considered anonymous. > If the user does exist with the same name as REMOTE_USER then > this user is used with all it's associated roles etc. > > I had thought this is what jcNTUserFolder did but I couldn't get it to work > like this. I think what it does do is try to authenticate directly with the > nt domain server using a name and password supplied by the user? jcNTUserFolder, like the standard one, behave differently in remote user mode and in normal mode (actually, it does not modify the default behavior): - in normal mode, it tries to log the user on the local machine, and if it can, it assumes that the username/password pair is valid, and then let Zope do authorization - in remote user mode, it does not authenticate because the REMOTE_USER has already authenticated, and let Zope do authorization. regards, [EMAIL PROTECTED] _______________________________________________ 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 )