Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The middleware is processed for files too #5

Open
bmoex opened this issue Oct 28, 2020 · 3 comments · May be fixed by #21
Open

The middleware is processed for files too #5

bmoex opened this issue Oct 28, 2020 · 3 comments · May be fixed by #21

Comments

@bmoex
Copy link

bmoex commented Oct 28, 2020

Maybe its something not for this; but I had to manually do this in my own environment and wanted to mention it here:

I have a middleware handling 'secured' files to find the files and serve the file to the browser. As this is processed through middleware the justincase extension lowercased the filepath too; resolving into unknown files.

I fixed this with the following code before the lowerstring check is executed:

       // Safe check that no direct file is requested
        $absolutePath = GeneralUtility::sanitizeLocalUrl(Environment::getPublicPath() . $path);
        if (file_exists($absolutePath)) {
            return $handler->handle($request);
        }

Do you think this should be added for possible other conflicts too?

@bmoex bmoex changed the title The route is for changed when for files too The route is changed for files too Oct 28, 2020
@bmoex bmoex changed the title The route is changed for files too The middleware is processed for files too Oct 28, 2020
@Abdull
Copy link

Abdull commented Mar 14, 2023

Is this issue also about fileadmin file handling? If so, then it doesn't seem to be a problem anymore for fileadmin file handling:

I just tested b13/justincase:1.2.0 with a TYPO3 11.5.25 on Linux (case-sensitive file system), and fileadmin file handling is as expected, i.e. file name capitalization is significant and obeyed.

Example

Three files in fileadmin, all in the same directory:

File https://typo3.example.com/fileadmin/case.png (lowercase)

case

File https://typo3.example.com/fileadmin/CASE.png (UPPERCASE)

CASE

File https://typo3.example.com/fileadmin/CaSe.png (MiXeDcASe)

CaSe

Result

Requests to any of these three files are correctly disambiguated, and a request to nonexisting https://typo3.example.com/fileadmin/casE.png correctly results in a 404 Not Found.

@bmoex
Copy link
Author

bmoex commented Mar 14, 2023

By default TYPO3 bypasses the fileadmin folder but i have a middleware that initiates the fileadmin folder through php, and therefor activates your middleware.

My middleware then validates if the user is logged in and has access based on uri; but due to your middleware this request is manipulated (newly created) for my usecase and therefor not used correctly anymore.

As i adjusted it locally, it doesn't conflict anymore. Feel free to adjust or just leave it be but the problem remains. If you want my 'secured files' extension to test, i can send you this in private (feel free to dm me in slack)

@sterborg
Copy link

The redirect middleware is affected. If you want to use redirects for files with uppercase letters in the filepath, it won't work as the request is already turned to lowercase.

Workaround at the moment is to change the order of middlewares. I'm not shure if there are any drawbacks, though.

achimfritz added a commit that referenced this issue Jun 28, 2024
* drop TYPO3 < 11 Support
* add TYPO3 13 Support
* add ci workflow
* add BeforeMiddlewareIsAppliedEvent

Fixes: #5
Fixes: #11
@achimfritz achimfritz linked a pull request Jun 28, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants