Check if a saved user's name is admin

Rails
1

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.

2

On 2/23/06, Mischa B. [email protected] 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

3

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.

4

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!!

5

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

6

On Feb 23, 2006, at 4:11 PM, Craig W. wrote:

Rails mailing list
[email protected]
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

7

On Thu, 2006-02-23 at 16:34 -0800, Ezra Z. wrote:

Ruby on Rails Blog / What is Ruby on Rails for?

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

8

On Feb 23, 2006, at 6:06 PM, Craig W. wrote:

moderator)’,

model access control and not controller. So you wold be relatively
Craig
Thanks for the kind words Craig.

-Ezra

9

On Thu, 2006-02-23 at 15:19 -0800, Ezra Z. 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

10

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 Z.” [email protected] wrote in
message news:[email protected]…
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 B. 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
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

11

Thanks,
This is so obvious! Why didn’t I think of it myself??

12

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 B. [email protected] wrote:

end

I’m

–

  • J *
    ~