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 |
Reporter | dhx | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | N/A |
Status | new | Resolution | reopened | ||
Product Version | 1.2.0 | ||||
Summary | 0011399: Deprecate $g_show_realname and use $g_show_user_realname_threshold instead | ||||
Description | 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 Thoughts? |
|
I don't really care about the implementation, as long as the existing functionality is maintained, i.e. we need be able to |
|