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), but I’d love to
hear other suggestions.
Thanks,
Andrew
Oliver brought up a good point in a different thread that I thought
I’d continue over here:
On 5/22/07, Oliver B. [email protected] 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
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
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:
-
I didn’t want to have to overwrite the standard tags (
<r:children:…> 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).
-
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.
-
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