Changes between Initial Version and Version 1 of Ticket #11189, comment 20
- Timestamp:
- Aug 21, 2013, 7:10:54 AM (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #11189, comment 20
initial v1 1 1 I'll be returning to this ticket shortly, and I'm thinking that I might rework the changes to utilize the generic `ConfigurationError` exception with its default message, as shown in comment:4:ticket:11272. This is to avoid exposing configuration data to the end user, such as //Invalid format sqlite/db/trac.db//. 2 2 3 On the one hand it doesn't seem very harmful to expose this information to users, and it may be more convenient to just present the information to the administrator since the situation is most likely to be encountered while setting up the Trac instance. On the other hand, presenting the `ConfigurationError` with the default message could be consistently used across Trac, and in addition to consistency we don't have to make a decision for each piece of configuration data and decide whether it isshould be exposed to all users.3 On the one hand it doesn't seem very harmful to expose this information to users, and it may be more convenient to just present the information to the administrator since the situation is most likely to be encountered while setting up the Trac instance. On the other hand, presenting the `ConfigurationError` with the default message could be consistently used across Trac, and in addition to consistency we don't have to make a decision each time a similar situation arises and decide whether the configuration data should be exposed to all users. 4 4 5 5 A third option would be a future enhancement to only show a custom error message containing configuration data (i.e. the log message) through the web interface when the user has `TRAC_ADMIN` (discussion in bloodhound:#589 is related). I haven't explored whether this is practical for all situations - whether a permission check will be possible in all scenarios including the one presented in bloodhound:#589.