Forum: Ruby on Rails Check if a saved user's name is admin

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.
862b20f190d93c4c3649db86de67ee6d?d=identicon&s=25 Mischa Berger (Guest)
on 2006-02-23 16:01
(Received via mailing list)
Hi all,

I have a question about this method in my User model:

# Returns true for the (saved) user called "admin"
def is_the_administrator
  true if save and name == "admin"
end

The method returns true if the user's name is admin. However, I only
want to
return true if the state of the object is "saved", so I call the save
method
first.

I'm wondering if there's another (better) way to make sure the object is
saved...
Is there??

Thanks,
Mischa.
119af50160cabfe1fb6f2f05f5018c64?d=identicon&s=25 James Ludlow (Guest)
on 2006-02-23 16:17
(Received via mailing list)
On 2/23/06, Mischa Berger <spmm_pls@yahoo.com> wrote:
>
> I'm wondering if there's another (better) way to make sure the object is
> saved...
> Is there??

I'm not entirely sure what you're trying to do here.  Presumably,
you'll have this admin user set up one time (or at least changing
rarely), but will be reading it from the database many times.  For the
purpose of checking the admin/non-admin status of this account,
wouldn't you know that you just pulled this record from the database?

-- James
862b20f190d93c4c3649db86de67ee6d?d=identicon&s=25 Mischa Berger (Guest)
on 2006-02-23 17:27
(Received via mailing list)
> I'm not entirely sure what you're trying to do here.

Hmm, it's hard to explain what the problem is, but I'll give it a try
anyway.

Once the admin is created I don't want anyone to be able to change the
name.
I implemented this like this in the view:

<% if @user and @user.is_the_administrator %>
  <%= text_field "user", "name", :disabled => true %>
<% else %>
  <%= text_field "user", "name" %>
<% end %>

However when someone else tries to change their name to "admin", the
text_field will be disabled too. The object is not saved, because of the
validation (validates_uniqueness_of :name). So I only want the field to
be
disabled if the object is saved. The way I implemented it now works, but
I'm
guessing there's a better way to do this.

Any ideas?

Thanks.
862b20f190d93c4c3649db86de67ee6d?d=identicon&s=25 Mischa Berger (Guest)
on 2006-02-23 20:44
(Received via mailing list)
Hi,

Sorry for reposting, but my date was set 1-feb today (don't ask) and I'm
not sure if this gets read...

My question is about this method:

# Returns true for the (saved) user called "admin"
def is_the_administrator
   true if save and name == "admin"
end

The method returns true if the user's name is admin. However, I only
want to
return true if the state of the object is "saved", so I call the save
method
first.

I'm doing this because...
Once the admin is created I don't want anyone to be able to change the
name.
I implemented this like this in the view:

<% if @user and @user.is_the_administrator %>
   <%= text_field "user", "name", :disabled => true %>
<% else %>
   <%= text_field "user", "name" %>
<% end %>

However when someone else tries to change their name to "admin", the
text_field will be disabled too. The object is not saved, because of the
validation (validates_uniqueness_of :name). So I only want the field to
be
disabled if the object is saved. The way I implemented it now works, but
I'm
guessing there's a better way to do this.

Any ideas?

Thanks!!
8e44c65ac5b896da534ef2440121c953?d=identicon&s=25 Ezra Zygmuntowicz (Guest)
on 2006-02-24 00:23
(Received via mailing list)
Mischa-

	You might want to look at my acl_system plugin. It handles role
permissions like you want in a more secure way.

http://brainspl.at/articles/2006/02/20/new-plugin-acl_system

Example:

class PostController < ApplicationController
   before_filter :login_required, :except => [:list, :index]
   access_control [:new, :create, :update, :edit] => '(admin | user |
moderator)',
                  :delete => 'admin & (!moderator & !blacklist)'


Cheers-
-Ezra
C1e5a9e9344b6d31b9df7303e6dc378a?d=identicon&s=25 Craig White (Guest)
on 2006-02-24 01:12
(Received via mailing list)
On Thu, 2006-02-23 at 15:19 -0800, Ezra Zygmuntowicz wrote:
> Example:
>
>
> class PostController < ApplicationController
>   before_filter :login_required, :except => [:list, :index]
>   access_control [:new, :create, :update, :edit] => '(admin | user |
> moderator)',
>                  :delete => 'admin & (!moderator & !blacklist)'
>
>
----
Looks like once again, you are solving a problem for me but I am wary
that the implementation is going to change as this is early.

I'm curious though...why the need to ! - can't the access_control simply
default to !everyone unless specifically permitted?

Craig
8e44c65ac5b896da534ef2440121c953?d=identicon&s=25 Ezra Zygmuntowicz (Guest)
on 2006-02-24 01:36
(Received via mailing list)
On Feb 23, 2006, at 4:11 PM, Craig White wrote:

>>
> ----
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Craig-

	Yes you can leave off the !whatever. I just included that as an
