Re: CGI::Application::Authentication and Static Pages

[digger]

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

[leocharre]

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.

[digger]

You have given the most thorough treatment of this subject I have found anywhere. It might even be a great Meditation or part of a tutorial on C::A. I only wish I could ++ this more than once.

In my other C::A based apps, I have written a runmode called "dispatcher" that just serves my static pages. It just felt weird - as you said "separation of church and state please." So, since it was a little uncomfortable, I thought I would root around a little to see if there was a better solution. It looks like this is the best solution in a shared environment. If I ever move to a VPS, then I will be able to look at a more integrated solution with mod_perl and Apache. For now, it will all go through C::A.

Thanks for taking the time to share your perspective on this. I feel much better about serving my content this way. As you said, it is slightly slower, but very consistent and easy to implement in any shared hosting environment.

I only wish for shell access. I am familiar with symlinks, and pretty comfortable at the command line, but my reseller hosting doesn't provide a shell.