# User Authentication

**URL:** <https://www.ruby-forum.com/t/user-authentication/123676>\
**Category:** Radiant CMS\
**Created:** [December 19, 2007, 6:01pm UTC](https://www.ruby-forum.com/t/user-authentication/123676 "2007-12-19T18:01:17Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Rick\_Henderson](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/9fc29f/32.png) [@Rick\_Henderson](https://www.ruby-forum.com/u/Rick_Henderson)\
**Post date:** [December 19, 2007, 6:01pm UTC](https://www.ruby-forum.com/t/user-authentication/123676/1 "2007-12-19T18:01:17Z")

</div>

Greetings all,

New to Radiant and the community, but my hope is that my co-worker and  
I  
can contribute a lot to the project in the years to come.

That being said, our first step is to develop a user extension for  
Radiant. We need the ability to add users and group security to our  
site  
pages.

Has this been proposed, or worked on, yet? Are their any “hooks” in  
the  
code for doing this that we can leverage in making this extension?

If there is no pre-positioned ability for this we thought about  
handling  
this through the use of a tag perhaps and then utilizing the inheritance  
of  
Radiant to pass down the security in the sections required.

In closing, I just have to say that I love the simplicity and power of  
how  
Radiant is designed. It’s organization allows for a very flexible  
system to  
be developed.

Thanks for the hard work so far on this great project!

```
  - Mystic
```

---

<div class="post-metadata">

**Author:** ![Rick\_Henderson](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/9fc29f/32.png) [@Rick\_Henderson](https://www.ruby-forum.com/u/Rick_Henderson)\
**Post date:** [December 21, 2007, 10:48am UTC](https://www.ruby-forum.com/t/user-authentication/123676/2 "2007-12-21T10:48:59Z")

</div>

Currently there is no ACL support in Radiant. This has been proposed  
and  
discussed in this list, search the archives.

I have been brainstorming about this lately and i have some ideas for  
working in a “security extension” in the future. I have done some UML  
diagrams and pen-on-paper mocks of a possible UI, but nothing tangible  
yet.  
Maybe in the next wave of energy+motivation…

/AITOR

---

<div class="post-metadata">

**Author:** ![Rick\_Henderson](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/9fc29f/32.png) [@Rick\_Henderson](https://www.ruby-forum.com/u/Rick_Henderson)\
**Post date:** [December 21, 2007, 4:38pm UTC](https://www.ruby-forum.com/t/user-authentication/123676/3 "2007-12-21T16:38:25Z")

</div>

I am planning on putting a few hours into playing with this today - I  
will post my outcomes.

On Dec 21, 2007 1:47 AM, Aitor Garay-Romero [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> > Radiant is designed. It’s organization allows for a very flexible system  
> > Site: [http://lists.radiantcms.org/mailman/listinfo/radiant](http://lists.radiantcms.org/mailman/listinfo/radiant)
> 
> * * *
> 
> Radiant mailing list  
> Post: removed\_email\_address@domain.invalid  
> Search: [http://radiantcms.org/mailing-list/search/](http://radiantcms.org/mailing-list/search/)  
> Site: [http://lists.radiantcms.org/mailman/listinfo/radiant](http://lists.radiantcms.org/mailman/listinfo/radiant)

–  
Da Dukk, on the road again!  
[http://www.NWGamers.org](http://www.NWGamers.org) - for a good time!  
[http://greg.nokes.name](http://greg.nokes.name) Ramblings from the Roost - For a Bad Time!

---

<div class="post-metadata">

**Author:** ![Rick\_Henderson](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/9fc29f/32.png) [@Rick\_Henderson](https://www.ruby-forum.com/u/Rick_Henderson)\
**Post date:** [December 22, 2007, 12:26am UTC](https://www.ruby-forum.com/t/user-authentication/123676/4 "2007-12-22T00:26:46Z")

</div>

So, here is the jist of the brainstorm, with some almost code… what  
do ya’ll think?

Radiant ACL proposal (very rough!)

Step #1 Deal with Caching

Inject a method into show\_page to call the authentication system. We  
need to know what page is being rendered so that we can pull group  
information. I propose passing the page as to the show page module to  
facilitate this. At first, I would suggest that this only applies to  
the admin pages. It would be pretty easy to allow pluggable user  
modules to overwrite the base one, and you could add granular rights  
to any page.

In our environment, even with small teams, there are certain pages  
that only the leadership portion of the team should be able to view.

def show\_page(page)  
if authenticator(page.find.groups(:all))  
render\_page  
else  
render\_login\_error\_page  
end  
end

def render\_page  
response.headers.delete(‘Cache-Control’)  
url = params[:url].to\_s  
if (request.get? || request.head?) and live? and  
(@cache.response\_cached?(url))  
@cache.update\_response(url, response, request)  
@performed\_render = true  
else  
show\_uncached\_page(url)  
end  
end

Step 2 - Validate Access

The authenticator would look something like this:

def authenticator(groups)  
unless session[:id].nil?  
user = User.find(session[:id])  
effective\_groups = user.find.groups & groups  
for group in effective\_groups  
case group.rights  
when 0 #denied access  
redirect\_to\_login and return false  
when 1 #read only  
return true  
when 2 #read and write  
#some action to allow folks to edit  
when 3 #read, write and grant  
#some action to allow folks to edit, and add people to the ACL  
end  
else  
if groups.include?(anon\_group\_id)  
return true  
else  
return false  
end  
end  
end

On Dec 21, 2007 7:37 AM, Greg [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> > diagrams and pen-on-paper mocks of a possible UI, but nothing tangible yet.
> > 
> > > can contribute a lot to the project in the years to come.  
> > > of  
> > > - Mystic  
> > > Site: [http://lists.radiantcms.org/mailman/listinfo/radiant](http://lists.radiantcms.org/mailman/listinfo/radiant)
> 
> –  
> Da Dukk, on the road again!  
> [http://www.NWGamers.org](http://www.NWGamers.org) - for a good time!  
> [http://greg.nokes.name](http://greg.nokes.name) Ramblings from the Roost - For a Bad Time!

–  
Da Dukk, on the road again!  
[http://www.NWGamers.org](http://www.NWGamers.org) - for a good time!  
[http://greg.nokes.name](http://greg.nokes.name) Ramblings from the Roost - For a Bad Time!

---

<div class="post-metadata">

**Author:** ![Rick\_Henderson](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/9fc29f/32.png) [@Rick\_Henderson](https://www.ruby-forum.com/u/Rick_Henderson)\
**Post date:** [December 22, 2007, 2:43am UTC](https://www.ruby-forum.com/t/user-authentication/123676/5 "2007-12-22T02:43:32Z")

</div>

Hi everyone,

I don’t to sound pedantic here, but can we be sure to distinguish  
between Authentication (auth), Authorization (authz), and Access  
Control? See the intro of this section of the Apache manual:

[http://httpd.apache.org/docs/1.3/howto/auth.html#intro](http://httpd.apache.org/docs/1.3/howto/auth.html#intro)

Just to be clear, this looks to be a problem entirely of authorization  
and not authentication or access control.

Take a look at Radiant’s login system in lib/login\_system.rb: Auth is  
provided by the before\_filter #authenticate (which unfortunately also  
authorizes to some extent), which calls #current\_user. I’d recommend  
using this method instead of calling User.find(session[:id]) manually.  
This way your extension will work with other extensions that may  
overload the authentication mechanism (e.g. I’m working on an  
extension that uses RubyCAS-Client [1] to allow centralized  
authentication over multiple applications – and I’m going to do this  
by overriding #current\_user).

Ok, so let’s consider an authz system: let’s say a user has roles.  
Roles grant them permission. Roles can either be global  
“Uber-administrator” or granular to a page “Editor of the lunch menu  
web page”. Right now Radiant determines if the user is authorized  
using the #user\_has\_role?(action). If you overrode this to call to  
include a page parameter, it would probably do what you need.

E.g.

def user\_has\_role?(role, page)  
current\_user.send(“#{role}?”, page)  
end

Also override #user\_has\_access\_to\_action? so that it include the page  
param.

So then you just need to monkey-patch User so that messages like  
“current\_user.uber\_admin?(page\_doesnt\_matter\_because\_im\_uber)” or  
“current\_user.lunch\_menu\_editor?(lunch\_menu\_page)” make sense.

I flirted with added an authz system to Radiant awhile back, and while  
this project [2] seems to be dormant and permissions are in funky  
little strings, the data model is solid and is what I’d recommend for  
the storing users and roles.

Well, I hope this helps. Auth and authz can be tricky, so I wish you  
the best of luck. I think the hardest part really, is putting  
together a role admin interface that makes sense. That’s why I’m  
leaving that as an exercise to you… 😉

-Andrew

[1] For more on RubyCAS, see:  
[http://rubyconf2007.confreaks.com/d3t2p1\_security\_and\_identity.html](http://rubyconf2007.confreaks.com/d3t2p1_security_and_identity.html)  
[http://code.google.com/p/rubycas-server/](http://code.google.com/p/rubycas-server/)  
[http://code.google.com/p/rubycas-client/](http://code.google.com/p/rubycas-client/)

[2] [writertopia](http://www.writertopia.com/developers/authorization)