Forum: Ruby on Rails Using vs. administer a rails application

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
6f3f4fcb842db4b755cd8adc8bca67c6?d=identicon&s=25 ms (Guest)
on 2009-01-29 23:19
(Received via mailing list)
Good evening,

there's a question, I can't really answer for myself. Let's assume,
I've got a rails application for selling cars. A user can create an
advertisement by choosing the corresponding model from a table
"car_models" and then add additional information. The user should
always be able just to _read_ the "car_models" table, not to change
it. On the other hand, there's an assistant who administers the
"car_models" table, adding, changing and removing entries.

So, where we are? We have our "CarModel" controller with its CRUD
methods. And, let's assume, we have a roled based access control
implemented. A normal user is a group member of "STD_USER", for
example. So he may only access the "get" oder "read" methods,
whatever. The assistant however is member of the group "STD_ADMIN",
for example, and has access to all methods of our "CarModel"
controller.

Although this looks secure, I must confess, that I am concerned. What
if the RBAC fails for some reasen? What if a normal user gets
accidentally in the admin group?

Wouldn't it be better to separate those functionalities? Let's say:
one administration application and one great wide world application.
I'm not convinced myself. How do you handle this?

I would be very happy about suggestions.

Thank you very much!
ms
3131fcea0a711e5ad89c8d49cc9253b4?d=identicon&s=25 Julian Leviston (Guest)
on 2009-01-30 06:49
(Received via mailing list)
Yeah, it's better to separate them, but you're still going to be in
the same boat as before, really: it's going to be down to whatever
qualifier you decide to split the access levels on.

Sent from my iPhone
F193e52d0a812b1429d51412bee21cdc?d=identicon&s=25 gundestrup@gmail.com (Guest)
on 2009-01-30 10:04
(Received via mailing list)
Well it all in relations.
CarModel controller - has in info.
has_many :advertisments

All controller actions regarding this model, is garded by if the user
is adminnistrator.
hence in your user model, you put an bool called "admin".
So all actions in the controller if garded with if @user.admin

For the advertisment you have:
And a belongs_to :carmodel

id
Carmodel_id
-----lots of extra info.

Regards
svend
Ad8b580d8004335c95d2d15518168ce3?d=identicon&s=25 Jej (Guest)
on 2009-01-30 11:13
(Received via mailing list)
I use Goldberg (http://wiki.github.com/urbanus/goldberg) to manage
this situation. It's possible to restrict access to controllers/
actions by roles. So you can forbid edit/update to normal users (or on
the other hand, forbid everything then allow only view for normal
users).

But anyway, you are not protected against a configuration mistake or
any security bug...

Jej
9770ee3431156709c728f6105dd98f0d?d=identicon&s=25 Bosko Ivanisevic (Guest)
on 2009-01-30 11:35
(Received via mailing list)
I use this approach, too. Moreover I like to separate all admin
controllers in their own namespace. Unfortunately in version 2.2
creating scaffold in namespace creates tables with admin_ (if
namespace is admin) prefix which is annoying and looks to me as a
bug.

Also in your controller you can put:

before_filter :require_admin

where require_admin is a method defined in your application.rb and
returns true if current user has admin flag set.

You can use before_filter in another way to require admin just for
some actions:

before_filter :require_admin, :except => ['index']

of

before_filter :require_admin, :only => 'destroy'

Regards,
Bosko


On Jan 30, 10:03 am, "gundest...@gmail.com" <gundest...@gmail.com>
9770ee3431156709c728f6105dd98f0d?d=identicon&s=25 Bosko Ivanisevic (Guest)
on 2009-01-30 11:39
(Received via mailing list)
By "this approach" I meant the one Svend gave :-), not the one with
Goldberg.

Regards,
Bosko

On Jan 30, 11:34 am, Bosko Ivanisevic <bosko.ivanise...@gmail.com>
Ad8b580d8004335c95d2d15518168ce3?d=identicon&s=25 Jej (Guest)
on 2009-01-30 13:13
(Received via mailing list)
> not the one with
> Goldberg.

You should ;)

I think it's better to group the security concerns in the same place
(ie. in golberg) rather than spread them amongs different
before_filters.

But whatever, the both rely on the skills of the coder!

Jej
This topic is locked and can not be replied to.