Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

Task #12312 (new)

Opened 5 years ago

Last modified 4 years ago

Bug: password reset assumes root user ID of 0

Reported by: mtbcarroll Owned by:
Priority: minor Milestone: Unscheduled
Component: General Version: 5.0.1
Keywords: n.a. Cc: omero-team@…
Resources: n.a. Referenced By: n.a.
References: n.a. Remaining Time: n.a.
Sprint: n.a.

Description

Looking at password in db.py it appears to assume that root's user ID is 0. Shouldn't it be checking the Roles object? Or, at least, if the server isn't available, joining with the experimenter table to find out which is actually named root?

Change History (4)

comment:1 Changed 5 years ago by jamoore

  • Milestone changed from Unscheduled to 5.0.3
  • Owner jamoore deleted

Then let's implement or close. (There may need to be a general conversation about which is the most definitive: ID or name. On Unix, it would be ID)

comment:2 Changed 5 years ago by mtbcarroll

A lot of code avoids assuming 0: for instance, the admin service prevents changing root's name from root (which wouldn't much matter if we could still assume id 0, Unix should still work with root renamed), views.py bothers with expressions like conn.getAdminService().getSecurityRoles().rootId, and on startup the server regards the name as the authoritative datum in doing a,

select id from experimenter where omeName = 'root'

which make me wonder what assumptions have already been pervading the code.

comment:3 Changed 5 years ago by jamoore

  • Milestone changed from 5.0.3 to 5.x

Looking at password in db.py it appears to assume that root's user ID is 0. Shouldn't it be checking the Roles object? Or, at least, if the server isn't available, joining with the experimenter table to find out which is actually named root?

Making calls directly to PSQL has been something we've largely avoided from the CLI, so I don't think that's in scope to change here. If you think we should add a proper call in before doing this, we can look at doing so, but in general db assumes that no server is present, i.e. you've lost your password etc. so I'd tend to vote no on that. That then only leaves whether or not root or 0 should be definitive, which is a pretty large undertaking. (I'm inclined to vote for 0 so that someone could make there root name more i18n friendly.)

All that taken into account, I'm pushing. I'm open to suggestions/discussion, but I think mostly this should be a "rationalize Roles usage" RFE.

comment:4 Changed 4 years ago by jamoore

  • Milestone changed from 5.x to Unscheduled
Note: See TracTickets for help on using tickets. You may also have a look at Agilo extensions to the ticket.

1.3.13-PRO © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.76714 sec.)

We're Hiring!