> At this point, I come back to the same heuristic: to do
> whatever the code in
> 1.8 does. Anyone have a minute to try it out and tell
us what
> happens when you deny read permission to a few *.wiki
files
> in a namespace folder?
So, this was a great idea until I actually tried it with
respect to the
"deny permission on a namespace folder" thread.
The results there were that
things worked very poorly - partial rendering of pages,
exceptions, cache
confusion, etc. The worst part is that it actually served up
pages that I
wasn't supposed to be able to see! Also, I don't think
there's any way at
all to mask the existence of a namespace.
Also I was able to see topics I didn't have permission to
read in the Recent
Changes page. Not sure if that was a caching artefact or
not.
I have to admit this problem is a tough one for me. I'm
going to need the
community's help to figure out what we should do. Here are
what I see as the
options:
1) Denying read permission only denies the ability to see
the *contents* of
topics. It is not possible to mask the existence of topics.
2) If you can't read a topic, it's just like it didn't
exist.
3) Denying read permission on a *namespace* is different
from denying read
permission on a *topic*. Denying read permission on a
namespace means you
a) can't read any of its topics, and maybe
b) can't enumerate its contents, and maybe
c) can't even see that it (the namespace) exists
I don't think #2 is particularly useful - masking the
existence of a topic
is of limited utility when all you have to do to figure out
if it exists is
just try to create it - if you're denied permission, that
means it already
exists. Not to mention the way it screws up linking.
"Why can't I create the
page? It's got the dotted underline..." And if you
throw in red links (or
whatever) then we're back to admitting that the topic
exists.
#1 is going to be the simplest to implement and administer.
#3 (with options
a, b, and c) is probably the closest to the way that
filesystem security
works, if you consider a namespace to be like a directory.
Of course, it
also begs the question, "What if I have read permission
on a topic but not
on the namespace?" But maybe that's a corner case and
we don't care.
Option 3c is going to be slightly more difficult to pull off
because of the
way namespace-level operations are implemented. But it's
doable.
"What the wiki does today" isn't a good guide,
unfortunately - it doesn't
really have a good logical model for some of things we're
talking about. Or
maybe I just couldn't figure it out.
Thoughts?
------------------------------------------------------------
-------------
Using Tomcat but need to do more? Need to support web
services, security?
Get stuff done quickly with pre-integrated technology to
make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on
Apache Geronimo
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Flexwiki-users mailing list
Flexwiki-users lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flexwiki
-users
|