in reply to htaccess and cookies

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) ;
}

Replies are listed 'Best First'.
Re: HTACCES & Cookies
by stevenc (Novice) on Jun 26, 2002 at 10:32 UTC
    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.
[reply]
      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) ;
}

[reply]
        The reason im making this changes its because I discovered that sometimes more than 3 people are using the same username and passwors, when its suppose to be a personal acount...what Im trying to do its to check if a username is log on at the same time from two different computers, that way I can make the username and password really personal...

        If someone has a suggestion Im all ears...here was my plan:

        1. Let each username to acces from two different computers(not at the same time, something like from work and at the house). I was thinkin to acomplish this by setting up cookies.
        2. Save in a log when a member logs in. Everytime someone tries to log in, it checks the log and sees if that username its not already logged on. In case it is then denies access.

        That was the plan. Im using .htpassword and .htacces, Im running out of ideas, so if someone could help me it would be great... 2.

[reply]
        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.

        You mean the HTTP protocol, not ASF developers. They've just implemented the protocol, not designed the auth routine.

        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.

        What are they? Apart from having to code it oneself, I fail to see the shortcomings. Basic auth is already as insecure as can be, it can't get any more insecure unless the CGI replacement is poorly implemented.

        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.

        Bit of confusion I think, I never mentioned anything about writing your own SSL substitute in mod_perl, I merely mentioned you could use SSL to prevent evesdropping on the initial login, which in the case of a form would POST username and password details in even clearer (non-base64 encoded) text than basic auth.

        Summing up yes you can do a better job with CGI than basic auth, at the expense of understanding and development time and the fact that clients may choose not to use cookies, and a CGI script must check each cookie on each request.

        Steve.
[reply]

In Section Seekers of Perl Wisdom