Task #25830
closed
Use $TYPO3_CONF_VARS['BE']['explicitADmode'] = 'explicitAllow' as default
Added by Patrick Rodacker over 13 years ago.
Updated over 10 years ago.
Description
I would like to suggest, to set the configuration setting
$TYPO3_CONF_VARS['BE']['explicitADmode']
to explicitAllow as default instead of explicitDeny due to security policies.
If an extension is installed extending the list the access should not be granted per default but should be denied as default instead.
- Tracker changed from Suggestion to Task
- Project changed from 1687 to TYPO3 Core
- Priority changed from Should have to Must have
- Target version set to 6.2.0
- TYPO3 Version set to 6.2
- Status changed from New to Accepted
Would be cool if we finally set this new default, as it usually makes more sense.
To be able to change this default there need to be an Upgrade Wizard which guides the users from the old-school default to the new one:
1) old environment already was with explicitAllow => no change required, all is fine
2) old environment was configured with explicitDeny (on purpose) => keep "explicitDeny" in the new LocalConfiguration and nothing else
3) old environment was configured with explicitDeny (because it was the default) => change to "explicitAllow" and convert the user permissions to the new schema accordingly
I think the challenge is to "detect" 2 or 3, or maybe provide the user the choice in the Upgrade Wizard (with the risk of the user not understanding what he is about to choose...).
2) is impossible to detect, if done somewhere in AdditionalConfiguration.php
-> old environment has no config in LocalConf.php (hence now defaults to explicitAllow), but effective config says explictDeny => Things are modified somewhere else
3) is IMO not possible
The scenarios we can encounter:
| LocalConfiguration value before upgrade |
Effective Value after upgrade |
Action to take |
| explicitAllow |
* |
do nothing |
| explicitDeny |
* |
do nothing |
| (no definition) |
explicitAllow |
Write explicitDeny to LocalConf |
| (no definition) |
explicitDeny |
Changed somewhere else, do nothing |
why not adding a question to the upgrade wizard and tell the user, that explicitDeny is not recommend and should be changed to explicitAllow, this way we can also tell the user, that the option will hopefully be deprecated and deleted lateron
There should be also a hint, that the integrator needs to upgrade the groups / permissions, if the setting is changed!
imho it would be enough to define a new default and explizitly set the value of existing installations to whatever it is
This way it should be an easy patch ...
- Status changed from Accepted to Needs Feedback
For new installations explicitAllow is the default now on 6.2!
(FactoryDefault)
so it could be seen as fixed? right?
- Status changed from Needs Feedback to Closed
IMO yes.
Closed as this has been fixed with the rewrite of the Install Tool.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by