Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Never Write Another Login Script Again!

by jbeninger (Monk)
on Jul 08, 2003 at 19:06 UTC ( [id://272390]=perlmeditation: print w/replies, xml ) Need Help??

Greetings High and Mighty Monks.

I've got a module I'm considering putting on CPAN, and I'd like your thoughts on the issue. As I can already hear the impending forehead *slap* as I find the 99%-functionally-equivalent module that's already on CPAN, I'd just like to mention that I've done a fair bit of searching, and haven't seen anything quite like this yet.

The Pitch
How many times have you gotten started on a new project, only to have to go through the tedious, yet necessary process of setting up a user/session management system? Logging in, logging out, "Forgot my password"...

Well no more! Now with a minimal amount of setup, you too can have a fully-functional user login system based on CGI::Application!

By simply including the line:
    use base LoginRequired::DBI;
in your application, all of your login difficulties will disappear! If someone calls the script without being logged in, they're brought to the login screen. If they've forgotten their password, they can have it emailed to them. If they don't have an account, they can create one.

The Small Print
Okay, it's obviously not *quite* as simple as that, but the as-yet-unwritten pod will provide the details on how to use each of these features. Most of the setup involves things like defining database username and password, and column-names for the logins, password, email, etc. Most of these have defaults, so it's literally a 2-minute job to make a LoginRequired application.

I've tried to make the module generic in the sense that it can be easily modified for different databases and different methods of storing sessions (right now it uses Apache::Session). But I've also tried to restrict it to four basic operations to prevent it from getting too bloated (login, logout, retrieve password, and create user).

I'm already looking forward to the day when I won't even have to think the word "login" again. What do you think of the whole thing?

James Beninger

Replies are listed 'Best First'.
Re: Never Write Another Login Script Again!
by eweaverp (Scribe) on Jul 09, 2003 at 00:37 UTC

    I say, if it works, upload it, with your email address, and if people want to use it, they will use it. If there are bugs, they may complain to you, or they may fix it, and _then_ complain to you.

    It certainly seems useful; although not for me. You may want to think carefully about extensibility options. Is it easy to add new fields (even required fields?) Is there an clean API exposed that makes it easy to fool with the underlying procedures if it is necessary? Or is everything locked up pretty tightly?

    How secure will it be? Plain-text storage? Encryption of some mysterious kind? SSL connections for log-in?

    Can it also control access to plain .html files, and not just CGI content? Will it integrate with .htaccess?

    No matter what, nobody's going to get hurt. So upload at will.

    ~evan

      Thanks everyone for your comments. It's definitely given me some things to think about, as well as a tentative feeling that I'm on the right track :)

      The scope of this project is web apps with a relatively simple login process - PM for instance. It is not meant to be standalone user management system. It's still up to the developer to add the user preferences, admin areas, etc. if they're required. One motivation was that a login system could be implemented quickly, and then refined later.

      When creating a new LoginRequired instance, a number of parameters can be used to customize the login process. These are things like "user_id_field", "password_field" that define database column names and a "confirmation_fields" array defining which fields are used to confirm an identity before emailing a user a password. Just about anything I could make customizable I did.

      I've also worked at making it relatively simple to use different technologies for session and user management. Overloading the "getSession" and "commitSession" functions is all that's required to change the way sessions are stored. There's a similar set of functions in the works for storing user information.

      Given the comments here, I think I'll take a couple of days to refine and document the beast and put it up on CPAN. I was going to go further in describing it, but it's easier when there's some code I can point to.

      Thanks again for the comments.
      James

Re: Never Write Another Login Script Again!
by xdg (Monsignor) on Jul 09, 2003 at 00:40 UTC

    That sounds like a fantastic idea, though it also sounds like it may be on the more difficult side to make it as easy to drop in as you suggest.

    If you start this, please post news about it (status, intermediary works, etc.) on the newly-created CGI::Application Twiki. You might consider documenting your design and build process there as an ongoing log or tutorial or something -- that might have an educational value similar to that of the module itself.

    In any case, best of luck -- I look forward to seeing it.

    -xdg

    Code posted by xdg on PerlMonks is public domain. It has no warranties, express or implied. Posted code may not have been tested. Use at your own risk.

Re: Never Write Another Login Script Again!
by chunlou (Curate) on Jul 09, 2003 at 02:09 UTC
    Good product idea.

    But what sort of user accounts are you talking about? LDAP or any arbitrary account? And always DBI? Via HTTP as well?

    Especially I don't see "create account" is a generic job. Consider a Human Resources app. Creating an account means you also have to indicate who is his superior and who are his subordinates. But in order to do that the superior and the subordinates must be already in the system. Hence, "create account" is a recursive process in this case.

    Obviously, I'm just not sure about the scope of your application and your problem boundary.
Re: Never Write Another Login Script Again!
by theorbtwo (Prior) on Jul 09, 2003 at 07:39 UTC

    Consider also, that some sites prefer to mail the user there password, some prefer to create a new random password and send that, and still others prefer to send a link that will do the second, but only if it is clicked. You should make it easy to do any of those.


    Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

Re: Never Write Another Login Script Again!
by barbie (Deacon) on Jul 09, 2003 at 12:31 UTC
    I like the idea and probably would use it, provided it ISN'T locked into CGI::Application.

    While I can appreciate that that module is good, it has never fitted how I create/build/operate dynamic websites. While working for Questions (QIIS) I did develop an Identity module that handled all the user, cookies and session management. As I use a plugin approach (shamelessly stolen from my experience of designing an EJB application a few years ago), it means website interfaces can appear the same, but with one having the plugin and the other not. I could also add/remove the plugin on the fly, which a tie in to CGI::Application wouldn't do.

    I might be motivate to send some patches once you have a working module :)

    --
    Barbie | Birmingham Perl Mongers | http://birmingham.pm.org/

      <metoo>I think things here depend on how complex the module will be. While I would like to see some basic authentication support in CGI.pm, a fully functional authentication module might be better as a stand alone.</metoo>

      Regardless, I am sick of writing authentication systems, and I think a Perl mod is sorely needed. I was even going to do one my self, until I realised how complex it could be. Think about user groups, access levels, and how to restrict the operations of users, groups and levels. Should logging be included... etc. Well, if you can get a 0.0 version to CPAN I'll love to add to it (when I have time, and I happen to be sober of course).

      10POKE53280,A:POKE53281,A
      20?"C64 RULES ";
      30A=A+1:IFA=16THENA=0:GOTO10
Re: Never Write Another Login Script Again!
by hardburn (Abbot) on Jul 09, 2003 at 14:02 UTC

    There is Apache::AuthCookie, which sounds quite similar to what you're doing. It's tied into mod_perl, though. I've been dieing to see a non-mod_perl solution (since my current employer has a wicked combination of legacy CGIs and political issues that keep us from using mod_perl).

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    Note: All code is untested, unless otherwise stated

Re: Never Write Another Login Script Again!
by NetWallah (Canon) on Jul 09, 2003 at 16:16 UTC
    I have used very similar generic functionality in the past, using pretty good free code called SQSecurity.
    This is based on using an IIS-ASP (Windows) web server, and a database.

    You may want to download that, and perhaps plagerize a few ideas. Cheers.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://272390]
Approved by Mr_Person
Front-paged by hsmyers
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (4)
As of 2024-03-19 09:31 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found