IMHO, anything you don't want everyone to see- should not physically reside in webshare- period.

On one hand this is a general rule for me- on the other- it sounds like you're doing some fun stuff. It seems your admin will either be an editor of the content- or your html files are HTML::Template files, that are prefed by admin app- very witty..

So, these *are* or are not "static web pages" or are they templates that are fed by admin??

(Still, I say nothing in webshare that you don't want everyone to see..

For example with shared hosting, or whenever you're at the mercy of root..
What if they disable some apache directives that now make your .htaccess files worthless? Then your content is free for the viewing. Yes, this is a wild and whacky rare possibility. What if cgi stopped working? Is your content unprotected? If your cgi serves content not normally accessible via http, then if things break, nothing is lost. )

That junk said..
It seems like your ap is *not* using authentication? Is that correct? I mean, authentication *inside itself* ...

Maybe you're not familiar with CGI::Application::Plugin::Authentication, it took me a little while to figure out how to use it, it was frustrating at first- but it sets some sort of a standard for doing authen. You can use .htpassw files even if you want, i think...

The idea is that every runmode (run, state, screen) of your cgi app requires a check. And if you don't store files in webshare, you don't have to worry about the rest.

These really are static pages. One page is just a list of links to admin options, and another is an upload page. There is a templates folder inside the admin directory that holds my H::T templates for the application, but the templates are completely separate from the static pages I want to use in this case.

Please pardon my ignorance, but I am a little confused about moving these kinds of pages outside the web accessible directory structure. If I do that, don't I get stuck still opening and serving these pages directly within my app? And if I don't use .htaccess to redirect requests for files to my app, how do I require authentication to access the directory contents? I don't want to use .htpasswd, I want to use the same authentication method as the rest of my app. I may be missing something, so I am more than willing to learn a new way of doing things if it is more efficient/effective.

I am using C::A::P::Authentication to handle auth for my application. All of my run modes are protected and it works great serving dynamic content. With static content, I have 2 options. One - try to redirect after authentication and two, manually serve dynamic pages. If I do a redirect, I get stuck in a loop because each request ends up passed to my app, which redirects to the page which sends the request to my app...... So it looks to me like the only option is to manually open the static html files and return them from my app. I was wondering if there was a way to serve the static content without opening an delivering the files that way.

Thanks for taking the time to answer my questions,
digger

First my suggestion, then a bunch of ranting about why- to prove I have similar irks about the suggestion.

Suggestion:
1) do not redirect
2) serve all content (dynamic, static, whatever) which is part of your dynamic application- through the application. yes, read in the freaking html, spit it out. Or code it inline with cgi.

Why oh why?

You want to serve dynamic content via dynamic means. And *anything* that is not dynamic, should be served statically!? Right? Makes sense, right? Sounds clean thoughtful.. etc.

Yes.

Fact of the matter is- your application is not a static application. It is a dynamic application. It takes user input.
(i guess if we get more liberal, even serving static pages is a dynamic application at play, user input is a request to apache, and the static content is .. well.. you see my point- but for converstation's sake, normal httpd daemon we refer to as static. Maybe the distinction could be drawn at; if the user client can do something that will change the server data content somehow- like uploading, saving, changing parameters, etc- )

Ok so here's where I'm going with this and it's going to make you cringe. It would to myself as well.

This is *one* possible way to attack the problem. It will feel wrong at first.

Serve static content via dynamic means- as long as the activity is taking part in your dynamic application.

Yes. You heard right.

But why on earth would you! It's just html!!! We don't *need* do this! This is apache! Separation of church and state please!!

Look, there is one very freaking important thing about perl that the high monks keep repeating- Do not optimize off the bat.


Make your application do what it should do. That is #1. Afterwards, optimize...

It should be a lot easier to have a runmode that only serves a "hello" page, a welcome page, that has static content- via your cgiapp- then to serve this as a html page that should only serve if user is logged in- That makes it a runmode.

How many people will use installations of your application? What is your team made up of? How many developers are there?

I suggest keep everything that should be accessible only when you log in via your cgiapp- to be passed via the application.

Yes it's slower.
Yes, apache should do that.

btw, I have a cgi app that is purely about serving static content, html, pdf, whatever. All through a cgiapp, the cgi app is doing the authentication, checking who this is, if they can read this, if they have access and why to this section of things.. it's not a secondary thing to check all that, it's the main thing, content is secondary in that case. For our side at least.

There is also the part where you consider where your time is well spent, and where we may want to let some loose ends be. In favor of more important things.
If later you have a lot of users, many people use installations of the app, this can be revised. No of course this is not the only option. This is perl, this is apache, this is likely some kind of unix, so the possibilities are not finite.

By the way, your cgi-bin, although accessible via http, is likely not *in* webshare.. it might be a symlink. There is a difference. I'm not advocating this is the way to protect content- but.. I just want to throw that out there.

You should have shell access, man symlink.