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
