On Sun, Mar 8, 2009 at 5: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.
I personally do not know enough about Spring Security to be of help and it appears that other committers are too busy with other things to help out. If you really need resolution you'll have to either a) learn Spring Security and figure it out for your self or b) hire somebody who can do (a) for you. Covalent used to offer Roller support, but I'm not sure if they still do. They were recently purchased by Spring Source, so perhaps they could offer some support? If you know Servlet authentication well and don't want to learn Spring Security, another option would be to run from a trunk build and use plain old Servlet authentication instead of Spring security. You'd have to setup a security realm in your app server and you'd have to tweak Roller's web.xml to provide the level of security you need (see the commented out example config in the trunk version of Roller). That is what I do on my site. Sorry I can't be of more help. - Dave > 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. >
