Depending on the security needs of you organization, I would recommend Server Side authentication (with SSL so no one can snoop your plaintext). Perl can see the remote user's name through $ENV{REMOTE_USER}. You can then implement any kind of application level permissions.
BTW stay away from ASP Perlscript... it is M$'s negelected bastard child of scripting languages. From what I hear buggy and slow.
grep
grep> cd pub
grep> more beer |
| [reply] |
I am not sure if the following works with IIS 3, for I've only tested it with IIS 4&5:
For the path you want to save, remove anonymous logon and only use domain-autentication. (for Netscape, plain-text-password must be enabled, for IE not). Then you can control the access with NTFS-Rights. With a systemvariable (I think, it was $ENV{USER}) you can find out which user is logged on (works similar to .htaccess).
Best regards,
perl -e "print a|r,p|d=>b|p=>chr 3**2 .7=>t and t" | [reply]
[d/l] |
Not sure of the context in which youre working:
- making the script get the ID automatically
- user authentication
In the case of point one, there is no *real* safe way of explicitly identifying a user over the web without the use of authentication. If you are in a static IP env, then you may be able to use that method, however if you have a proxy in the middle, you'll get the proxy IP. The other problem you will face is person A sitting at person B's desk - you dont know who is at the keyboard.
In the case of point 2 (authentication) its really quite simple. There are many examples of code out there that will do it.
Points to consider rolling your own authen method
- Do use CGI.pm - its the best, the doco is good, and heaps of monks can help you.
- Do use -T (in any CGI app you build). It is a well recognised method of making your application secure (when used 'correctly'), again many monks can help you with this.
- What will you store the username/pwd combo in (txt, DBI et al)
- How will you keep track of sessions (read, how will you generate, and where will you store your sess_id)
Another thing i shout on about is the use of CGI::Application and HTML::Template. They provide a good solid framework for the production of scalable applications that are *easy* to change the look and feel of, and also plug new functionality into.
Method for (simple) authen protocol (Typical course of events)
- display authen page
- user submits ID and pwd to cgi app
- cgi checks for invalid chars (such as ; \ | ` )
- cgi gets pwd based on supplied uname
- cgi encrypts pwd and compares to fetched pwd
- user is authenticated and resulting page is displayed
Using a method like this, the actual password is never seen by anyone which makes it a little more secure. the down side is, if someone forgets their pwd, you can never get it back if you use something like md5 or sha1.
You then also have to thing of things like administration (changing user pwds, adding/removing (l)users), password aging, transaction rate etc etc..
If you are thinking of building a web app that will handle authentication, these things really shouldnt be out of scope, even for the 1st rev of your application. You want people to like, (and use) your application, ommiting (what i consider essential) features may not give your users the impression you are after.
Even tho' this is big on theory with no examples (which i suspect you were after), I hope it provides a reasonable guide as to what you should consider when building CGI apps. | [reply] |