Update. I implemented the Read Security Check as a servlet filter (bound to /page/*) and ran into what seems to be a bug with the Compression Filter. When it's enabled, any servlet filter downstream that sets the http response code (or servlet) breaks (just returns a blank page, instead of the proper error code / jsp).
Basically, doing an HttpServletReponse.sendError(HttpServletResponse.SC_FORBIDDEN) returns a blank page (either from a servlet filter, or a velocity servlet). Removed the Compression Filter mapping on /page/*, and it works just fine. Servlet Engine = Resin 2.1.17 Trunk Subversion copy (pulled about a week ago) George Daswani -----Original Message----- From: George Daswani [mailto:[EMAIL PROTECTED] Sent: Thursday, March 02, 2006 8:55 AM To: roller-dev@incubator.apache.org Subject: RE: bug? RollerAtomHandler permission check Hello, In regards to the read access permission, I basically added a new WebsiteData Boolean attribute called "restricted" - the admins can then toggle said bit (similar to the active flag) on/off. I extended the PermissionsData so it became public static short READERS = 0x01; // 0001 public static short LIMITED = 0x03; // 0011 public static short AUTHOR = 0x07; // 0111 public static short ADMIN = 0x0F; // 1111 I'm currently modifying the Page Servlet and the various other servlets to do the following simple check if ( WebsiteData.isRestricted() ){ // check if user has READ permission to said website If ( user == null ){ if ( WebSiteData.hasUserPermissions(user, PermissionsData.READERS){ // display the page } else { // set response as forbidden } } else { // not logged in, we need to store this page link for use by // ACEGI - so that after the scurity check, we get this page // session.setAttribute( AbstractProcessingFilter.ACEGI_SECURITY_TARGET_URL_KEY,WHATEVER_THE_CURR ENT_URL_IS) // redirect to "/j_security_check" } } else { // not restricted, just do what we normally do } The following pages will then be modified "tabbedmenu.website.members" The admin will have the option of setting a user to one of the following permissions someuser -> { "Admin", "Author", "Limited", "Reader" , "Remove" } on the right actions panel, a new action will be available called something like "Add Member Permission" which works similarly to the "Invite New Member" except it doesn't invite (it adds directly). IMHO, the above is the least invasive way to add read access permissions to a blog site. I'm pretty sure a couple of people will want better permissions (ie. Users -> groups -> permissions -> blogs) Another approach to doing this might be to create another ACEGI filter that unders the Roller request/context, can grok the website read restriction attribute, permission requirements. We should be able to insert such a filter in the security.xml (which in turn won't require programmatic security checking in the various servlets). George Daswani -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, March 02, 2006 5:44 AM To: roller-dev@incubator.apache.org Subject: Re: bug? RollerAtomHandler permission check On Feb 28, 2006, at 6:46 PM, George Daswani wrote: > Speaking of Permissions, I'm currently modifying roller so that > certain > blog websites have read access restrictions (private, accessible > only by > users with read permissions or above via roller users). Was thinking > about the doing following, and would such a thing be useful to other > people? > > Basically modifying the current permission set from > > public static short LIMITED = 0x00; // 0000 > public static short AUTHOR = 0x01; // 0011 > public static short ADMIN = 0x03; // 0011 > > to > > public static short READ = 0x00; // 0000 > public static short LIMITED = 0x01; // 0001 > public static short AUTHOR = 0x03; // 0011 > public static short ADMIN = 0x07; // 0111 > > then modify the various templates to support it? Would such a > patch be > useful to other people? As I've said before, I think "private" is a very important feature for business and personal bloggers alike, so I've love to see this patch. Your patch will probably have a higher chance of acceptance if you share/discuss your design here on the list. - Dave
