I have loaded a 3rd party PHP document management system for some of my users, but one key feature doesn't work. When the user wants to view a word/excel/powerpoint document, the browser returns the file, byte for byte to the browser, which looks like garbage.

There is a simple way to load a file to display properly, via calling from an IFRAME tag. For example:

<iframe src="English - Russian Keyboard Equivalent.doc" width="100%" height="100%"></iframe>

would actually load the word document into an IE browser or give the Firefox viewer the option to open the doc into Word directly.

The problem I have is that the documents are stored outside of the web root, for security purposes. My question is this, How do I go about loading these documents into an IFRAME, while maintaining the document security? Copying the file into the web area for display violates document control and security, but doing a raw data feed, like the program is currently doing obviously isn't working either.

Any thoughts?

    file_server.php:

    <?php
$file = '../file_directory/' . basename($_GET['file']);
if(file_exists($file) && is_readable($file))
{
   readfile($file);
}
else
{
   header("HTTP/1.0 404 Not Found");
}

    main file:

    <iframe src="/file_server.php?file=English - Russian Keyboard Equivalent.doc" 
width="100%" height="100%"></iframe>

      That doesn't seem to work for me. I'm getting a blank IFRAME. I'll keep looking at it...

        jkurrle;10886990 wrote:

        That doesn't seem to work for me. I'm getting a blank IFRAME. I'll keep looking at it...

        At a glance, I see 3 possible outcomes for this code snippet:

        1. You should be getting a blank (error w. error logging on and/or error output off.)

        2. Garbage (lacking a header to specify file type)

        3. 404 page (your file path is wrong or the file not readible by web server)

        Try injecting a header before the readfile()

        header("Content-Type: application/msword");

        adjust Content-Type depending on file type.

          Put the header tag in and still get a blank frame. Any other ideas on what to try or some other methodology?

            Try calling the PHP file directly rather than via the iframe tag in the other file. Check the webserver/PHP error logs. Try adding the following to the top of the PHP script:

            <?php
ini_set('display_errors', 1);
error_reporting(E_ALL);

              I shouldn't open my mouth but I will eventually use readfile myself so I had a look.
              You did hopefully check the user contributions at http://se2.php.net/manual/en/function.readfile.phpThere was a lot of comments that I know will hit me in the face if I am not taking proper actions.
              One thing you could try on your testbench first is to see if it works with files inside your webroot just to verify the framework.

                Ok, got past the issue by using Apache's ALIAS module, but now I find the darned program renames all files 1.dat, 2.dat, 3.dat as it saves them. I can retrieve the original name out of the mysql database with no problem, but how would I do a document name translation on the fly so the browser knows what application to use when loading the fly?

                Any ideas?

                  After a little bit of digging I am making an assumption that with proper content type, for example: pdf

                  header("Content-type: application/pdf");

                  it should take care of itself...Note this is an assumption. I'll see when I get there myself.

                  Ooops, and maybe the file extension is important on Windows OS

                    Well, sending the header does open MS Word, but it does not like the dat extension and asks what do I want to convert it from. I need a way to change the name on the fly, apparently...

                      Whoops! It looks like the page is actually sending the HTML code to word. I'll have to relook at it...

                        I ended up running a couple of exec() statements that would delete any preexisting symbolic link to the file, then create the symbolic link to the dat file with the actual file name. Once I did that, I could link an IFRAME to it.

                        Thus, the working solution came out like this:

                        1) Use Apache's ALIAS directive to create a link to an external directory and say it is in the web server's root path.

                        2) Use PHP's exec() command to delete any preexisting symbolic link with "rm -f" (linux command).

                        3) Use PHP's exec() command to create a symbolic link with "ln -s" (linux command) in the "data" directory

                        4) Link to the new symbolic link with an IFRAME html tag.

                        In this way, the data is still outside of the web root, yet still protected. The only hang-up I'm having is that I cannot delete the symbolic link at the end of the script, as it deletes the link too quickly, and the IFRAME doesn't work.

                        It's not pretty, but it works...

                          Thanks for the solution. This will be useful.

                            Write a Reply...