Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.
 
PerlMonks  

htaccess and cookies

by kidd (Curate)
on Jun 26, 2002 at 03:36 UTC ( [id://177280]=perlquestion: print w/replies, xml ) Need Help??

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

Im tryin to upgrade my site in order to provide a better service, so I have to questions.

1. I have protected pages that I protect through .htacces, so when someone tries to acces them, they have to enter their username and password trough a popup window. But what I want is for them to be able to enter the username and password into a normal HTML form so they can gain acces to the protected pages without the popup window. How can I do this with a CGI ?

2. Can someone point me or tell me how can I set up a cookie with the username, password and expiration date of 999 years(forever), then how can I read it again, and how can I delete it? I know little about cookies and less about cookies with perl, so if you could give me like a really in diapers tutorial it would be great...

Thanks

edited: Wed Jun 26 15:32:54 2002 by jeffa - title change was "HTACCES & Cookies"

Replies are listed 'Best First'.
Re: (newrisedesigns) .htaccess and Cookies
by newrisedesigns (Curate) on Jun 26, 2002 at 04:15 UTC

    Well, i'm not so sure how to send back headers that would allow you to sign in a user through Apache UserAuthentication (your first one), but I don't think you want to do that anyway, unless you don't mind having large .htpasswd files :)

    What your asking for is quite large, so I'll try my best to explain some of this, but you'll need to find some other tutorials (i have some links).

Re: HTACCES & Cookies
by bronto (Priest) on Jun 26, 2002 at 07:37 UTC

    About question one, reply is: don't do it! It's possible to do it exchanging authentication information in hidden fields, but it's far more unsecure than letting the web server doing the authentication for you: it's part of its job and it knows well how to do it. Furthermore, basic authentication is unsecure in itself, and increasing unsecurity by letting your CGI do the authentication is really bad, bad, BAD.

    Anyway, if you need to know user's id within your code, you can read it from the environment ($ENV{REMOTE_USER}).

    About question 2: simply use CGI. Do a perldoc CGI and read on: there is all that you need -and much more.

    Ciao!
    --bronto

    # Another Perl edition of a song:
    # The End, by The Beatles
    END {
      $you->take($love) eq $you->made($love) ;
    }

      Using CGI to authenticate users is no less secure than using basic HTTP authentication, credentials are passed as plain text in both cases. You can allow your users to login via an SSL connection if you want it more secure.

      Your best bet is to create a cookie that contains certain information (IP address, username, time, expiry, for example) and an MD5 digest of that information and send that back to the client after a successful login. Each subsequent request just makes sure the cookie hasn't been tampered with by checking the data in the cookie against the MD5 hash, you need not check the username against the password each time. This has the added benefit that you're not sending a username and password on each request. For a great explanation of all things authentication/authorization, have a look at the Eagle book chapter 6, it's mod_perl specific but explains the concepts very well.

      Steve.
        Using CGI to authenticate users is no less secure than using basic HTTP authentication, credentials are passed as plain text in both cases.

        I don't claim to be an expert in anything. Thus I don't believe I would be able to do a CGI authentication routine better than the Apache programmers.

        Summing up, my reply meant: are you sure you are able to do with a CGI a better job than apache does?

        Many people could. I wouldn't. And I don't recommend to others what I wouldn't do myself.

        About SSL and mod_perl, I preferred not to cite them. I preferred to focus on the intrinsic weaknesses of a self-made CGI authentication against an (already weak) basic authentication.

        I subscribe your opinion on SSL and mod_perl, with a preference for SSL for the same reasons as before: personally I don't think I would be able to do with a self-made mod_perl handler a job better than SSL.

        Ciao!
        --bronto

        # Another Perl edition of a song:
        # The End, by The Beatles
        END {
          $you->take($love) eq $you->made($love) ;
        }

•Re: htaccess and cookies
by merlyn (Sage) on Jun 26, 2002 at 17:26 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://177280]
Approved by grep
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (8)
As of 2024-10-10 17:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    The PerlMonks site front end has:





    Results (45 votes). Check out past polls.

    Notices?
    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.