tikiatua/internal-assets-plugin

Accessing assets above webroot results in 404 "not found"

Closed this issue · 3 comments

Good day,

I'm hoping to use your plugin to secure some member-only assets, stored above the webroot. The plugin is installed and activated and the new assets configuration is set up to use the environment variables. When uploading a new asset, it properly saves to the specified directory ("private") above the webroot as expected. However, when trying to access the asset, I encounter a 404 Not Found error.

I'm using Craft Pro 2.4.2669. Here's a snapshot of my config, edited for brevity:

config/general.php

define('SITE_URL', URI_SCHEME . $_SERVER['SERVER_NAME'] . '/');
return array(
  '*' => array(
    'environmentVariables' => array(
      'internalAssetsPath' => CRAFT_BASE_PATH . '../private/',
      'internalAssetsUrl'  => SITE_URL . 'private/'
    )
  )
);

My asset configuration is then as follows:

File System Path

{internalAssetsPath}members-material/

URL

{internalAssetsUrl}members-material/

Note that SITE_URL works perfectly fine with other environment variables, so I don't think this is contributes to the issue. It does seem, however, to be a URL routing issue. Have you encountered or receive reports of similar behavior?

Thanks so much for your time.

Cheers.

Hi @cliquenoir

Thanks for reporting your issue. The internal assets plugin is currently "hardwired" to the path SITE_URL . 'internal/'.

Therefore you cannot access your assets through your "private" url. You can. However easily change the path in the file InternalAssetsPlugin.php on line 39 and 40.

Hope this will help.

Thanks so much for the prompt reply. All is now working as expected.

Cheers.

Thanks again for helping clarify the plugin’s functionality.

I have another question for you if you have the time. When considering authentication failure for a given asset, from what I can tell Craft’s own authentication check seems to supersede the plugin’s ability to make the same check. For example, in the _sendFile function, a return of False on the if($hasaccess) condition doesn’t return the “Permission denied” alert. Instead (at least in my experience), Craft redirects to the primary login URL (i.e. loginPath). I encountered this because I wanted to elaborate a bit on the “permission denied” alert with a redirect to the loginPath but with a flashed message attached.

Truthfully, I’m entirely new to Craft plugin development and so may be missing something but I was curious to know your thoughts (so long as my explanation makes sense).

Cheers,

Chris