"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.