(reposted after my original thread ended up on the 'installation' forum)

Hey all,

Attached is an early build of a module I am working on - 'SecureFiles' allows content managers to set file access permissions on folders. Files within these folders will be subject to permission checks through sapphire.

As you might not know, files uploaded to you SilverStripe site are open to the internet - that is, anyone who knows the right URL will be able to get to your files.

Features:

New CMS tab 'Security' for folders, allows content editors to give specific users access to specific folders
Privileges are inherited from parent folders
Rules enforced by an optimized controller.
Unsecured folders are still allowed direct access
New permission code "Access to Secure Files" overrides folder specific privileges
Prevent Google indexing your private files!

This is an early version, so documentation is still sparse, however it should be this easy to install:

1. Extract to your SilverStripe directory

2. Run dev/build?flush=1

I would like to here about any bugs of feedback you might have, so please add to this thread.

Hi Hamish,

I've been using securefiles with SS2.3.1 which works like a dream. I'm really hoping to use it with 2.3.2 since a client requires a secure area and support for different languages.

For translatable to work, my choice is either go back to 2.2.4 or upgrade to 2.3.2.

I tried your module with 2.3.2beta1 but when I click on a file I get the raw response ala...

%PDF-1.4 %�쏢 5 0 obj <> stream x�UP�NC1
KYb��...etc...

Do you have any suggestions?

Cheers,

Barry.

Okay so after a lot of reinstalls using different versions of silverstripe I finally discovered the problem was to do with http headers.

I was using a very simple extended image class, which I put at the bottom of mysite/code/ArticlePage.php

<?php

..

class ArticlePage_ArticleImage extends Image {
 
   function generateSmall($gd) {
      return $gd->croppedResize(60,60);
   }
   
   ..
 
}

?>
.
.

Note the newlines after the php close tag ?>

Argh!!! DAYS were spent trying to track that one down.

"When browser requests a page, the http server sends http headers before html contents. It means that if you are using php to send any headers, it must be done before writing any html output.

source: http://www.trap17.com/index.php/php-header-problem_t33323.html

I think, because the securefiles module outputs a http response direct to the browser, people should be careful to not have any whitespace outside their <?php ... ?> tags.

Cheers,

Barry.

Keeny: Keep in mind that PHP closing tags aren't required - IMO if a file is purely PHP it is best to omit them.

Hi AJ,

Yeah - I noticed some people using that style of coding (leaving out the php close tags) but was unsure why they were doing it at the time. I'll definately consider using that style now.

Can anyone think of a 'con' to leaving the php ?> close tag out?