The "Media file selector"-Upload-Widget ignores the given field file directory of a upload field with private files

Can you please confirm this is still a bug in the latest release (7.x-1.0-rc3)?

I also have problems with filefield path integration. See #1481636: Media module integration is not working where the tokens have no effect. I'm running RC3

Does it work if filefield paths are disabled? We need to know if this is an actual bug in Media itself or not.

I have seen the same behaviour in version 7.x-1.2 when inserting an image from the Web (after switching on Media Internet Sources module). It works fine (creates a proper directory and uploads the file there) with the "upload" tab.
thanks :)

I have a bit different problem.

It completely ignores "File directory" option, if you upload file using "media_internet" (Web -> URL or Embed code), it just uploads file in root public://, but if you upload file from local machine it uses "File directory" option and uploads file to path whatever says in "File directory".

I have the same problem as #5

I also experience this problem (#4, #5, #6). To avoid highjacking this thread, I have created a new bug report : https://drupal.org/node/2135367

I'm using media 7.x-2.0-beta11 with File (Field) Paths 7.x-1.0+1-dev and the image is correctly saved on the configured directory.

note: 7.x-2.0-rc1 has been released, for most situations its recommended that if you are using a beta release of media you should upgrade to 7.x-2.0-rc1.

Please take the regular precautions of backing up your site and db and try this out on a dev environment first rather than a live site.

This is NOT fixed in 7.x-2.0-rc1. I just tested this on a fresh install and when uploading files via the media browser, files that are supposed to be private are being saved as public when the "File directory for uploaded media" subdirectory option is configured. In the logs, I see "File public://files-test/filename.png could not be copied, because the destination directory private://files-test is not configured correctly." This has been tested on a local MAMP installation, as well as on Pantheon. Filefield paths is NOT installed nor is media_internet, etc. This does not happen when uploaded via file/add. This is definitely a media browser issue.

Upgrading this to critical because this is a serious security vulnerability if uploaded data, such as documents, are sensitive and must be private.

Any volunteers? Patches are welcome

Not sure if Dave Reid's quote here clarifies things?
@Dave Reid quote

@joseph.olstad I don't think so because A) he is referring to bulk uploading and B) This problem does not exist outside of the media browser. See this comment.

Also, the same error occurs if, after this failure, you try to edit the file and change it to private. Since the subdirectory (in this case, 'files-test') does not exist in the private filesystem, the file cannot be moved from public to private.

This could potentially be a bug in core, because files in directories cannot be migrated from public to private. However, if this is indeed the desired behavior of core, then the media module breaks core functionality with this subdirectory feature.

I have also just confirmed that this is not a core issue, and exists outside of the context of media_wysiwyg, and is a bug in media browser's implementation of private file subdirectories. This issue does not occur if the image field on a content type uses the core file widget with the "File directory" option, but does occur if the media browser widget is used. In both of these scenarios, the destination is the private filesystem.

If anyone decides to test this, I recommend using a token (such as files-[current-date:raw]) for the file directory in both scenarios. Using a static directory will cause confusion when testing if you upload with the core widget first, because core will successfully create the directory when uploading a private file, and then an upload with the media browser widget would not fail.

see comment here
#2135367: Media Internet Sources does not upload files in the field's File Directory

with the patch 30 in (see link below) you can use that patch , then write your own custom hook form alter to change the folder upload location as desired
#2000934: Allow selection of which folder a file is to on the file/add form

@joseph.olstad That patch does not help with this problem, unfortunately. When applied, there is indeed a new field on file upload that lets me choose a directory, and it works fine outside of the media browser, though there never was a problem in that scenario. When I upload a new file, specifically through the media browser, this new field is already pre-populated with the destination I configured at admin/config/media/browser, so there is nothing additional to be done with this form. The problem still remains thus: if the upload destination is the private filesystem, and the subdirectory in that new field does not already exist, it does not get created and the file just gets dumped into the public filesystem.

This is still an issue with rc3. I've already taken a look at the code and haven't been able to figure it out. This is a critical security issue and needs to be fixed ASAP.

Seem to me like more of a configuration issue than a bug.

Keep in mind that whatever directory/folder you configure, the Web server must have read and write permissions. And if you want the Web server to create a folder and browse a folder then it will need read /write and execute. Otherwise the server will not have access to upload your file to that location or new location.

This definitely is a bug. It has nothing to do with read/write permissions. I've tested it when the private files directory has 777 permissions, and it still fails.

I haven't yet had the need for this use case so not much motivation yet.

#1351906: Importing image fails on private file system.

@chrisgross , are you using media_bulk_upload ? because I recently had to patch file_entity in order to get files uploaded that way to respect the upload path.

Its likely that to solve your issue that there may be a file_entity patch available for you.

see my last comment here

#1351906: Importing image fails on private file system.

This has nothing to do with bulk uploads. This happens when I upload a single file through media browser. This occurs with a brand new, clean drupal install, where media browsers' upload destination is configured as any directory that does not exist yet, such as with tokens. If the destination is private, the directory does not get created, and the file gets dumped into the public file system. It happens even if private files have 777 permissions. It doesn't happen when uploading through a file field. It ONLY happens when uploading through media browser.

I remember seeing the same behavior as described by @chrisgross and worked around the issue by creating the necessary subdirectories in the private folder upfront.

Maybe a permission problem on the private folder or htaccess file, not allowing to create a new directories?

How did the 2.0 version of this module get released without this being fixed? This is marked as a release blocker and is a CRITICAL security issue.

I see now that the tag was removed. Why?

Actually, this problem seems fixed on my local install with 2.0, even though I haven't found an issue addressing it specifically. I will test in on Pantheon.

Check the release notes of 7.x-2.0
and the commit you're likely interested in is here:

This should be fixed with the 7.x-2.0 release

Otherwise please describe scenario in detail with steps to reproduce.

This issue still exists in 2.10. See comment #26 for steps to reproduce.

Chrisgross, can you please write a patch for this using a fully up to date clone of the file_entity 7.x-2.x branch? Meanwhile I'll see about writing a simpletest to try to reproduce #1327524-26: The "Media file selector"-Upload-Widget ignores the given field file directory of a upload field with private files so that the simpletest will have the final word.

It looks like this issue is still there. Should we reopen this?

I'm able to reproduce this with an user that is not user one on version 2.13.
Haven't tried with a clean install and latest dev version.
But testing this as a user that should be able to upload but is not user one makes the difference for me.

I see there is another issue about this: https://www.drupal.org/node/2901380
Marked as Postponed waiting for RTBC core patch.