Security issue with link audio to file url

Since there seems to be no audio add-ons for v9 yet, I have been using the link to a file’s url option. there are 2 choices: (1) Direct URL: if you need to embed an image directly in HTML, use this URL

(2) Tracking URL: By using this URL Concrete will still be able to mange permissions and track statistics on its use.

I used option 2 because our site is private with different groups and need the permissions option. I had created text on a page with several links to audio files and then copy/pasted the text from the page into an email (google groups) thinking that clicking on the links to listen to the audio would prompt the user to log into our c5 website. while editing the Email I discovered that the links opened the files without being logged in to the website so I went through each line that had a link to an audio file and clicked on “remove link” from the email editing tool. However, to my shock this morning, the files were still opening the audio files directly from the email in the google group! Since clicking on a link to an audio file takes the user to a blank page with just an audio player- I assumed that the audio player page would carry the same permissions as the page the link is from, but it doesn’t not seem to be the case and I can not find the individual audio player pages in order to set up specific permissions… so for now, this is a security issue I need to deal with. Can anyone please direct me on how to make sure that the audio links require permissions?? Thanks very much.

Are the files being linked to in /application/files/####/####/filename by any chance? For any files that should not be accessed by the public it would be ideal to have them stored outside of the document root of the webserver. This can be done by creating a File Storage Location (see Developer docs: File Storage Locations and Editor docs: File Storage Locations)

When creating the file storage location, enter a physical path to a folder that is not inside the server’s document root and leave the relative path empty. Then in the File Manager, move the files over to the new File Storage Location. This will prevent files from being accessed by their path on the server and require the access to be handled through ConcreteCMS’s processing script. This can then enforce the permissions set through the CMS. If files are being accessed directly by visitors through their physical path on the server, this will be handled by the webserver before any permissions, etc are processed.

Hope this helps!

I appreciate your help- but this seems very complicated for my level (unless there is a how-to video somewhere). I don’t recall this issue with v8. I’ll try to follow the links you sent and hope I can fix it- thanks for your reply.

Hi w2f - this would have been the same in V8 as well… Is there a chance that whatever software you are using to create the emails is following the link you paste into it (which should be something like domain/download_file/<random_hash>) and changing it to the direct url which would be something like domain/application/files/####/####/####/filename

If so, that would be the email software and not ConcreteCMS that is doing that… In either case, to prevent people from having direct access to files the File Storage Location will be the way you want to go :slight_smile:

Cheers

I read through the Editor Docs link and realized that I had overlooked changing the File Manager Permissions in the Dashboard- that has resolved the issue now- but I’ll catch up on the storage locations too - (I had everything set for so long in v8 that after upgrading to v9 I forgot to check for details like this). thanks again- really appreciate the support.

2 Likes