easy-digital-downloads

easy-digital-downloads copied to clipboard

Bug Report

Expected behavior

Downloads should work when direct access is blocked.

Actual behavior

Downloading files fails, get 404 messages after upgrading from 2.11.7 (I think) to 3.0.4

Everything worked fine before. I have setup my site with Trellis.

# https://docs.easydigitaldownloads.com/article/682-protected-download-files-on-nginx
location ~ ^/app/uploads/edd/(.*?)\.zip$ { rewrite / permanent; }

I have used this nginx include that blocks direct access to files. I set file downloads to force.

I also had to use these filters, not 100% sure if both are needed I think so, tried with disabling them did not work either. The edd_ignore_x_accel_redirect was possibly only needed when I was hosting on Pantheon. Anyway I used this setup for a long time, and it always works fine. Now the "Force" download option seems to just redirect to the file. When trying to download I end up on the URL where the actual file is. It seems that serving the files through php, or how you would call that does not work anymore.

// FIX EDD SL Downloads
add_filter( 'edd_ignore_x_accel_redirect', '__return_true' );

add_filter( 'edd_local_file_location_is_allowed', 'ngt_eddfileloc', 10, 4 );

function ngt_eddfileloc( $should_allow, $file_details, $schemas, $requested_file ) {

	$should_allow = true;

	// If the file is an absolute path, make sure it's in the wp-content directory, to prevent store owners from accidentally allowing privileged files from being downloaded.
	if ( ( ! isset( $file_details['scheme'] ) || ! in_array( $file_details['scheme'], $schemas ) ) && isset( $file_details['path'] ) ) {

		/** This is an absolute path */
		$requested_file = wp_normalize_path( realpath( $requested_file ) );

		if ( false === strpos( $requested_file, '/shared/uploads/edd/' ) ) {
			// If the file is not within the wp_upload_dir(), it should not be able to be downloaded.
			$should_allow = false;
		}
	}

	return $should_allow;
}

The only way I could fix this for now is to make the files accessible for anyone knowing the URL, something I obviously do not want.

Information (if a specific version is affected):

PHP Version: 7.4

EDD Version (or branch): 3.0.4

WordPress Version: 6.0.2

Any other relevant information:

@nextgenthemes We are also using Nginx on our site with the Forced method and aren't seeing this behavior where they are 404's.

I just ran a full diff on the changes from the last EDD 2.x version and the most recent EDD 3.x version and I'm not seeing anything in that diff that would result in a 404 response. However our file URLs are hosted locally currently.

Ideally we'd want to see the file URL you are trying to download but I know you'd probably not like to share that publicly, so if you could write into our support and provide us the following:

1. Product pricing configuration.
2. Screenshot of your download configuration (focusing on the files section where it shows us what the File URL looks like)
3. An actual link to the file.
4. The link you click on your site to download the file (this would be the EDD tokenized URL)

@cklosowski Just letting you know that your support is absolutely unacceptable, AGAIN. They asked for admin access only to tell me I should restructure my entire site so some basic default setup that uses default folder names for uploaded files because they are totally clueless about what is causing this.

I use Bedrock, It's not uncommon, it's supported by every plugin out there, WP is INTENDED to be used that way, but you always only care about the most default of default setups.

@nextgenthemes I'm sorry you are having issues, your support ticket was brought to my attention and I provided some feedback to try after reviewing what might have caused your issue. I believe we have found what the root cause is but I need to do some testing to ensure this.

I've created this PR which might help solve the issue, and in my testing seems to resolve the issue, that is causing your problem, which is the difference in the home_url() and site_url() when it comes to determining the local file URL.

When your issues was first brought up (the most recent ticket) I verified that none of the custom code you wrote was affected by changes, but looking even further into it with some more information about your setup I think what I've done here might help mitigate non-default directory configurations: https://github.com/awesomemotive/easy-digital-downloads/pull/9580

@robincornett @zkawesome I think I've identified why this was coming up from time to time in support. I worked on a PR today, and I believe it has to do with the Site URL and Home URL being different. In EDD 2.x we were checking based on the home_url() and in 3.0 we're using the site_url().

This change was made to make things compatible with WPML, and was staged nearly 4 years ago by the WPML team. This change, however, I believe had the unintended side affect of creating an issue in the opposite circumstance of WPML's expectations.

My approach is to actually check site_url and then home_url if it is still false after checking site_url. That way we can support both configurations of WPML, and setups like Trellis that separate the structure. It also adds a filter edd_is_local_file, so that even if things are even further custom, we can apply a quick fix with a snippet.