Preventing user entering URL to invoke controller actions

[John Henderson]

Any ideas how to prevent the user from entering things like
http://mysite.com/users/new ?

Obvoulsy from the AJAX scaffold, we do not enter ANY controller actions
in the URLs. But how do we prevent the user from doing this?

I know we can add checks to the edit action to ensure that if it called
we can ensure the user is allowed to view/edit the requested record.
(Sections 21.5 & 21.6 in Agile Web Dev)

[Paul Robinson]

On 14 Jul 2006, at 12:57, John Henderson wrote:

>
> Any ideas how to prevent the user from entering things like
> http://mysite.com/users/new ?
>
> Obvoulsy from the AJAX scaffold, we do not enter ANY controller
> actions
> in the URLs. But how do we prevent the user from doing this?

If you're using user_engine, you have full control of which users
have which roles which in turn determines which method/controller
pairs they are allowed to call. If you need role-based authorisation,
use a role-based authorisation system, but it's out of scope for ajax-
scaffold to handle, IMHO.

--
Paul Robinson

[drnicwilliams]

If you only want to allow it to be called from an Ajax call you could
also do something like:

def new
return redirect_to :action => 'index' if not request.xhr?
.. normal code here...
end

You could do a similar thing to prevent GET calls and allow only POST
calls.

[John Henderson]

Thanks Paul & Dr Nic

I already have my own full role based authentication built in to the
user model. This prevents access to each controller depending on role.

However this does not prevent a user who has access to a controller
from calling events manually and specifying the id of whatever record
they want to use.

Dr Nic's suggestion of limiting access to Ajax calls takes things a
step further but still is not perfect.

I wonder is there any way to set some sort of flag when the create
new/edit or delete buttons are pressed, then checking for and resetting
this flag in each controller event?

[Paul Robinson]

On 14 Jul 2006, at 20:39, John Henderson wrote:

> I wonder is there any way to set some sort of flag when the create
> new/edit or delete buttons are pressed, then checking for and
> resetting
> this flag in each controller event?

Not a way that can easily be spoofed. One way to investigate would be
to look at the referrer, but to be honest I would advise looking at
RBAC at the method level instead of just the controller level.

--
Paul Robinson

[drnicwilliams]

You could force the session id to be passed into any urls.

/forums/new - valid url entered explicitly
/forums/show/234 - invalid
/forums/show/234?session=234df3234af - valid if params[:session]
matches the same code in the session

[John Henderson]

In the end I've decided to go with Dr Nic's suggestion of limting
access to most controller actions from Ajax calls only.

This does have the side effect of rending the application useless to
anyone unfortunate enough not to have javascript.

However, there's lots of other Javascript in my application (including
navigation) so without Javascript the app is not usable.

Would be good to check for Javascript during login and prevent login if
Javascript is not present. A quick google on the subject says there is
no way to detect the presence of JS - unless anyone here knows
different?

[drnicwilliams]

Perhaps its better to ask yourself if its truly important to protect
something harmless like /controller/new in the first place? Just as
long as you protect the actions that affect the database, and allow
widgets within the page to hide their contents if the user isn't logged
in, isn't the appropriate access level etc.

It's nice to know your app can work at some level without javascript :)

[John Henderson]

good point. I forgot new doesn't actually do anything destructive -
although I guess it could give away potentially sensitive information
if the new_edit form has select lists which only certain users are
permitted access to.

I'm afraid my app won't work at all without javasript as it ususes
javascript controls for navigation. So you will get logged in but not
much further....