I seem to have made the waters muddier rather than clearer in picking up
these postings from last year;
http://markmail.org/message/64ipuo2istfb2tqm
let me try it this way:
01. Out of the box, I get a security.xml file that says this:
/roller-ui/login-redirect**=admin,editor
/roller-ui/profile**=admin,editor
/roller-ui/createWeblog**=admin,editor
/roller-ui/menu**=admin,editor
/roller-ui/authoring/**=admin,editor
/roller-ui/admin/**=admin
/rewrite-status*=admin
I don't know what it all means, but I assume that the authors do, and I
find that it, indeed,
partitions the context name space nicely -- protecting the important
stuff
from anybody in
the world messing up my blogs.
02. Then I notice that it doesn't prevent anyone in the world from
viewing
my bloggers'
content and submitting unwanted comments. The suggested solution was to
add this
incantation at the end of the list:
/**=admin,editor
The result, however, was that now no one can get to the site. If you try
with IE, you can
probably see the circular whirlwind of locations; if you try with
Firefox,
you get a helpful
screen saying that that browser has determined that a cycle of re-directs
will never result
in resolution of a location. To put it another way, even though the
"Make
everything
Private" declaration appears at the end of the ordered list, it
apparently
results in one
or more other contexts being protected that need to remain un-protected.
03. The first solution to that problem, I would guess, would be to
explicitly declare,
earlier in the list, that some context is NOT protected. So does anyone
know:
A. What specific context(s) need to remain un-protected in order for
any visitor
to be able to attempt to use the login screen(s)?
B. Using either ANT or REGEX notation, how to state that a context
is
NOT
to be restricted.
04. The second solution to the problem, or at least a solution that I
was
trying to
explain works for me -- because my needs are trivial -- is to assert
explicit access
restrictions for each blog by inserting these sorts of things at the top
of
the list:
/myuser1handle/**=admin,editor
/myuser2handle/**=admin,editor
So, I was hoping to provide a solution for anyone else who may have a
similarly
trivial use case, but hoping that someone would be able to suggest a
solution that
would work for non-trivial sites -- non trivial either because you have
hundreds or
thousands of blogs, or non-trivial because, while you may only have
scores
of
users, you do not prevent them from dynamically creating a new blog
anytime
they
choose.
For that use case, it was my suggestion that a single entry at the top of
the list
would suffice:
/allmyblogslivehere/**=admin,editor
which, to extend my example would mean that my users' contexts would
actually
have to be extended to:
/allmyblogslivehere/myuser1handle/
/alllmybloslivehere/myuser2handle/
etc. So, if anyone can provide a simple statement of what steps are used
to place
all blogs under something other than -- or one more level deeper than
/roller-ui/ --
that would seem to be a formula that would work even if none of us is
ever
going to
take a course on Spring-injected security mechanisms.
Thanks for your suggestions.
----- Original Message ----- From: "Matt Raible" <[email protected]>
To: <[email protected]>
Sent: March 09, 2009 06:24 AM
Subject: Re: Setting Roller Instance to Require Login To View Entries ?
On Sun, Mar 8, 2009 at 3:14 AM, Terry Corbet <[email protected]>
wrote:
Is it possible to get some resolution on Greg's request? Anyone
reviewing the thread can see that while his request was deemed valid,
even important, since no one on the commit team had any need for a
solution, after being left 'twisting in the wind' for a year, he
valiantly tried again.
Ok, so now I'm trying. Like, Greg, I have no knowledge of Spring, no
other applications requiring that I go through the steep learning
curve for that toolkit -- most especially the portion of that toolkit
whereby you 'inject' security into Roller. But, since I seemed to
have no choice, I spent the last 10 hours Googling and Guessing. If I
try to combine the bits of information provided in the security.xml
file, with the suggestion that you made -- but as Greg reported, it
fails -- of adding an entry such as "/**" at the bottom of the <value>
list, with the notes that the excruciatingly-terse developers
responsible for acegisecurity provide on the Spring mail lists, here's
where I end up:
A. What I think would result in the simplest, clearest declaration of
authorization would be one that could express a negative rule -- a
rule that says: "Do not require authentication for this URL."
Neither using Ant path expressions nor using regex was I able to find
a successful syntax for doing that.
Does your security.xml use <http auto-config>? If so, you should be
able to use something like:
<intercept-url pattern="/login.jsp*" filters="none"/>
From Spring Security's documentation:
You can use multiple <intercept-url> elements to define different
access requirements for different sets of URLs, but they will be
evaluated in the order listed and the first match will be used. So you
must put the most specific matches at the top.
B. If I can only accomplish my goal of partitioning the URL space via
positive statements, I would really like to have some partial URL that
could be exclusively resolved to user blog handles. Since I don't
really know all the various contexts that have been engineered into
the product, and since I really don't want to create URLs that are
made longer just so I can write a convenient security declaration,
that leaves me with having to make discrete, positive declarations for
each of my member blogs.
C. Now, in my use case, where the number of discrete blog handles
will be greater than 10 to the 1st and less than 10 to the 2nd, that
provides a workable solution. I suspect it is not a workable solution
for Greg or any of you with large, enterprise requirements, but I can
at least report some preliminary success by putting these kinds of
statements at the front of the <value> list instead of putting the
"protect everything" declaration at the end of that list:
/user1sblog/=admin,editor
/user2sblog/=admin,editor
...
/user37sblog/=admin,editor
D. Given a little attention by those of you who know your
architecture and know the syntax of the accepted declarations, I am
sure you can find a more efficient set of declarations to cover use
cases with upwards of 10 to the 2nd to 10 to the 3rd unique blog
handles and enablement of new blogs by the user community on demand.
It seems that successfully composing a handful of negative
declarations with wildcards is all that would be required to take
advantage of the suggested "protect everything" shorthand.
You should be able to use Ant-style pattern matching or regular
expressions. If you can provide the pattern, I should be able to
provide the proper configuration.
Matt
