Viewing word documents on server and localhost

ok, i’ve had a long night and i just need to get this sorted before i can finish. I think it’s so simple it’s annoying. anyway, i have a section where users upload a copy of their cv. The cv is stored in a directory on the server, and the path to the cv is stored in the database.

Now i am trying to view the word files. Simply view them, so it opens up in word. I’m fairly sure this will work as a standard hyperlink on the server, but on my local computer the path from the database to the word document is absolute ie c:\workspace\site\userUploads\cv\cv1.doc - how can i view this document in word? Firefox balks saying it doesn’t know how to open the address as the protocol (c) isn’t associated with any program. Adding a file:\\\ prefix doesn’t work.

Link to the URL of the file (http://example.com/userUploads/cv/cv1.doc) not the path on the file system.

thanks for the reply.

In my application.ini i have the config variable:

vacancies.fileDestination = APPLICATION_PATH "/../vacancyApplications"

…which is needed when creating directories. Yet on my localhost this always resolves to the c:\ filepath, not the (local) url of the project.

Also, will that still work if the documents are uploaded to a directory above the documentroot? ie:

/myDomain/userUploads/
/myDomain/www <–docRoot

If you upload the file above the document root, then you can’t link to it. Nobody can directly download that file.

You either have to put the files somewhere that you’ll be able to link to it, or create a script which reads the file and streams its content to the user.

You can’t hand out local file paths. “c:\workspace” doesn’t exist on my computer, and it definitely doesn’t have your files in it.

The path only resolves to c:\ on my localhost (local dev computer) - on the server it resolves to /domain/project.

Having the documents above the document root is the most secure way i can think of storing them (apart from blobs in the db?, :nono:), i really don’t want them in any publically accessible location, even if restricted by a htaccess.

What about when the user of the app wants to view a cv, a copy is made in a temporary directory created in the public webspace, so it will open in word, then deletes both directory and copy of the document immediately? Or is there another way of serving these documents whilst keeping them secure?

Yes, “create a script which reads the file and streams its content to the user” is the other way

header('Content-type: application/vnd.ms-word');
header('Content-Disposition: attachment; filename="document.doc"');
readfile($filepath);

You’d need to build whatever security you want into that script as well. By itself that code is no more secure than just placing the files in a folder on the web.

…and that would still open in word, or output to the browser?

Any suggestions for security? I’m using zend auth & acl, as well as checking for a session identifier. And if the documents are copied to a temporary directory that is deleted after is streamed, i can’t really think of many more measures than that? I’m more worried about bots or malicious users getting the directory index, or perhaps using IndexIgnore *.doc in a htaccess?

They’re the same headers Apache is sending when you directly ask it for a .doc file somewhere below the document root.

There is no difference to the end user. If .doc opens in Word, then the file can be opened in Word.

But with a script like this, the file can be anywhere on the filesystem (that the user the web server runs under can access).

If you check the session identifier in the top of Dan’s script then only those people where the session matches can download the file. The script copies the file directly into the person’s browser so there isn’t a need for a temporary directory to be deleted.

They’d need to access it via the PHP script Dan suggested if you place them outside of the public section of your site because then only scripts running on the server can access the actual files.

With that code the filename in the address bar might be abc.php while the actual file being delivered is zyx.doc