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