Project

General

Profile

Actions

Defect #1

closed

permissions if not admin

Added by Todd McGrath about 17 years ago. Updated over 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Affected version:

Description

You probably already know this, but just in case....

If a user is not an administrator and they attempt to click on a project where they are a member (in any role, manager,
developer, reporter, etc.), there is an unexpected result:

Filter chain halted as [authorize] returned false
Completed in 0.00010 (10000 reqs/sec) | Rendering: 0.00000 (0%) | DB: 0.00000 (0%) | 403
[http://localhost/projects/show/1]

I believe this is the relevant code in the application.rb:

  1. admin is always authorized
    return true if self.logged_in_user.admin?
  2. if not admin, check membership permission
    @user_membership ||= Member.find(:first, :conditions => ["user_id=? and project_id=?",
    self.logged_in_user.id, @project.id])
    if @user_membership and Permission.allowed_to_role( "%s/%s" % [ ctrl, action ], @user_membership.role_id
    )
    return true
    end
    render :nothing => true, :status => 403

-/-

Put another way- create a non-admin user, add this user to a project in any role (manager, developer, etc.) and then
login as this new user. when you click on the project, you receive a blank page

-/-

Thoughts? Let me know if you want any help on this or if I'm doing something strange?

Todd


Files

default-permissions-PATCH.txt (1.11 KB) default-permissions-PATCH.txt Todd McGrath, 2008-02-03 10:48
base.rhtml-PATCH.txt (7.45 KB) base.rhtml-PATCH.txt Todd McGrath, 2008-02-03 10:48
roles_controller.rb_PATCH.txt (894 Bytes) roles_controller.rb_PATCH.txt Todd McGrath, 2008-02-03 10:48
application_helper.rb-PATCH.txt (970 Bytes) application_helper.rb-PATCH.txt Todd McGrath, 2008-02-03 10:48
Actions #1

Updated by Todd McGrath about 17 years ago

Pardon me! The code above is perfect.

The problem can be resolved by inserting into the
permission_roles table. The projects/show permission is not
included from default roles and also if you add a new Role.

I'll research more.

Actions #2

Updated by Todd McGrath about 17 years ago

I think the problem is two parts

1) default data load should include 100 in default
permissions (I'll attach patch file to this ticket)

2) When creating a new Role, we need to add a permission id
of 1. What is the best way to do this? hidden form field?
update the "method" in roles_controller to include
it?

Actions #3

Updated by Todd McGrath about 17 years ago

So, on further review, there are going to be many of things
related to this-

projects/list_issues
projects/list_news

etc.

Actions #4

Updated by Todd McGrath about 17 years ago

I have solution working for me and it also solves feature
request id: 6535. Maybe it will be helpful for you?

On the roles page (new or edit), we could include all
permissions including public. This way, we can control
things like projects/show, projects/list_issues, etc.

In addition, we can control whether or not certain modules
will even appear for certain groups (see feature request id:
6535). For example, if a group does not have "List"
permission for Documents module, the Documents link will not
appear.

I will upload three patch files to this ticket for your review:
roles_controller.rb_PATCH.txt
base.rhtml-PATCH.txt
application_helper.rb-PATCH.txt

Actions #5

Updated by Jean-Philippe Lang about 17 years ago

Hi, You're right. There is a big problem for members of non public
projects. Public actions (projects/show, ...) should be implicitly
authorized to any role. For the moment, i'll fix it this way
(0.4.0 should be released soon).
In 0.5.0, many changes should be done on permissions management,
I'll do my best to answer your needs.

Thanks for your submission.

Best regards,

Jean-Philippe

Actions #6

Updated by Jean-Philippe Lang about 17 years ago

Fixed in Revision 128

Actions #7

Updated by efgh efgh over 14 years ago

  • Status changed from Closed to Reopened
Actions #8

Updated by efgh efgh over 14 years ago

__

Actions #9

Updated by Mischa The Evil over 14 years ago

  • Status changed from Reopened to Closed
Actions #10

Updated by Fahmi Setiawan over 11 years ago

  • Assignee set to Azamat Hackimov
  • % Done changed from 0 to 100
Actions #11

Updated by Etienne Massip over 11 years ago

  • Assignee deleted (Azamat Hackimov)
  • % Done changed from 100 to 0
Actions

Also available in: Atom PDF