TrinityInfinity has asked for the wisdom of the Perl Monks concerning the following question:

Well, probably not the best title, but here's my situation, and I've got little clue where to go next:

I have a perl-driven flatfile database that tracks items, updates them, etc. No biggie, it works great now, and has thus far been my biggest achievement in perl yet. The next stage of development is creating a way to administrate some of the program features (like only admins would be able to delete an item for example). This will require having some user system of some sort, where people who want to administrate would attempt to login, and either get in or not. Otherwise, they'd be a plain jane user like everyone else.

I'm looking at cookies now as a way to authenticate users, and envision some sort of file to store names, encrypted passwords, etc in, but I've never attempted any kind of user system, only things everyone can use.

Thus, does anyone have any pointers to introductory documents about things of this nature? Any experiences to relate? The more the better, as I'm starting from the very bottom rung on this ladder =)

Replies are listed 'Best First'.
Re: Administration Ignorance
by c-era (Curate) on Jul 11, 2001 at 19:14 UTC
    You don't need to authenticate users, let your webserver do it for you. Most web servers will pass the user name as an environment variable (plus there username is sent every time they request your page, no cookies needed). Then you just have a file with the user name and their privleges.
[reply]
Re: Administration Ignorance
by sifukurt (Hermit) on Jul 11, 2001 at 20:32 UTC
    Depending upon the level of security you're looking for, cookies aren't the best method. In the past, I've encoded authentication and a timestamp as a hidden field in a form. Obviously, you don't want put these things in as plain text. What I've done is this. After doing the initial authentication, grab the person's IP address, their username and password, and time() and make a delimited string. Then you'll want to encrypt it and escape it and include it as a hidden field. You can encrypt it with just about any of the encryption modules. I'm partial to Crypt::RC4 cuz I wrote it.
    use Crypt::RC4;
use URI::Escape;
$code = "$ENV{REMOTE_ADDR}\|$time\|$username\|$password";
$encoded = RC4( "my_passphrase", $code );
$escaped = uri_escape( $encoded );

    [download]

    Now at the top of each subsequent script, you'll unescape, decrypt, and split on "|" and then verify that information. By including time(), you can put a timeout on the individual sessions. The advantage to doing this is that you'll be able to ensure that the user hasn't gotten to this script through a bookmark or through hijacking someone else's session. And by including the timeout feature, you minimize the potential for damage if someone who is logged in leaves their system unattended. Only if the encoded IP address matches the current user IP address, the encoded username and password are accepted, and if less than, say, 300 seconds have elapsed is the person allowed in. Otherwise they're redirected some place else. If everything checks out, create a new string with the current time(), encrypt and escape it, and include the new string as a hidden field again.
[reply]
[d/l]
[select]
Re: Administration Ignorance
by arhuman (Vicar) on Jul 11, 2001 at 19:30 UTC
    You might need to use suidperl (see perlsec)
    And the Perl special vars :
    • $< (the real uid)
    • $> (the effective uid)

    To grant root rigths to some users (based on their uid)


    "Only Bad Coders Code Badly In Perl" (OBC2BIP)
[reply]

Back to Seekers of Perl Wisdom