Re: Re: HTACCES & Cookies

[bronto]

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

[kidd]

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.

[stevenc]

You can use Apache::Session (even under CGI) for this. Have a look at the documentation and see if it fits your needs. Another positive reason for rolling your own authentication routine is so you can log users out, something which can't be done with basic auth.

Steve.

[stevenc]

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.