Page tree will not be shown in the typo3 backend
If you don't use a real domain like www.mydomain.ch/typo3 (example http://194.150.249.xxx/~mydomain/typo3 the page tree will not be shown in the typo3 backend by firefox. There is only an error message:
The requested URL /~mydomain/typo3/¤tSubScript=sysext/cms/layout/db_layout.php was not found on this server.
With IE7 this message will disappear and the page tree will be shown if you click again on the page icon. On firefox unfortunately not.
(issue imported from #M12324)
#2 Updated by Stefan Hug over 7 years ago
We haven't any - in the directroy. And the problem is only in the newest Version 4.2.10. All other Version works correct. The problem is that we have many accounts on a multihoster and as long as the dns is not configured we have only access this way (http://194.150.249.xxx/~mydomain/typo3). As soon as you work with the real domain you don't have any problems with the Version 4.2.10
#8 Updated by Peter Niederlag over 7 years ago
This is indeed a serious problem to all users who operate a TYPO3 installation in a subdirectory with '~' or '-' in the name, which is perfectly valid and reasonable.
Can't find ethe pending patch on core list to fix the issue, I'll attach one right away.
#11 Updated by Peter Niederlag over 7 years ago
I second Oliver here, '~' and '-' are rather common in subdirectory names. However it is even valid to have a ':', '"' or other "weird" charcters in directory names. This might evend depend on the OS. My sggestion would be to stick with "common" characters for now.
A rather usefull addition probably would be to allow additional internationl/UTF-8 characters (ü,ö and alike).
#14 Updated by Oliver Klee over 7 years ago
Most important is : because this blocks URLs liks http://myeveilserver.com/. % also needs to be blocked because it allows encoding other possibly dangerous characters.
I don't think we need to allow § $ either - they're not expected to be used in file names that are part of URLs.
So, to sum it up, we should block : % § $
#17 Updated by Steffen Kamper over 7 years ago
i object your objection. If you forget something you have to add it, same in whitelist as in blacklist.
If you create whitelist you have to include te complete universe "except" the things you want to prevent. Result is that you forgot some chars and many users can't use BE anymore, that's more worse!
#19 Updated by Oliver Klee over 7 years ago
I agree that we need to add the stuff which we've forgotten.
In this case, it's all about directory names that are part of URLs. Do we really need to cover the case of non-ASCII-characters for this? I'm referring to what's common, not what is possible if someone tries to create file names that might break the BE login.
#24 Updated by Marcus Krause over 7 years ago
It's probably too late but:
Revisions 6235-6237  are clearly the root cause for this bug. I simply wonder why the methods, introduced with #0010724, haven't been used to prevent "external frame inclusions".
In addition, the name of the newly introduced method t3lib_div::sanitizeBackEndUrl() is a bit misleading; the method is not sanitizing, it's only accepting or denying a given string. And that is what we like to have for "prevention of external frame inclusion", either the url is valid or not. We do not want to sanitize anything.