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

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.

Comment on Re^2: CGI::Application::Authentication and Static Pages

Replies are listed 'Best First'.
Re^3: CGI::Application::Authentication and Static Pages by digger (Friar) on Jan 18, 2008 at 16:00 UTC
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.	[reply]

Replies are listed 'Best First'.

Re^3: CGI::Application::Authentication and Static Pages
by digger (Friar) on Jan 18, 2008 at 16:00 UTC

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.

[reply]