Hi Piotr, is there a way for a sysadmin (of a shared phpMyAdmin installation) to indicate which setting is available or not for "normal" users?
I'm asking because I know, for example, that some sysadmins want to disable the "Show detailed MySQL server info" for all their users.
I'm not saying that we need such mechanism, but we'll have to be careful in the choices we give to users if they are perceived by sysadmins as related to security.
2010/7/21 Marc Delisle marc@infomarc.info:
Hi Piotr, is there a way for a sysadmin (of a shared phpMyAdmin installation) to indicate which setting is available or not for "normal" users?
Yes, config file has a key 'UserprefsDisallow', which contains names of values that users cannot override. Also, setup script has checkboxes (next to each option) which allow to modify this. Settings in 'UserprefsDisallow' are marked as DISABLED in user preferences (and are listed in Blacklist section of my debug message).
I'm asking because I know, for example, that some sysadmins want to disable the "Show detailed MySQL server info" for all their users.
I'm not saying that we need such mechanism, but we'll have to be careful in the choices we give to users if they are perceived by sysadmins as related to security.
In addition to disabling options, some are only partially editable by users. Namely: * MaxDbList, MaxTableList, QueryHistoryMax - users can set values which are equal to or lower than the one hardcoded in config.*.php * AllowUserDropDatabase, UseDbSearch, QueryHistoryDB, ShowPhpInfo, ShowChgPassword - these can be only disabled (changed from true to false), enabling them is impossible for users
Both cases above are marked by an icon with comment in setup script.
Piotr Przybylski a écrit :
Yes, config file has a key 'UserprefsDisallow', which contains names of values that users cannot override. Also, setup script has checkboxes (next to each option) which allow to modify this. Settings in 'UserprefsDisallow' are marked as DISABLED in user preferences (and are listed in Blacklist section of my debug message).
Great!
In addition to disabling options, some are only partially editable by users. Namely:
- MaxDbList, MaxTableList, QueryHistoryMax - users can set values
which are equal to or lower than the one hardcoded in config.*.php
- AllowUserDropDatabase, UseDbSearch, QueryHistoryDB, ShowPhpInfo,
ShowChgPassword - these can be only disabled (changed from true to false), enabling them is impossible for users
Both cases above are marked by an icon with comment in setup script.
I don't find intuitive that for some options, a checkmark means true and that for others, it means false (I know that you displayed "disable" but it requires more reflexion from the users).
The only alternative I can think of, would require a js-enabled browser to block enabling the option.
2010/7/21 Marc Delisle marc@infomarc.info:
Piotr Przybylski a écrit :
Yes, config file has a key 'UserprefsDisallow', which contains names of values that users cannot override. Also, setup script has checkboxes (next to each option) which allow to modify this. Settings in 'UserprefsDisallow' are marked as DISABLED in user preferences (and are listed in Blacklist section of my debug message).
Great!
In addition to disabling options, some are only partially editable by users. Namely:
- MaxDbList, MaxTableList, QueryHistoryMax - users can set values
which are equal to or lower than the one hardcoded in config.*.php
- AllowUserDropDatabase, UseDbSearch, QueryHistoryDB, ShowPhpInfo,
ShowChgPassword - these can be only disabled (changed from true to false), enabling them is impossible for users
Both cases above are marked by an icon with comment in setup script.
I don't find intuitive that for some options, a checkmark means true and that for others, it means false (I know that you displayed "disable" but it requires more reflexion from the users).
The only alternative I can think of, would require a js-enabled browser to block enabling the option.
I made it that way because I want to keep stored data at a minimum (only differences to defaults) and code straightforward (it's already complex enough), and adding a few options defaulting to false gives me a nice and simple switch to use. When detecting checkbox value I can only tell whether it is on, or off/not available.
I will think about using <select>s there, maybe then the solution will still be simple enough and more obvious. Or maybe I should move all these settings to a new tab, where this behavior would be described? "disable" text would stay, to alert user that something about this form is different.
Added to my todo list, first I will check whether <select>s would be suitable for the task.
Piotr Przybylski a écrit :
2010/7/21 Marc Delisle marc@infomarc.info:
Piotr Przybylski a écrit :
Yes, config file has a key 'UserprefsDisallow', which contains names of values that users cannot override. Also, setup script has checkboxes (next to each option) which allow to modify this. Settings in 'UserprefsDisallow' are marked as DISABLED in user preferences (and are listed in Blacklist section of my debug message).
Great!
In addition to disabling options, some are only partially editable by users. Namely:
- MaxDbList, MaxTableList, QueryHistoryMax - users can set values
which are equal to or lower than the one hardcoded in config.*.php
- AllowUserDropDatabase, UseDbSearch, QueryHistoryDB, ShowPhpInfo,
ShowChgPassword - these can be only disabled (changed from true to false), enabling them is impossible for users
Both cases above are marked by an icon with comment in setup script.
I don't find intuitive that for some options, a checkmark means true and that for others, it means false (I know that you displayed "disable" but it requires more reflexion from the users).
The only alternative I can think of, would require a js-enabled browser to block enabling the option.
I made it that way because I want to keep stored data at a minimum (only differences to defaults) and code straightforward (it's already complex enough), and adding a few options defaulting to false gives me a nice and simple switch to use. When detecting checkbox value I can only tell whether it is on, or off/not available.
I will think about using <select>s there, maybe then the solution will still be simple enough and more obvious. Or maybe I should move all these settings to a new tab, where this behavior would be described? "disable" text would stay, to alert user that something about this form is different.
Added to my todo list, first I will check whether <select>s would be suitable for the task.
I am beginning to wonder if these options (that can only be disabled): *AllowUserDropDatabase *UseDbSearch *QueryHistoryDB *ShowPhpInfo, *ShowChgPassword
make sense to offer in the user prefs interface. For example, if I want to block myself (remember, this is just about the current user) to change a password, do I need a setting to do so? I'll just avoid changing a password from the interface.
2010/7/21 Marc Delisle marc@infomarc.info:
Piotr Przybylski a écrit :
2010/7/21 Marc Delisle marc@infomarc.info:
Piotr Przybylski a écrit :
Yes, config file has a key 'UserprefsDisallow', which contains names of values that users cannot override. Also, setup script has checkboxes (next to each option) which allow to modify this. Settings in 'UserprefsDisallow' are marked as DISABLED in user preferences (and are listed in Blacklist section of my debug message).
Great!
In addition to disabling options, some are only partially editable by users. Namely:
- MaxDbList, MaxTableList, QueryHistoryMax - users can set values
which are equal to or lower than the one hardcoded in config.*.php
- AllowUserDropDatabase, UseDbSearch, QueryHistoryDB, ShowPhpInfo,
ShowChgPassword - these can be only disabled (changed from true to false), enabling them is impossible for users
Both cases above are marked by an icon with comment in setup script.
I don't find intuitive that for some options, a checkmark means true and that for others, it means false (I know that you displayed "disable" but it requires more reflexion from the users).
The only alternative I can think of, would require a js-enabled browser to block enabling the option.
I made it that way because I want to keep stored data at a minimum (only differences to defaults) and code straightforward (it's already complex enough), and adding a few options defaulting to false gives me a nice and simple switch to use. When detecting checkbox value I can only tell whether it is on, or off/not available.
I will think about using <select>s there, maybe then the solution will still be simple enough and more obvious. Or maybe I should move all these settings to a new tab, where this behavior would be described? "disable" text would stay, to alert user that something about this form is different.
Added to my todo list, first I will check whether <select>s would be suitable for the task.
I am beginning to wonder if these options (that can only be disabled): *AllowUserDropDatabase *UseDbSearch *QueryHistoryDB *ShowPhpInfo, *ShowChgPassword
make sense to offer in the user prefs interface. For example, if I want to block myself (remember, this is just about the current user) to change a password, do I need a setting to do so? I'll just avoid changing a password from the interface.
I was thinking about giving users a choice to hide some UI settings, but it we drop it the issue of problematic inputs for them will also disappear.
Does anybody else have some opinion on this?
Piotr Przybylski a écrit :
2010/7/21 Marc Delisle marc@infomarc.info:
Piotr Przybylski a écrit :
2010/7/21 Marc Delisle marc@infomarc.info:
Piotr Przybylski a écrit :
Yes, config file has a key 'UserprefsDisallow', which contains names of values that users cannot override. Also, setup script has checkboxes (next to each option) which allow to modify this. Settings in 'UserprefsDisallow' are marked as DISABLED in user preferences (and are listed in Blacklist section of my debug message).
Great!
In addition to disabling options, some are only partially editable by users. Namely:
- MaxDbList, MaxTableList, QueryHistoryMax - users can set values
which are equal to or lower than the one hardcoded in config.*.php
- AllowUserDropDatabase, UseDbSearch, QueryHistoryDB, ShowPhpInfo,
ShowChgPassword - these can be only disabled (changed from true to false), enabling them is impossible for users
Both cases above are marked by an icon with comment in setup script.
I don't find intuitive that for some options, a checkmark means true and that for others, it means false (I know that you displayed "disable" but it requires more reflexion from the users).
The only alternative I can think of, would require a js-enabled browser to block enabling the option.
I made it that way because I want to keep stored data at a minimum (only differences to defaults) and code straightforward (it's already complex enough), and adding a few options defaulting to false gives me a nice and simple switch to use. When detecting checkbox value I can only tell whether it is on, or off/not available.
I will think about using <select>s there, maybe then the solution will still be simple enough and more obvious. Or maybe I should move all these settings to a new tab, where this behavior would be described? "disable" text would stay, to alert user that something about this form is different.
Added to my todo list, first I will check whether <select>s would be suitable for the task.
I am beginning to wonder if these options (that can only be disabled): *AllowUserDropDatabase *UseDbSearch *QueryHistoryDB *ShowPhpInfo, *ShowChgPassword
Another example is UseDbSearch; this would be disabled in config.inc.php because we want to avoid stressing the server, right? So I don't see the point of permitting a user to disable it for himself. It would mean that when he disables this in Settings, he's aware of the possible overhead but if he makes a db Search he's not aware...
2010/7/21 Marc Delisle marc@infomarc.info:
Piotr Przybylski a écrit :
2010/7/21 Marc Delisle marc@infomarc.info:
Piotr Przybylski a écrit :
2010/7/21 Marc Delisle marc@infomarc.info:
Piotr Przybylski a écrit :
Yes, config file has a key 'UserprefsDisallow', which contains names of values that users cannot override. Also, setup script has checkboxes (next to each option) which allow to modify this. Settings in 'UserprefsDisallow' are marked as DISABLED in user preferences (and are listed in Blacklist section of my debug message).
Great!
In addition to disabling options, some are only partially editable by users. Namely:
- MaxDbList, MaxTableList, QueryHistoryMax - users can set values
which are equal to or lower than the one hardcoded in config.*.php
- AllowUserDropDatabase, UseDbSearch, QueryHistoryDB, ShowPhpInfo,
ShowChgPassword - these can be only disabled (changed from true to false), enabling them is impossible for users
Both cases above are marked by an icon with comment in setup script.
I don't find intuitive that for some options, a checkmark means true and that for others, it means false (I know that you displayed "disable" but it requires more reflexion from the users).
The only alternative I can think of, would require a js-enabled browser to block enabling the option.
I made it that way because I want to keep stored data at a minimum (only differences to defaults) and code straightforward (it's already complex enough), and adding a few options defaulting to false gives me a nice and simple switch to use. When detecting checkbox value I can only tell whether it is on, or off/not available.
I will think about using <select>s there, maybe then the solution will still be simple enough and more obvious. Or maybe I should move all these settings to a new tab, where this behavior would be described? "disable" text would stay, to alert user that something about this form is different.
Added to my todo list, first I will check whether <select>s would be suitable for the task.
I am beginning to wonder if these options (that can only be disabled): *AllowUserDropDatabase *UseDbSearch *QueryHistoryDB *ShowPhpInfo, *ShowChgPassword
Another example is UseDbSearch; this would be disabled in config.inc.php because we want to avoid stressing the server, right? So I don't see the point of permitting a user to disable it for himself. It would mean that when he disables this in Settings, he's aware of the possible overhead but if he makes a db Search he's not aware...
I removed these problematic settings in latest commit.
Piotr Przybylski a écrit :
I am beginning to wonder if these options (that can only be disabled): *AllowUserDropDatabase *UseDbSearch *QueryHistoryDB *ShowPhpInfo, *ShowChgPassword
Another example is UseDbSearch; this would be disabled in config.inc.php because we want to avoid stressing the server, right? So I don't see the point of permitting a user to disable it for himself. It would mean that when he disables this in Settings, he's aware of the possible overhead but if he makes a db Search he's not aware...
I removed these problematic settings in latest commit.
Looks fine.
Another point: let's say I choose Navigation Frame / Tables and I change something there, then click Save. I'm always back to the first sub-tab (in this case, Navigation Frame / Navigation frame) and I find it confusing because I would expect to see feedback about the page on which I clicked Save.
2010/7/27 Marc Delisle marc@infomarc.info:
Piotr Przybylski a écrit :
I am beginning to wonder if these options (that can only be disabled): *AllowUserDropDatabase *UseDbSearch *QueryHistoryDB *ShowPhpInfo, *ShowChgPassword
Another example is UseDbSearch; this would be disabled in config.inc.php because we want to avoid stressing the server, right? So I don't see the point of permitting a user to disable it for himself. It would mean that when he disables this in Settings, he's aware of the possible overhead but if he makes a db Search he's not aware...
I removed these problematic settings in latest commit.
Looks fine.
Another point: let's say I choose Navigation Frame / Tables and I change something there, then click Save. I'm always back to the first sub-tab (in this case, Navigation Frame / Navigation frame) and I find it confusing because I would expect to see feedback about the page on which I clicked Save.
I will do something about that.
2010/7/27 Piotr Przybylski piotr.prz@gmail.com:
2010/7/27 Marc Delisle marc@infomarc.info:
Piotr Przybylski a écrit :
I am beginning to wonder if these options (that can only be disabled): *AllowUserDropDatabase *UseDbSearch *QueryHistoryDB *ShowPhpInfo, *ShowChgPassword
Another example is UseDbSearch; this would be disabled in config.inc.php because we want to avoid stressing the server, right? So I don't see the point of permitting a user to disable it for himself. It would mean that when he disables this in Settings, he's aware of the possible overhead but if he makes a db Search he's not aware...
I removed these problematic settings in latest commit.
Looks fine.
Another point: let's say I choose Navigation Frame / Tables and I change something there, then click Save. I'm always back to the first sub-tab (in this case, Navigation Frame / Navigation frame) and I find it confusing because I would expect to see feedback about the page on which I clicked Save.
I will do something about that.
Fixed
Piotr Przybylski a écrit :
2010/7/27 Piotr Przybylski piotr.prz@gmail.com:
2010/7/27 Marc Delisle marc@infomarc.info:
Piotr Przybylski a écrit :
> I am beginning to wonder if these options (that can only be disabled): > *AllowUserDropDatabase > *UseDbSearch > *QueryHistoryDB > *ShowPhpInfo, > *ShowChgPassword
Another example is UseDbSearch; this would be disabled in config.inc.php because we want to avoid stressing the server, right? So I don't see the point of permitting a user to disable it for himself. It would mean that when he disables this in Settings, he's aware of the possible overhead but if he makes a db Search he's not aware...
I removed these problematic settings in latest commit.
Looks fine.
Another point: let's say I choose Navigation Frame / Tables and I change something there, then click Save. I'm always back to the first sub-tab (in this case, Navigation Frame / Navigation frame) and I find it confusing because I would expect to see feedback about the page on which I clicked Save.
I will do something about that.
Fixed
I like it.
-
Marc Delisle -
Piotr Przybylski