example of the syntax flexibilty you have with the logicparser. And
the implementation might change but the api and interface will remain
the same. I like to leave backwards compatibility in my code if
possible.

	Also if you get in early, you can make suggestions and get changes
you would like into the code before it gets to old and set in its
ways ;). The thing I have plans for at this point have to do with
model access control and not controller. So you wold be relatively
safe using it now. Plus you can always keep the old version around if
you dont want to upgrade. It is working nicely right now.

Cheers-
-Ezra
C1e5a9e9344b6d31b9df7303e6dc378a?d=identicon&s=25 Craig White (Guest)
on 2006-02-24 03:07
(Received via mailing list)
On Thu, 2006-02-23 at 16:34 -0800, Ezra Zygmuntowicz wrote:
> >> http://brainspl.at/articles/2006/02/20/new-plugin-acl_system
> >>
> 	Yes you can leave off the !whatever. I just included that as an
> you dont want to upgrade. It is working nicely right now.
----
not that my opinion carries much weight around here but after the
incredible solution offered by ez_where, I emphatically endorse anything
you offer and you can be certain next week, when I get back to
users/roles/rights, it will be act_as_authenticated/new_plugin_acl
(needs a name)

Craig
8e44c65ac5b896da534ef2440121c953?d=identicon&s=25 Ezra Zygmuntowicz (Guest)
on 2006-02-24 03:31
(Received via mailing list)
On Feb 23, 2006, at 6:06 PM, Craig White wrote:

>>>>
>>>> moderator)',
>>>
>> model access control and not controller. So you wold be relatively
> Craig
Thanks for the kind words Craig.

-Ezra
862b20f190d93c4c3649db86de67ee6d?d=identicon&s=25 Mischa Berger (Guest)
on 2006-02-24 12:27
(Received via mailing list)
Hi Ezra,

Thanks. Your plugin looks really interesting.

What I am currently trying to do is check if a role has
Create/Read/Update/Delete rights on a post. This should be stored in the
database too. So, in my case there'd also be a posts_roles table. I
haven't
implemented anything yet (besides giving users one or more roles).

Like I said, I don't want to hardcode the rights for a role. Instead I
want
to lookup the roles' rights for a post in the database. Does/will your
ACL
provide for something like this?

Thanks,
Mischa.


"Ezra Zygmuntowicz" <ezra@yakimaherald.com> wrote in
message news:32709474-0004-4762-9172-6164AF2F14FD@yakimaherald.com...
Mischa-


You might want to look at my acl_system plugin. It handles role
permissions
like you want in a more secure way.


http://brainspl.at/articles/2006/02/20/new-plugin-acl_system


Example:


class PostController < ApplicationController
  before_filter :login_required, :except => [:list, :index]
  access_control [:new, :create, :update, :edit] => '(admin | user |
moderator)',
                 :delete => 'admin & (!moderator & !blacklist)'




Cheers-
-Ezra


On Feb 23, 2006, at 11:43 AM, Mischa Berger wrote:


Hi,


Sorry for reposting, but my date was set 1-feb today (don't ask) and I'm
not
sure if this gets read...


My question is about this method:


# Returns true for the (saved) user called "admin"
def is_the_administrator
  true if save and name == "admin"
end


The method returns true if the user's name is admin. However, I only
want to
return true if the state of the object is "saved", so I call the save
method
first.


I'm doing this because...
Once the admin is created I don't want anyone to be able to change the
name.
I implemented this like this in the view:


<% if @user and @user.is_the_administrator %>
  <%= text_field "user", "name", :disabled => true %>
<% else %>
  <%= text_field "user", "name" %>
<% end %>


However when someone else tries to change their name to "admin", the
text_field will be disabled too. The object is not saved, because of the
validation (validates_uniqueness_of :name). So I only want the field to
be
disabled if the object is saved. The way I implemented it now works, but
I'm
guessing there's a better way to do this.


Any ideas?


Thanks!!


_______________________________________________
Rails mailing list
Rails@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails







_______________________________________________
Rails mailing list
Rails@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails
05d703f649ef1d07e78d7b479fb4c4ac?d=identicon&s=25 James Adam (Guest)
on 2006-02-25 03:36
(Received via mailing list)
Just in terms of your implementation, it's a pretty bad idea to tie
'administrator' rights to a field which has another purpose. What you
might consider doing is adding a new (boolean/int) column to your user
table - 'is_administrator', andd ActiveRecord will give you
User#is_administrator? for free. you can then also use various
validations to ensure that only a single user is the administrator,
and absolutely don't provide any kind of web interface to setting that
parameter (including stripping it from params hashes).

But yeah - in general, tying permissions to a general-purpose field is
a bit of a no-no.

- james

On 2/23/06, Mischa Berger <spmm_pls@yahoo.com> wrote:
> end
>
> I'm
>
--
* J *
  ~
862b20f190d93c4c3649db86de67ee6d?d=identicon&s=25 Mischa Berger (Guest)
on 2006-02-26 11:19
(Received via mailing list)
Thanks,
This is so obvious! Why didn't I think of it myself??
This topic is locked and can not be replied to.