[Zope] - Setting __bobo_realm__

Jim Fulton jim@Digicool.com
Tue, 08 Dec 1998 22:06:35 +0000


"Christopher G. Petrilli" wrote:
> 
> On Tue, Dec 08, 1998 at 07:29:32PM +0000, Jim Fulton wrote:
> > "Christopher G. Petrilli" wrote:
> > >  [ I make Jim's life more difficult about Realms in HTTP ]
> > >
> > > Ah, what I'm interested in is doing it INSIDE the GUI, on a folder
> > > level, not on a "Module" level, or a global level.  For example, if I
> > > access a folder with it's own Userfolder, and authorize on that, then
> > > want to go to the MAIN /manage screen, I have to reauthorize, which is
> > > fine, since they both use "Main" as the realm.  BUT when I go BACK to
> > > the sub folder (above), I'm still running as the "superuser" or
> > > whatever.
> >
> > And that's not what you want? :) In general, we prefer that
> > people who are authorized above should be authorized below.
> 
> Well, yes but... :-) Don't you hate that?


No, I very much prefer it.  If I have an 
object A/B, I expect the manager of A to be able
to manage B and to be able to create managers for 
B without giving up it's own access to B.

> 
> > Do you *really* want subfolders to have different realms,
> > do you just want to be able to able to "log out"?
> 
> Realms are often interesting because they allow you to be more specific
> about WHAT you want from someone.

Actually, roles allow me to be more specific about
what I want from someone.  Realms just let me define
where a user is defined.
 
> Also, moves are afoot to better manage authentication information, which
> IE already does, and Apple is introducing their KeyRings back into MacOS
> to manage this.
> 
> Part of the problem is sheer stupidity on e part of hte
> implementations... for example, in Netscape, if you authorize to
> "http://blah.com/Accounting/manage", and then try and access
> "http://blah.com/manage", Netscape will automatically send your
> Authorization header, when the standard specifically says:
> 
> """
> A client SHOULD assume that all paths at or deeper than the depth of the
> last symbolic element in the path field of the Request-URI also are
> within the protection space specified by the Basic realm value of the
> current challenge. A client MAY preemptively send the corresponding
> Authorization header with requests for resources in that space without
> receipt of another challenge from the server.
> """
> 
> And in fact it shouldn't send it for higher hierarchical accesses. So,
> to aleviate this problem, I think being able to separate the system into
> multiple realms would be advantageous.  Now, that doesn't mean that I
> can't over-complicate things by saying that I think that acquisition
> shouldn't be followed and that if user 'doe' is in the user folder of
> the root object, which is realm "root" and tries to access a lower space
> which is in realm "trusted" that she shouldn't be allowed access if
> things are acquired that way.  You should be able to look "up" the tree
> and find things.

So, if I understand you correctly, you want a user folder to 
implicitly contain users defined in user folders above, or, 
put another way, a user defined in a user folder is implicitly
defined in any realms defined by user folders in sub-folders of
the folder containing the user's user folder.

I think this is a reasonable compromise.  Having user folders, 
rather than ZPublisher do acquisition of user definitions is
a direction that we've been moving in.

> 
> > If the later, we find it convenient to have a "logout"
> > document sitting around:
> >
> >   <!--#raise Unauthorized-->
> >      You have logged out<p>
> >   <!--#/raise-->
> >
> > if you really want subfolders to have their own realms,
> > it probably wouldn't be too hard to
> > provide a user folder property for the realm
> > and have the user folder set the necessary response header
> > when an authorization fails.
> 
> Yes, this is kinda what I'm trying to get to.  What effect does
> Unauthorized have?

It causes the browser to display a log-in box.  Note that there
is currently a problem being that in cases where Unauthorized 
exceptions are raised by application code, the realm is not set.
We plan to fix this.

Jim

--
Jim Fulton           mailto:jim@digicool.com
Technical Director   (540) 371-6909              Python Powered!
Digital Creations    http://www.digicool.com     http://www.python.org

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.