Hi Elizabeth --
> Yep, that does it. I was just envisioning another way that
> avoided the
> second set of if/else switches by utilizing what CGI::App
> does so well.
I am about to go on a bit of a tangent, so please forgive me.
<ramblemode>
One thing I have consistently observed in all the years I've been developing
software (web-based, and desktop-based before the web) is this: It is rare
-- very rare -- that a particular implementation (or technology) ever
actually removes the need to make a particular decision or eliminate a
specific bit of complexity. Instead, it is virtually always the case that
all the technology or implementation is doing is pushing the responsibility
for the decision from one place to another.
Sometimes you may think you have eliminated a decision by making it
dependant on some other property or decision which has already been made.
This doesn't eliminate the need for a decision -- it just makes your
software more "deterministic" -- more automatic, less flexible. (That is
not automatically a good OR a bad thing. It is good to automate something
which should be automated, and it is good to provide flexibility where
flexibility is needed. It is VERY, VERY BAD to do the opposite!)
The best a programmer can do is to make sure that he or she does not add
redundancy to the overall system, by forcing a decision to unnecessarily be
made more than once.
Consider the following:
http://some.site/myfile1.html
http://some.site/myfile2.html
...OR...
http://some.site/myfile.pl?id=1
http://some.site/myfile.pl?id=2
...OR...
http://some.site/myfile.pl (POST DATA: "id=1")
http://some.site/myfile.pl (POST DATA: "id=2")
Here is a classic example of pushing around complexity. In all three cases,
the exact same decisions have to be made.
One the first case, the Web Server chooses which file to display. Pretty
straight-forward. In the second and third cases, a Perl CGI chooses the
file to display. In the third case, the use of POST data (instead of
URL-encoded parameters) superficially hides the fact that you still have two
distinctly different requests.
Ultimately, no matter which you choose, you still have a mapping of 1:1
between requests and output. Same decisions, pushed around! Net gain:
Zilch.
</ramblemode>
The short version: My recommendation!
If I understand your situation, you have some run-modes in an application
which require login, and other run-modes in the same application which do
not.
Simple answer: Separate your applications based on security! Provide a
separate Application module (*.pm file) and instance script (*.pl file) for
each application. Consider, for example:
http://my.site/widgetview.pl -- Search through and view widgets.
http://my.site/widgetmanager.pl -- Add, modify or delete widgets.
http://my.site/ordermanager.pl -- Add, modify or delete orders.
http://my.site/login.pl -- Login to access Widget Manager
Use case one:
1. A user is pleasantly browsing your catalog of useful and
affordable widgets.
2. Said user clicks on "Edit Widget" which sends them to the "Widget
Manager".
3. The Widget Manager, being an access-restricted application,
redirects the user to "login.pl" with a parameter set, "target_uri",
pointing back to "widgetmanager.pl".
4. User enters uid/passwd, clicks submit.
5. login.pl redirects user to $target_uri, which allows them access.
Use case two:
1. User clicks a bookmark for the "ordermanager.pl".
2. The Order Manager, being an access-restricted application,
redirects the user to "login.pl" with a parameter set, "target_uri",
pointing back to "ordermanager.pl".
4. User enters uid/passwd, clicks submit.
5. login.pl redirects user to $target_uri, which allows them access.
In this architecture, you are simplifying the system by moving the decision
"where do you go from here" to the web server! In terms of development,
things couldn't be easier. Admin-only apps can probably all inherit from
the same CGI-App custom super-class to implement security. Your "login.pl"
doesn't have to really be aware of where the user wanted to go -- it will
send the user anywhere "target_uri" tells it.
Would this work for you?
-Jesse-
----
Jesse Erlbaum, CTO
Vanguard Media
212.242.5317 x115
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
