There is an issue when a Symfony\Bridge\PsrHttpMessage\Factory\HttpFoundationFactory request is created from anywhere. If there are any POST $_FILES (File object) on that request, they are renamed and moved to the tmp directory with a new name. This new name is not propagated on the original request.
During this process of creating the new psr7 request, any temporary files are moved and renamed in the temporary folder.
The `tmp_name` values starts as something like: /private/var/tmp/phpEHH19a and then on line 102 of the HTTPFoundationFactory, the file is moved and renamed to something like:
`symfony5a4e551619af73.65717941BYwCkd`
This renaming flow happens like this
HttpFoundationFactory->createRequest() -> getFiles --> createUploadFiles and this line 102 of HTTPFoundationFactory
$psrUploadedFile->moveTo($temporaryPath);
causes the file to be renamed.
This type of request can happen in a number of places, but definitely in a decoupled app, especially during authentication. For example with the simple_oauth module when updating the tokens. This new request is never passed along and the original request still retains the original `tmp_name` file paths.
Once you finally get access to the request object in a module controller via
\Symfony\Component\HttpFoundation\Request
and check all the files via: $request->files->all();
The Symfony\Component\HttpFoundation\File\UploadedFile Object contains the original file path.
This is a major problem that needs to be overcome in order to handle multipart/form-data with decoupled javascript file uploads. I noticed the issue when working on a custom graphql module to handle file uploads.
Here is the path you can use to trace through the issue:
The SimpleOauthAuthenticationProvider calls validateAuthenticatedRequest($request) which creates a new psr7 request (see above). During this process, the files are moved and the new request does not include the updated request files object.
I think this is a bug upstream with Symfony or it's a bug with how files are handled with sub requests or maybe it's a bug with how simple_oauth handles getting the new tokens. I don't think it's a simple_oauth bug though because it's just making a request and there is a side effect of the temporary files being moved.
See the screenshot below. The $request variable is created and the tokens are reset. As a result of the new request, the temporary files are moved and renamed. The screenshot shows the new spl filepaths but this request dies in this method and the files do not get updated on the original request object. If you look at the watched variables on the right you can see that the file at the original tmp_name path no longer exists.
Needs work
6.0
Code
The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.