0 users online. Create an account or sign in to join them.Users

Search

I contemplate to integrate some sort of client-relation management onto my site. I think the members extension is a good start.

I'm just wondering how to handle files uploaded by clients and of course client related files that can be downloaded by the client. Since there's no such thing as a "member files" extension (iirc) I'm planning to create an extension that would basically

  • allow members to upload files to a private location (per member and outside www root)
  • have the possibility to create private location categories (e.g. images, documents .etc)
  • allow members to download files that are meant for them (and only for them)

Still not sure if thats a good idea anyway, but well, why not?

I've done a ton of work on projects like what I think you're describing iwyg. I don't think you'll need any other extension if your running the members extension and running your forms from the front end of the site.

You could use the unique file upload field, if you were going to host the files on the same server as the site itself; or you might take a look at the Amazon s3 upload field that several in the community have made and I use personally.

When the file is uploaded by a member, they could assign permissions based on member role or member name or really any criteria you might choose for them in a front end form. Then you could create a datasource that would relay the files that only those who had permission (based on login) could view/download.

Hope that helps.

The problem with unique file upload field is, that files would be public accessible.

You can use an .htaccess rule to prevent this, can't you?

willing to and fully enabled.

So, what do you think would be best practice for serving files to the client then? Looking up if the file belongs to the client (of course) and then setting file headers and write file contents to the buffer?

You could use something like the xsendfile module for apache.

If you build a download URL to a "dummy page" with a GET param (e.g. ?download=...), you can for example attach an event to this page which checks the permissions in the load() function. If everything is OK, you call the __trigger() function which may be something like this:

protected function __trigger(){

    $file = rawurldecode(DOCROOT.'/'.$this->_upload_dir.$_GET['download']);
    if(!is_file($file)) return;

    $filename = basename($file);
    $filesize = filesize($file);
    $mimetype = $this->getMimeType($file);

    header('Content-Disposition: attachment; filename="'.$filename.'"');
    header('Content-Type: ' . $mimetype);
    header('Content-Length: ' . $filesize);

    $result = @readfile($file);
    echo $result;
    exit();
}

I am not sure about readfile though, it might not work on very big files.

You will need a getMimeType() function, which you should be able fo find in Symphony's core. (I think we added a function when we implemented the core email API.)

You could use something like the xsendfile module for apache.

Sounds promising!

outside www root

missed that bit. sorry.

I just took a short look at the Apache xsendfile module. Now that is great! Native Apache handling of files, still PHP script processing. Cool. That also means: no memory or speed problems.

If you are on Debian, installation is rather simple. In the shell, type the following (as root):

apt-get install libapache2-mod-xsendfile

I'd definitely check this. Sounds promising indeed.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details