Protecting Web-Accessible Directory and Subcontents

[eluser]skfriese[/eluser]
Is there any way to restrict access to the content within a web-accessible folder using the login details contained within a PHP session? Please read scenario below before replying. ;-)

I have an existing CodeIgniter application that happens to serve up web accessible content. Users are required to login to view the content, and their sessions are managed through DB-based PHP sessions. This all works fine, for the most part. However, it is still possible to access the web-accessible content directly by bypassing the CodeIgnitor application altogether and entering the URL to the content within the browser's address bar.

Now, the reason why this is now a problem is that there was never a requirement to "lock down" the content. The application merely tracks the user's progress through the content using AJAX if the user is logged into the application. No such progress is tracked if accessed "outside of the application". No big deal, but the client wishes to lock this content down now, and only allow those logged into the system to access it.

Being familiar with htaccess/htpasswd, I am able to restrict access to main content folder, but then the users must login again to launch the content. Thus my question above. Is there any way to "set" the $_SERVER['PHP_AUTH_USER'] or $_SERVER['PHP_AUTH_PW'] through PHP, so that I can set the HTTP authentication criteria when the user logs into the application? I'm also familiar with passing requests to the content using a "proxy" PHP script and authenticating that way instead, but that is not an option with this type of content as it is structured.

Any direction is greatly appreciated. I've attempted some serious Google-Fu over the past couple of days with no luck so far. :-S

[eluser]sophistry[/eluser]
if you have to use the standard auth technique of throwing up an htaccess type dialog, do not use htpasswd. control it all in PHP only. use header() with an unauthorized return header 403. that lets you throw up a standard dialog box. see php.net for details in the header() function manual page and comments.

sounds like you have a bunch of files sitting in open directories and people can grab them directly if they know the location. there are many ways to keep content protected. the first one that comes to mind is to just put the content "outside the web root" so that your webserver can not serve it directly. that means that you'll have to re-write some code where you call the content into your CI app to make it so that the app code can get to the files.

cheers.

[eluser]skfriese[/eluser]
Thanks, sophistry.

I'll play around with placing the content "outside" of the web root, as there is only a single "launch point" within the application for the content, and this may be easier than trying to go the route of basic/digest authentication through headers. I'm trying to avoid HTTP authentication (causing the user to enter "more" login information to access content), since the user will already be authenticated by the CI application through a standard HTML login form.

A concern that comes to mind, however...

If the content is sent to the browser through my CI application from a non-web-accessible folder, will the content be able to make relative requests to other content embedded within itself after it has been launched? My first assumption is that any links within the content to other assets (HTML files, video, etc.) will be broken. This PHP "proxy" method is usually only used when single files need to be shipped to the browser, such as archives, images, etc... Not when, say, full (existing) HTML/Javascript-based learning modules, etc. is the meat of the content you're serving up. I could be wrong, and I'm actually hoping that I am. Can you comment on this? (Thanks again)

[eluser]sophistry[/eluser]
it all depends how you wrap it up. if you put an entire 'web page' and its prerequisites ouside the webroot you'll run into the problems you outlined. if the paths to content are exposed in the HTML, they are exposed and there is nothing you can do about it short of re-writing the app.

and realistically speaking, you can't protect js anyhow without a lot of pain - it has to get downloaded to the browser to work.

what exactly is the sensitive part your boss wants to defend? images, videos, flash? whichever it is, just sequester that out of the webroot and write a little CI controller to serve the content, taking care to only allow the localhost (or whatever IP) to access it.

[eluser]Phil Sturgeon[/eluser]
[quote author="skfriese" date="1193508340"]If the content is sent to the browser through my CI application from a non-web-accessible folder, will the content be able to make relative requests to other content embedded within itself after it has been launched? My first assumption is that any links within the content to other assets (HTML files, video, etc.) will be broken. This PHP "proxy" method is usually only used when single files need to be shipped to the browser, such as archives, images, etc... Not when, say, full (existing) HTML/Javascript-based learning modules, etc. is the meat of the content you're serving up. I could be wrong, and I'm actually hoping that I am. Can you comment on this? (Thanks again)[/quote]

Have your PHP outside of the webroot, but your assets within easy grasp. This makes perfect sense right, as you lock away your valuables but not the crap you dont mind giving people (in this case images and CSS).

Using something similar to my asset manager you can easily keep tabs on where files are in a dynamic manner. That may be a tad O.T.T for you but is very useful for logical seperation of assets.