Try under the forum admin, permissions, edit permissions for read only access group and see if the Can view links within posts and Can download other file type attachments is checked

Hello kvr28,

thanks for your post, I re-checked all permissions and user groups but still attachments can be accessed by guests.

To clear it up: Guests can NOT see any forums/posts, not even in read-only mode! But if you know the attachment URL you can access it directly. This is a security concern for me, e.g. a logged in user can sent the attachment URL to an unauthorised person or someone checked the browser history of a previously logged in user and got the URL from there etc.

Regards, JS

Interesting… we will have a discussion here, I am no expert on these particular type issues but I suspect there isn’t much we can do within the forum application code. Surely you need to set something in an .htaccess file? Or restrict the folders via server settings. I suspect that if we were to add something to the .htaccess file then it may also prevent proper use of such files via the UI.

I also am unsure if it is possible to inform a folder, such as this, whether the user is logged in to the website or not.

But – as I say – I am no expert. I will talk to a colleague later today who may have a more definitive answer for you.

Of course, a htaccess file would be required. But it could be created by the forum code when this feature is activated. It is not possible to “inform the folder”

It should be easy to implement: The forum already has functionality to check if the current user is allowed to view a post (and if he is allowed to view attachments within that post). The database already contains the path & filename of the attachment and the post ID it belongs to.
Instead of directly linking to the attachment file the uploader plugin would present a link to a download.php file with the attachment ID as parameter, pseudo code would look something like this:

$attachmentId = $_GET[‘id’];
$row = getFromAttachmentTable($attachmentId);
if (!$row) { die(‘404’); }

$allowed = checkPostPermission($row[‘postId’]);
if (!$allowed) { die(‘403’); }

readfile($row[‘path’]);
?>

Another option would be to instead of changing the URL displayed in the forum to add a htaccess to the upload folder which redirects every request transparently to the download.php, which then fetches the attachment-row from the database by querying for the requested path/filename instead of the attachment ID and then performs the steps as outlined above.

Thanks for your help,
JS

Neither of those options are really a satisfactory answer…  it would break any images, for example, if you disabled the plugin as it would be required to display the images…  there has to a be a proper fallback…  and its not a small degradation in performance… 

the file uploader was never intended to server as a downloads manager/server as such… it was intended as way for users to share images and media – later adding files at user request…

guess one could customize just the file portion of the plugin, but some work…  btw, you may have omitted for simplicity, but your code you posted would be a security risk using unsanitized input…

also first time it has come up…guessing a url to attachment is far from easy… though I understand  your concern if you have vermin sharing urls…

we will have to discuss and think on it to see if we can come up with a workable path forward….  thanks!

Hello together,

any news on this yet?

Another issue that came up while using the plugin: Could an option be implemented to enable opening the attachment links in a new window/tab by adding a target attrib to the attachment link?

@mr-papa of cause, it is not as simple as my pseudo code shows. The header()’s must be correctly added to display the file/image inline. As I understood there are already postinstall / postuninstall hooks in the forum code, so after disabling the feature the (previously automatically created) .htaccess could be deleted from the upload folder so normal access is not disturbed.

Sure, it would have a performance impact, the feature should be optional for those with increased security needs.
I’m aware of the unsanitized input, it was just pseudo code to outline the idea as e.g. also the die() calls should not be kept but replaced by the correct display of the wordpress 404 page.

Have a nice week,
JS

Nothing to report at this time…  Its something we will discuss and see what might be best way to proceed…   we have a release to get out next week, so certainly nothing will happen before then…

as to the nofollow, that is something that should already be there (but isnt)… or at least it should follow the nofollow option we have for content links… that we can fixed up pretty quickly…