Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Re: Starting with CGI::Application(::Session) and Logins

by weierophinney (Pilgrim)
on Aug 23, 2004 at 01:15 UTC ( #384996=note: print w/replies, xml ) Need Help??

in reply to Starting with CGI::Application(::Session) and Logins

The way I've approached the issue is thusly:

  • Logins happen once per session, usually
  • Logins usually have to do with user authentication, user creation, and user management -- all potential run modes for an application of their own
  • Other applications, built on CGI::App, may require an authenticated user, but don't care how that happens -- only that certain traces indicating a user was authenticated are present
  • The way to track whether or not a user is authenticated is usually done via a session and/or a cookie

There are a lot of applications out there that look like they're doing everything -- user creation, user authentication, user management, shopping carts, forums, etc., but usually, when you dig deep in the guts of them, you'll discover that they are built modularly, with each module doing one thing, and one over-riding module/application binding it all together.

CGI::Application can look like that, too, but usually what you'll find is good authors have written a super class of CGI::App that checks for authenticated users, active sessions, etc. -- and that each separate application (user management, shopping cart, forum, wiki, etc.) then uses this as its base. The super class will usually then have some sort of mechanism that redirects to the user management class instance when authentication is necessary. Each application has its own class -- that way, when you go to refactor, debug, or extend it, you know that that class does ONE thing -- and everything to do with that one thing -- and that one thing ONLY. It may have many run modes, or very few run modes, but you know when you look at your shopping cart class, you're not going to be doing anything that affects your forum logic. (You may even find that sometimes if your class gets too big and unwieldy that it's time to refactor it and break it into more distinct applications; but that's another story.)

So, again, the basic idea is that you have one CGI::App class that handles user authentication and everything to do with user management, and then have the authentication method take care of initializing a session. Then your other applications all inherit from a super class that looks for that session (hence CGI::Application::Session) in order to verify whether or not a run mode is allowed at a given point in time.

  • Comment on Re: Starting with CGI::Application(::Session) and Logins

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://384996]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (5)
As of 2020-12-04 15:21 GMT
Find Nodes?
    Voting Booth?
    How often do you use taint mode?

    Results (60 votes). Check out past polls.