Restrict User details viewable by anyone

[Mark Jones]

Hi,

We are implementing our first site using hobo and are making progress
but am looking at some security / privacy issues and if you manually
add the URL to a users info page
"http://127.0.0.1:3000/users/1-mark-jones" then a guest is able to
view all the user's info.

We tried to get around this by adding permission to the user model:

def view_permitted?(field)
acting_user.administrator? || owner_is?(acting_user)"
end

The thinking being that only adn admin or the currently logge din user
woudl be able to view these details. This sort of worked but If we
then went to the signup page then the user fields to complete were not
shown.

The signup page is done in application.dryml

<def tag="signup-form" for="User">
<form lifecycle="signup" merge param="default">
<error-messages param/>
1. Your Details
<field-list fields="name, email_address, password,
password_confirmation" param/>
2. Your company
<field-list fields="company_name, website, address_line_1,
address_line_2, towncity, countystate, postcodezip, country" param/>
<br />
<div param="actions">
<submit label="#{ht 'users.actions.save', :default=>['Save']}"
param/><or-cancel param="cancel"/>
</div>
</form>
</def>


can anyone hep with this? I also tried creating a custom show event
and checking for admin or current user but that didn't work either..

Thanks

Mark Jones
Application Test Manager
Antix Labs Ltd

[Matt Jones]

On Nov 24, 2009, at 2:16 PM, Mark Jones wrote:

> Hi,
>
> We are implementing our first site using hobo and are making progress
> but am looking at some security / privacy issues and if you manually
> add the URL to a users info page
> "http://127.0.0.1:3000/users/1-mark-jones" then a guest is able to
> view all the user's info.
>
> We tried to get around this by adding permission to the user model:
>
> def view_permitted?(field)
> acting_user.administrator? || owner_is?(acting_user)"
> end
>

Try adding "|| new_record?" to the end of that sequence of
conditionals - there are still some edge cases where user_view gets
called on a new (empty) user record in the new/create actions.

--Matt Jones

[Bryan Larsen]

Coincidentally, I pushed a fix for that yesterday. So if you use the
hobo from git://github.com/tablatom/hobo.git, Matt's workaround
shouldn't be necessary.

If not, please let me know!

thanks,
Bryan

[Patrick Fitzgerald]

Hi Mark,

    I had a similar problem to this before, I managed to get solve by using a before_filter in the controller, maybe a similar approach would help you.  I have pasted the mail below with the details.  I hope it helps

Cheers,

Patrick

Mail I sent previously:

Hi All,

I manged to achieve what I wanted to. The way I did it was a mixture of Rails and Hobo.  First up I got hid the nav item from unprivileged users using the Rapid "if" tag like so:

1. Redefined the main-nav tag in application.dryml:

<def tag="main-nav">

<navigation class="main-nav" merge-attrs param="default">

<nav-item href="#{base_url}/">Home</nav-item>

<if test="&current_user.administrator?" >

<nav-item with="&IpAddress">IP Addresses</nav-item>

</if>

                <nav-item with="&Machine">Machines</nav-item>

</navigation>

</def>

This line will ensure only admin users can see the tab:

<if test="&current_user.administrator?" >

That's all well and good but if someone knows or guesses the URL then they can still gain read access to the data which isn't very secure.  For example: http://127.0.0.1:3000/ip_addresseswould still show all of the IP Addresses.  

In order to get around that I created a before filter which I placed at the head of the IP Address controller.  This code checks the user level and redirects if someone is trying to be somewhere they shouldn't be.

2.  The code for the IP Address controller:

class IpAddressesController < ApplicationController

before_filter :check_user_level

def check_user_level

puts "\n\n\n!!!AUTHORIZING!!!\n\n\n"

puts "Is admin user?: #{current_user.administrator?}\n\n\n"

    

                # If the user doesn't have the required access send them on their way.

if !current_user.administrator?

flash[:notice] = "You don't have the required access to be here.  I cast thee out!"

redirect_to "/"

end

end

hobo_model_controller

auto_actions :all

end

This approach works a treat to solve the problem I described earlier in this thread.  I hope that this helps someone out in solving a similar problem.

The downside of this is that it doesn't user the Hobo permissions system at all.  I would really like to know the Hobo way to solve this problem and welcome any comments or suggestions.

Cheers,

Patrick

--

You received this message because you are subscribed to the Google Groups "Hobo Users" group.
To post to this group, send email to hobo...@googlegroups.com.
To unsubscribe from this group, send email to hobousers+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/hobousers?hl=en.

[Mark Jones]

> > Try adding "|| new_record?" to the end of that sequence of  
> > conditionals - there are still some edge cases where user_view gets  
> > called on a new (empty) user record in the new/create actions.
>
> Coincidentally,  I pushed a fix for that yesterday.  So if you use the
> hobo from git://github.com/tablatom/hobo.git, Matt's workaround
> shouldn't be necessary.

Matt, Adding this OR got this working, Thanks, simple really when you
see the solution...

Bryan, I haven't upgraded hobo yet. I shall do this after our next
Milestone on Monday.. don't want to risk breaking anything else at
this stage. I'll report back if that doesn't solves the problem when
the workaround is removed.

Patrick, I read throught your thread before posting this and used some
of your fix but as this was not a new controller to restrict to but a
standard user controller with extra limitations it did not quite work
but gae me some new ideas.

Thanks All

Mark

[Bryan Larsen]

> Bryan, I haven't upgraded hobo yet. I shall do this after our next
> Milestone on Monday.. don't want to risk breaking anything else at
> this stage. I'll report back if that doesn't solves the problem when
> the workaround is removed.
>

That's a good plan. It helps me too -- The plan is to release a new gem
on Tuesday, so the more people who test before that the less chance I
have of having to release "brown paper bag" gem a few hours later. If
you look through the CHANGES.txt file, I seem to have a pattern of doing
that. :)

thanks,
Bryan

[Mark Jones]

For Completeness of this thread. I have upgraded hobo and this
workaround is indeed no longer needed.

Thanks

Mark
> Bryan