I'm sorry I don't know the answer to your question. However, if it's possible with container-managed authentication, I'm confident it can be done with Spring Security. The biggest thing is you probably need to give people access to the login screen (/roller-ui/login.rol on my version).
Matt On Mon, Mar 9, 2009 at 1:04 PM, Terry Corbet <[email protected]> wrote: > 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 >
