View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0011399||mantisbt||security||public||2010-01-15 07:36||2019-11-25 11:31|
|Summary||0011399: Deprecate $g_show_realname and use $g_show_user_realname_threshold instead|
There are two similar configuration options: $g_show_realname (either ON or OFF) and $g_show_user_realname_threshold (a threshold). Throughout the codebase these these options are used interchangeably which is wrong - because we should always be checking the access threshold against $g_show_user_realname_threshold.
Therefore I propose deprecation of the $g_show_realname option and replacement of all uses of this configuration option with a proper access check against $g_show_user_realname_threshold
This will help ensure that user real name's aren't exposed if the administrator sets configuration options as such.
|Tags||No tags attached.|
I'm not sure; I think these settings actually control two different things.
One may want to use realnames everywhere (i.e. $g_show_realname = ON), in which case I agree with dhx that it would not make sense to set $g_show_user_realname_threshold to anything other than ANYBODY.
But if you want to work with usernames ($g_show_realname = OFF), it makes sense to be able to restrict who can see realnames.
I've tried this solution on a working config, but I'm getting an Internal Server Error 500 as soon as I restart the webserver when I've implemented the following code:
What solution are you talking about ?
If you get an HTTP 500 error, you should look for further details in your system's logs.
In any case, unless I misunderstand, I don't think what you describe has anything to do with this issue's topic. Kindly open a separate issue if that's the case.
There was a semicolon missing in the config nevermind.
Reminder sent to: grangeway
Based on my comment 0011399:0031588, I think your commit 5d6b1bb4 should be reverted as you're removing functionality by doing this, and therefore introducing a regression for instances using these configs in the manner I described.
Reminder sent to: dregad
Damien: How good's your memory? In short, I guess we got to the point of needing to keep both variables that dhx proposed deprecating one of. I plan to have a look (And rethink at what these do over the next few days).
What i'm actually thinking about doing atm is the following:
a) keep both variables for reasons you described
At first glance, i'd probably use the new value at work (i.e. I currently use username's so as not to show students firstnames - whereas i'd set staff to udpater or whatever, and then set use_realname to updater
I don't really care about the implementation, as long as the existing functionality is maintained, i.e. we need be able to