Vote #70919
完了Redmine.pm considers all projects private when login_required is enabled
0%
説明
When the "login_required" setting is enabled, Redmine.pm consider all projects as private, which prevents non-member access to public projects.
journals
This should be fixed in r7808. Can you confirm?
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
With r7808, providing any login/password always allows reading on public projects, even if the user does not exist or the password is wrong.
--------------------------------------------------------------------------------
Indeed and I've just reverted it. The fix needs more refactoring.
--------------------------------------------------------------------------------
The attached patch should handle the access of non members. Feedback is welcome.
--------------------------------------------------------------------------------
I think "cast(projects.is_public as CHAR) IN ('t', '1')" could be handled as "projects.is_public" since it should be a boolean and I do not know if this SQL is allowed with all RDMBS. ("t" is just how DBI returns PostgreSQL true value.) I will test it with Mysql and maybe Sqlite. By the way, I am not sure how this change would affect the RedmineDbQuery directive.
--------------------------------------------------------------------------------
Guillaume Perréal wrote:
> I think "cast(projects.is_public as CHAR) IN ('t', '1')" could be handled as "projects.is_public" since it should be a boolean
It doesn't work with sqlite3.
> and I do not know if this SQL is allowed with all RDMBS. ("t" is just how DBI returns PostgreSQL true value.) I will test it with Mysql and maybe Sqlite.
It should work with mysql, postgresql and sqlite3.
> By the way, I am not sure how this change would affect the RedmineDbQuery directive.
The members and member_roles are no longer available for additional conditions but I don't think it really makes sense to add custom conditions on these tables.
--------------------------------------------------------------------------------
There is a small typo in the subquery: it selects @member_roles.id@ where it should be @member_roles.role_id@. Once fixed, it behaves as expected: I tested it with roles manager, reviever and non-member for reading and writing access.
--------------------------------------------------------------------------------
Fixed patch applied, thanks for the feedback.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Merged.
--------------------------------------------------------------------------------