# Radiant and fine grained authorization **URL:** \ **Category:** Radiant CMS\ **Created:** [May 22, 2007, 5:30pm UTC](https://www.ruby-forum.com/t/radiant-and-fine-grained-authorization/104795 "2007-05-22T17:30:45Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Andrew\_OSBrien](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/d6d6ee/32.png) [@Andrew\_OSBrien](https://www.ruby-forum.com/u/Andrew_OSBrien)\ **Post date:** [May 22, 2007, 5:30pm UTC](https://www.ruby-forum.com/t/radiant-and-fine-grained-authorization/104795/1 "2007-05-22T17:30:45Z")
Hi everybody, I’ve been looking at using radiant as my company’s CMS for our research products (loving the overall simplicity and the extensions capabilities, BTW). One of the things I’ll need to add on is some way to manage authorization on a per-directory and sometimes per-page basis (and sometimes even changing the content in a page). Standard Apache .htaccess files and groups aren’t an option, and I’d kinda rather do something more Railsish anyway. > From the looks of it, Radiant’s existing authentication system is fine > (and I’d rather not change something worked that deeply into the Admin > system), so what would be ideal would be something that only tries to > handle authorization. Does anyone have any experience or > recommendations with any of the Rails authz plugins available, > especially wrt use with Radiant? Right now I’m looking at the Authorization plugin ([http://www.writertopia.com/developers/authorization](http://www.writertopia.com/developers/authorization)), but I’d love to hear other suggestions. Thanks, Andrew ---
**Author:** ![Andrew\_OSBrien](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/d6d6ee/32.png) [@Andrew\_OSBrien](https://www.ruby-forum.com/u/Andrew_OSBrien)\ **Post date:** [May 22, 2007, 7:39pm UTC](https://www.ruby-forum.com/t/radiant-and-fine-grained-authorization/104795/2 "2007-05-22T19:39:08Z")
Oliver brought up a good point in a different thread that I thought I’d continue over here: On 5/22/07, Oliver B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Radiant has built-in caching, one of Radiant’s main features in fact. > With this caching being enabled it does not need to query the database > at all when a cached page is requested. This, however, is likely to > conflict with your plans of fine grained authorization. Yeah, that has kept me from doing page caching in Rails in the past. One thought I’d had was to allow Radiant to do all the caching it wants and in embed product specific classes or href rel attributes. Then, post process the output (outside of Rails, probably using Apache mod\_xslt) with a user specific XSLT (which would possibly be generated and cached by a GET request to a radiant extension that has a controller with a respond\_to.xsl {} block) to add things like the name of the current user and remove information and turn off links to pages they don’t have access to. This would also make it possible to make static html versions of pieces of the site for burning to CD (which some of our customer’s demand). Also, I’m guessing this is way more complicated than most authorization schemes (I blame our sales dept… grr 🙂 and it probably has limited applicability outside of our operation. So if you’ve read this far before hitting delete, thanks and I’d love feedback! -Andrew ---
**Author:** ![Andrew\_OSBrien](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/d6d6ee/32.png) [@Andrew\_OSBrien](https://www.ruby-forum.com/u/Andrew_OSBrien)\ **Post date:** [May 22, 2007, 8:45pm UTC](https://www.ruby-forum.com/t/radiant-and-fine-grained-authorization/104795/3 "2007-05-22T20:45:19Z")
Andrew O’Brien wrote: > mod\_xslt) with a user specific XSLT (which would possibly be generated > and cached by a GET request to a radiant extension that has a > controller with a respond\_to.xsl {} block) to add things like the name > of the current user and remove information and turn off links to pages > they don’t have access to. > > […] > > Also, I’m guessing this is way more complicated than most > authorization schemes […] This would probably work but looks extremely messy. Ideally you would want to keep and maintain all your access control at the application level and make the application aware of it. With respect to caching authenticated sessions I guess your best bet is some sort of session-based fragment cache. Currently Radiant only provides page level caching and identifying fragments and their dependencies is rather difficult at the moment. However, you might be able to create a variation on that: a page level cache that uses the URL and the user’s credentials, i.e. roles or groups, to compute the hash under which a page is stored in the cache. This way you prevent non-authorized users to access cached sensitive information, while at the same time provide some caching for authorized users. The only problem with this approach is that you still cannot display the correct username on the page and you may have some overhead in memory requirements for caching Maybe this generates ideas. Oliver ---
**Author:** ![Andrew\_OSBrien](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/d6d6ee/32.png) [@Andrew\_OSBrien](https://www.ruby-forum.com/u/Andrew_OSBrien)\ **Post date:** [May 22, 2007, 10:45pm UTC](https://www.ruby-forum.com/t/radiant-and-fine-grained-authorization/104795/4 "2007-05-22T22:45:31Z")
Hi Oliver, Point taken about it looking messy – I think any way of sequestering information (and references to it) is going to have some trade off though. I have a couple of reasons for wanting to seperate the content generation from the authorization process: 1. I didn’t want to have to overwrite the standard tags ( \ particularly comes to mind) to filter out or somehow mark unauthorized links from the navigation or other parts of the page. We don’t want our customers getitng frustrated in thinking they have access to something just to get a lot of 401 messages (or would it be 403? or 402? The documentation in 401 seems to describe authentication, not authorization… weird). 2. It seemed like a good way to make sure that our authorization logic could work on URLs outside of Radiant’s managment. Don’t get me wrong – I really like Radiant, but one of the things I hate about our homebrew PHP system is that so much of the authorization logic is mixed up with the rest of the application code. That’s mostly human design error, but nonetheless, something I dislike. Maybe my tastes are being unduly influenced by that. 3. I want to keep our content creators as removed from the authorization process as possible. As wiki fans, they’re savy enough to use Markdown, but I’d rather keep them away from radius tags, so they don’t have to make a context switch in their heads between the two. There’s bound to be a good way to crack this nut… -Andrew