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.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.