|
Adding "state" to HTTP
by merlyn (Sage) on Aug 03, 2000 at 17:09 UTC
|
Since HTTP is a stateless protocol, the mechanisms for adding "state" (such as "logged in") have to use one or more of the following methods:
- Mangled URLs (including a session key somewhere in the URL)
- Basic Authentication (login box, usually managed in the .htaccess file)
- Hidden fields (if your application goes from one form to another)
- Cookies (but be sure to provide a way to logout easily, or time it out)
- Firing off a separate web server for each session (useful in low-volume
applications)
Each has advantages and disadvantages. Be sure to steer clear of anyone that
advises you to use any of the following:
- IP address, even if attached to browser type (it's not unique for proxies,
and can even change within a single session)
- The Referer (accessed through $ENV{HTTP_REFERER}) which can
be trivially faked and is stripped automatically at some corporate firewalls
- Any kind of client-side session management using Java or Javascript
(some firewalls actually strip this stuff, making your site useless to them,
and all security-conscious people have this stuff turned off anyway)
That should get you started. For more information on some of the session
topics, see
my
WebTechniques Perl column archives.
-- Randal L. Schwartz, Perl hacker | [reply] |
|
|
LDAP servers, MySQL and DBM or even plain text files can also be mighty useful for session management. Like the man says username or email address should be used to retrieve data.
| [reply] |
(Ovid) Re: Encrypting or Hiding Certain Info in a URL
by Ovid (Cardinal) on Aug 02, 2000 at 23:07 UTC
|
Generally, you shouldn't be asking for passwords this way. If you're on a *nix system, you can try using an .htaccess file to restrict users, or put the Web page and scripts on a secure server to guarantee that the information is encrypted.
If you go with the scripts on a secure server, use the post method so that data is passed seperately from the URL. Otherwise, users may simply bookmark their login information which would allow anyone with direct access to their machine to see their password in the bookmark.
Cheers,
Ovid | [reply] |
|
|
Of course it's not just *nix systems where you can use
.htaccess and you'll also find ways of using the server to
restrict access with almost any (modern) web server.
Apache Week has a nice
article on this, which has no direct Perl relevance, but
a subsequent article on
DBM User Authentication does contain Perl code.
In the end the option you chose should reflect the amount
of security you actually need.
Ugly
| [reply] |
Re: Encrypting or Hiding Certain Info in a URL
by ferrency (Deacon) on Aug 02, 2000 at 23:07 UTC
|
You can prevent the username and password from being displayed in the URL by having your form use method=post instead of method=get. If you're passing the username and/or password between scripts, you'll then need to use either hidden input fields or cookies instead of building a URL with a query from scratch.
Encrypting is another story. You can't really tell browsers to encrypt the password before sending it to you (short of writing a Java script that does it, or something like that), but you can ensure that the post/get data is sent securely by building your website on an SSL secured web server. You should ask your web hosting provider for information about SSL.
Or if you're doing it yourself, some of the easier answers are Apache_SSL and Apache with mod_ssl.
Alan
| [reply]
[d/l]
[select] |
|
|
If you are looking to encrypt certain parts of the form, I've found a site where they have RSA Encryption (for the paranoid who can't do SSL) done in JavaScript.
http://my.netian.com/~dubs37/eng_cyber_rsa.htm
| [reply] |
|
|
method=post only works for input types, not text links (IIRC). I've had the same problem as the original poster and had to create a text link (ie: a table of files to download) that has to include the username/password.
IMHO, looking at the answers presented by the monks is to go with cookies. It's a bit more of a pain than putting it in the string, but it'll prevent figuring out passwords.
Regards
| [reply] |
|
|
I was actually using method=get, i switched to method=post
and that solved my problem. I will be looking into perl_mod
or mod_perl.
Thanx,
Kiko
| [reply]
[d/l] |
RE: Encrypting or Hiding Certain Info in a URL
by steveAZ98 (Monk) on Aug 02, 2000 at 23:16 UTC
|
Generally you would save the username and password in a table with a unique user id of some sort. When the user logs in, you check that the username and password are valid and then you save the session id to a cookie or pass it back as part of the url. Your authentication scheme can then verify that the user is who they say they are for each page access. Apache::Session and CGI come in extremely handy for handling these matters. There are other ways to handle this will mod_perl, I recommend taking a look at Writing Apache Modules with Perl and C book by Lincoln Stein and Doug MacEachern. Especially chapter 6, if this is an option.
HTH | [reply] |
|
|
If you plan implementing session id's
make sure that they are dynamic, and expire after say an hour.
Each time the person logs in their session id is good for about an hour, or less.
If the session id is static, it's just as good as a password.
| [reply] |
RE: Encrypting or Hiding Certain Info in a URL
by geektron (Curate) on Aug 02, 2000 at 23:08 UTC
|
i don't know how you're building the URL, but you should be using POST and not GET to send the information.
that will 'hide' the variables in the URL. | [reply] |
|
|
To be technically correct, Post does not hide the information in the URL, it sends the form information in the HTTP headers apart from the URL.
It is still possible to intercept those headers and grab the username and password, so use of session variables and cookies adds a level of security, and SSL is better.
Just don't want anyone to get confused about the differences between GET and POST. Cheers!
| [reply] |
