Re: Single login/sign-on for different web apps?
Hello, PL>Of course, the best authentication system for banking I've seen is PL>from UBS. They send you a scratchlist of around 100 numbers. Every PL>time you login you use one of the numbers and cross it off. Very PL>slick. GB>Does that really work in practice? That sounds really annoying. Is this GB>for business banking or for retail? How do they get the next 100 numbers GB>to the user? Do they mail it out when they've used 90? The ACE SecurID system (I think they're owned by RSA now) refines this process well. You have a hardy little credit-card sized (or key fob sized, and I'm sure they have other form factors) object. It has a little LCD screen and every 30 seconds the 4- to 6-digit number on it changes. When you log into the server, you give it your ID, a password, AND the number currently on your SecurID card or key fob. The key fob is nice. It's hardy and lasts a long time. I have one from Motorola from my stint there many years ago. You could probably toss it on the sidewalk from my third-story balcony and it'd be okay, plus it's small and easy to read. This is inferior to a true zero-knowledge challenge-response system which would require a little calculator, but it's far more secure than a password and far easier to use than paper and pencil. Here's the RSA SecurID URL: http://www.rsasecurity.com/products/securid/ Here's a picture of some of the hardware tokens: http://www.rsasecurity.com/products/securid/hardware_token.html I guess they DO have a challenge-response calculator. Neat. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: Summary: CGI.pm problems in BEGIN blocks
> I can't believe no-one else has run in to this. Something > to do with the default instantiation of CGI is my guess. It's actually highly unusual to do anything with CGI other than compile it inside a BEGIN block. You may very well be the first person who ever tried. Typical usage is to do initialization at the start of each request, since CGI is all about the current request context. - Perrin
Re: Single login/sign-on for different web apps?
I hadn't really taken a look at personal certificates until this thread came up. It looks like thawte is offering personal certificates at no charge. http://www.thawte.com/getinfo/products/personal/contents.html This would make it a more likely method since lots of site traffic wouldn't want to pay and people tyring out the service wouldn't be forced to pay just to login. When you say plug-in token are you talking about a browser plug-in? Aaron Johnson More Resources for PKI, CA, etc. http://ospkibook.sourceforge.net/docs/OSPKI-2.4.6/OSPKI/impl-mozilla.htm http://www.openca.org/ http://www.pki-page.org/ Gunther Birznieks wrote: > > > > >Of course, the best authentication system for banking I've seen is > >from UBS. They send you a scratchlist of around 100 numbers. Every > >time you login you use one of the numbers and cross it off. Very > >slick. > > Does that really work in practice? That sounds really annoying. Is this for > business banking or for retail? How do they get the next 100 numbers to the > user? Do they mail it out when they've used 90? > > It sounds like it would be less annoying to use certificates and some > plug-in token there is going to be that much extra work to deal with a > password sheet.
Re: Single login/sign-on for different web apps?
> >Of course, the best authentication system for banking I've seen is >from UBS. They send you a scratchlist of around 100 numbers. Every >time you login you use one of the numbers and cross it off. Very >slick. Does that really work in practice? That sounds really annoying. Is this for business banking or for retail? How do they get the next 100 numbers to the user? Do they mail it out when they've used 90? It sounds like it would be less annoying to use certificates and some plug-in token there is going to be that much extra work to deal with a password sheet.
Summary: CGI.pm problems in BEGIN blocks
Hi All,
Basically comes down to you cannot call the CGI.pm module in a
functional style within a block of code that is loaded at startup by a
mod-perl enabled web server.
Using CGI.pm in an OOP way eliminates the problem.
###
# this code causes problems with the usage
# of CGI.pm with mod-perl
package NOGOOD;
require Exporter;
use strict;
use CGI qw/:standard/;
our (@ISA, @EXPORT);
our ($USERID, $PASSWORD, $select_list);
@ISA= qw(Exporter);
@EXPORT = qw($USERID $PASSWORD $select_list);
BEGIN{
$select_list = scrolling_list(-name=>'TEST',
-values=>[1,2,3,4],
-default=>'1',
-size=> 1);
}
1;
# END
###
# this code WORKS
package GOOD;
require Exporter;
use strict;
use CGI;
our (@ISA, @EXPORT);
our ($USERID, $PASSWORD, $select_list);
@ISA= qw(Exporter);
@EXPORT = qw($USERID $PASSWORD $select_list);
BEGIN{
my $cgihandler = new CGI;
$select_list = $cgihandler->scrolling_list(-name=>'TEST',
-values=>[1,2,3,4],
-default=>'1',
-size=> 1);
}
1;
# END
I can't believe no-one else has run in to this. Something
to do with the default instantiation of CGI is my guess.
Thanks to all
Dave
--
Dave Morgan
[EMAIL PROTECTED]
403 399 2442
Re: Single login/sign-on for different web apps?
I wonder if one could change the HTTP Server's behavior to process a distributed version of "AuthUserFile" and "AuthGroupFile". That instead of AuthUserFile "/some/secure/directory/.htpasswd One would say AuthUserFile "http://xyz.com/some/directory/htpasswd" Then write a GUI (web) inteface to this password and group file and you have distributed authentication system. Ed Grimm wrote: On Wed, 16 Jan 2002, Medi Montaseri wrote: > I think Netegrity single sing-on system modifies the HTTP server > (possible with mod_perl) to overload or override its native > authoentication and instead contact a Host, Database or LDAP to get > the yes or no along with expiration data it then sends its finding > to the CGI by sending additonal HTTP Header info. A CGI program can > then go from there... Something like this. Basically, it has modules, plugins, or access instructions, as appropriate, for various web servers, to configure them to use it. I know it gives an LDAP interface, and I'm assuming it gives an LDAPS interface; I'm not sure what others it may present. > I might not have this 100%, but perhaps we can learn from those > commercial products. > > Someone suggested using LDAP and RDBMS, my question is why both, why > not just RDBMS. Why not just LDAP? As someone working on rolling out a single sign-on solution with LDAPS, I really want to know... (We're planning on getting Netegrity for its distributed administration stuff; at that time, we'll start using its web server configuration stuff for any new web servers. Until that time, we're rolling out LDAPS, and we're not currently planning on converting systems we roll out in the interm to Netegrity.) Incidentally, we're being a bunch of lazy bums, compared to the rest of y'all. We're considering single sign-on to mean they only need to keep track of one userid and password (unless they need to access classified or otherwise restricted stuff.) If they go to different sites and have to log on again, we don't currently care. (Basically, we have too many sites created by too many groups. We'll share the same login between servers run by the same group, but beyond that, security concerns outweigh user convinience.) Ed > Aaron Johnson wrote: > >> We are working on/with a similar system right now. >> >> We have an application that is written in Perl, but the people >> visiting will most likely be signing on at a different point then our >> applications sign in page. Our system was built to use its own >> internal database for authentication and their app/login uses a >> different method. The design requirements were that each side would >> have to do as little possible to modify there application to work in >> our single sign on solution. >> >> We have the luxury of not being overly concerned with the security >> aspect so please keep that in mind. >> >> We setup a nightly sync program that verifies the data in the current >> database vs. their login user information database. >> >> Here is a less then detailed summary of how the system operates. >> >> 1) The user logs into the application through their application and >> they are sent a cookie that contains the user name. >> >> 2) All links to our application are sent to a single page on their >> end with the full url of the page they want as part of the query >> string. >> >> 3) They verify that the user is valid using whatever method they >> want. >> >> 4) The user is then redirected to a special page in our application >> that expects the query string to contain two items, the user name and >> the final URL to go to. >> >> 5) Our application verifies the HTTP_REFFERER and the query string >> contains valid values. >> >> 6) Our application checks the database for a user matching the name >> sent in. Then if the user already has a session if they do then they >> are redirected to the correct page, otherwise it does a lookup in our >> system to create a session for the user based on the incoming user >> name and then redirects to the final URL. >> >> Now a user can go between the two applications without concern since >> they have a cookie for each domain. >> >> If the user comes to our site the reverse of the above occurs. >> >> This allowed us to plug into existing applications without a lot of >> rework. It is also fairly language/platform independent. >> >> As stated above I know there are some large security issues with this >> approach. >> >> Aaron Johnson >> >> Vsevolod Ilyushchenko wrote: >> >>> Hi, >>> >>> Have you ever ran into the problem of putting up many separate web >>> apps on several machines in your company/university/whatever that >>> are written from scratch or downloaded frow the Web and each of >>> which has its own user database? What would you think is a good way >>> to make the system seem more cohesive for the users? >>> >>> It occurs to me that 1) for the single login they all should use the >>> same user database (obviously :), and 2) for the single sign-on >>> there must be a
Re: Single login/sign-on for different web apps?
I think Netegrity single sing-on system modifies the HTTP server (possible with mod_perl) to overload or override its native authoentication and instead contact a Host, Database or LDAP to get the yes or no along with expiration data it then sends its finding to the CGI by sending additonal HTTP Header info. A CGI program can then go from there... I might not have this 100%, but perhaps we can learn from those commercial products. Someone suggested using LDAP and RDBMS, my question is why both, why not just RDBMS. Aaron Johnson wrote: We are working on/with a similar system right now. We have an application that is written in Perl, but the people visiting will most likely be signing on at a different point then our applications sign in page. Our system was built to use its own internal database for authentication and their app/login uses a different method. The design requirements were that each side would have to do as little possible to modify there application to work in our single sign on solution. We have the luxury of not being overly concerned with the security aspect so please keep that in mind. We setup a nightly sync program that verifies the data in the current database vs. their login user information database. Here is a less then detailed summary of how the system operates. 1) The user logs into the application through their application and they are sent a cookie that contains the user name. 2) All links to our application are sent to a single page on their end with the full url of the page they want as part of the query string. 3) They verify that the user is valid using whatever method they want. 4) The user is then redirected to a special page in our application that expects the query string to contain two items, the user name and the final URL to go to. 5) Our application verifies the HTTP_REFFERER and the query string contains valid values. 6) Our application checks the database for a user matching the name sent in. Then if the user already has a session if they do then they are redirected to the correct page, otherwise it does a lookup in our system to create a session for the user based on the incoming user name and then redirects to the final URL. Now a user can go between the two applications without concern since they have a cookie for each domain. If the user comes to our site the reverse of the above occurs. This allowed us to plug into existing applications without a lot of rework. It is also fairly language/platform independent. As stated above I know there are some large security issues with this approach. Aaron Johnson Vsevolod Ilyushchenko wrote: > > Hi, > > Have you ever ran into the problem of putting up many separate web apps on > several machines in your company/university/whatever that are written from > scratch or downloaded frow the Web and each of which has its own user > database? What would you think is a good way to make the system seem more > cohesive for the users? > > It occurs to me that 1) for the single login they all should use the same > user database (obviously :), and 2) for the single sign-on there must be a > way of storing the session information. That is, once I login in the > morning to the first app, I get a cookie, a ticket or something similar, > and then, as I go from app to app, I will not have to re-enter my > credentials because they are supplied by a cookie. Apache::Session sounds > like the right tool for the job. (Did I hear "Kerberos"? :) > > Has anyone had experince with this kind of app integration? The downside I > see is that once I settle on a particular scheme to do it, I will have to > build this scheme into every app that was not written internally. But > that's the life in the before-standards age, I guess... > > Thanks, > Simon > -- > Simon (Vsevolod ILyushchenko) [EMAIL PROTECTED] > http://www.simonf.com [EMAIL PROTECTED] > > "A man who feels himself a citizen of the world whose > loyalty is to the human race and to life, rather than > to any exclusive part of it; a man who loves his country > because he loves mankind, and whose judgement is not > warped by tribal loyalties." Erich Fromm -- - Medi Montaseri [EMAIL PROTECTED] Unix Distributed Systems Engineer HTTP://www.CyberShell.com CyberShell Engineering -
Re: Single login/sign-on for different web apps?
Daniel Little wrote: > > From: Mark Maunder [mailto:[EMAIL PROTECTED]] > > > > > Here's one idea that worked for me in one application: > > > > > > 1) assume that all hosts share the same domain suffix: > > > > > > www.foo.com > > > www.eng.foo.com > > > www.hr.foo.com > > > > > > 2) Define a common authentication cookie that is sent to *.foo.com. > > > This cookie could might contain the following information: > > > > > >username, timestamp > > > > The only way I could come up with, was to have the browser > > redirected to every domain name with an encrypted uri variable > > to prove it is signed on which causes each host included in > > the single sign on to assign an auth cookie to the browser. > > > > So the browser is logged into foo.com, bar.com baz.com and > > boo.com by logging into foo.com which assigns a cookie and > > redirects to bar.com which assigns a cookie and redirects > > it to baz.com which assigns a cookie and redirects it to > > boo.com which assigns a cookie and redirects it back to > > foo.com. It has now collected all cookies required for > > signon to all domain names and is logged into all of them. > > An alternative to this scheme - and depending on how much control you have > over the applications / servers at each end - is to do this in a delayed > fashion. The only time you really need to get authenticated at each server > is when the browser is sent off to the new site. Instead of redirecting the > browser to the new site directly, it sends it to a script on the server that > they are currently connected to (and therefore already authenticated with) > which requests a 'transition' token of some kind from the authentication > server. The transition token then is used to transfer them to the requested > server, which based on the token, does a lookup on the authentication server > to find out if its a valid transition token, and if so, generates a new > cookie for them (if necessary) and logs them into the site. > This assumes they dont just type in the url of the other site they want to visit manually. It limits the user to visiting sites via links on sites they are currently logged on to.
Re: weird problem. Lost of the POST data
> Well all my modules are written in Perl. When you say some C code you mean > the C code in DBI, or CGI or Template, don't you? Yes. That's why I suggest trying Template with the Perl stash instead of the XS one. - Perrin
RE: weird problem. Lost of the POST data
> -Mensaje original- > De: Perrin Harkins [mailto:[EMAIL PROTECTED]] > Enviado el: jueves, 17 de enero de 2002 1:01 > Para: Oscar Serrano; [EMAIL PROTECTED] > Asunto: Re: weird problem. Lost of the POST data > > > > Ummm yes... you know, I'm using the Template Toolkit. > > Try using the Perl stash instead of the XS stash, and see if your problem > goes away. > > > It seems as if the > > httpd child executes the processing of the template so fast that CGI.pm > has > > no time to get the POST data. > > I don't think so. It seems to me like your processes are getting > corrupted > by some C code or an improperly shared file handle or socket. I > doubt this > has anything to do with CGI.pm, since so many people use it and > don't report > having the same problem. Well all my modules are written in Perl. When you say some C code you mean the C code in DBI, or CGI or Template, don't you? I know many people uses CGI.pm but not so many with Template Toolkit and mod_perl... > > If you want to experiment, you could replace CGI.pm and see if it improves > thing for you. There are plenty of other modules you can use to > parse POST > data. Yes, I'm doing that now in some CGIs. Thank you, and you all that are helping me with this problem. Oscar Serrano. > - Perrin > >
RE: weird problem. Lost of the POST data
> -Mensaje original- > De: Robert Landrum [mailto:[EMAIL PROTECTED]] > Enviado el: jueves, 17 de enero de 2002 0:26 > Para: Oscar Serrano; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Asunto: Re: weird problem. Lost of the POST data > > > At 3:11 PM +0100 1/16/02, Oscar Serrano wrote: > >Here I put the beggining of the file: > > > >#!/usr/bin/perl -w > >use CGI; > >use strict; > >use varcomunes; #library of my own > >use lib $LIBRERIAS_AT; > >use EnlacesAT; #library of my own > >use Idioma; #library of my own > >use DBI; > >use OrdenesComunes; #library of my own > >use Template; #template toolkit 2.03 > >my ($rentafijapup, $rentafijapumm, $accionesp, $accionesmm); > >#many other my (whatever) definitions... > >my($query,$in); > > > >print "Content-type: text/html\nPragma: no-cache\n\n"; > > > >$query=new CGI; > >$in=$query->Vars(); > > > > > Check to make sure that you do not have some strange version of CGI > in $LIBRERIAS_AT. I've been bitten by this in the past when a > developer pointed some code to his home directory and had bad/debug > copied of modules in there. Thank you for your advice. But that's not my case. in $LIBRERIAS_AT I only have Idioma.pm OrdenesComunes.pm and other modules of my own. Thanks. > Rob > > -- > When I used a Mac, they laughed because I had no command prompt. When > I used Linux, they laughed because I had no GUI. >
Re: Single login/sign-on for different web apps?
On Wed, Jan 16, 2002 at 06:56:37PM -0500, Vsevolod Ilyushchenko wrote: > > > > 3) Perl-based applications can just use the module and the common key > > to decrypt the contents of the cookie to find the authenticated > > username. If the cookie is not present redirect to the central > > authentication page, passing in the URL to return to after > > authentication. > > Hmmm... Can I do it securely without using Kerberos? I think so. Looks like > if I use https instead of http, people won't be able to steal my (encoded) > session information as it is transmitted. And I can also add the IP address > to the cookie information. > > But the cookies file might be readable by other people! If they can steal > that file and change the IP address of another machine to yours, they can > pretend they are you! > I wonder if there is a way out of this... Yes, you use the timestamp. Just reauthenticate the user when they try to do 'sensitive' activities. For example you might allow someone to view their bank balance if they typed their password within the last 2 hours. Transferring money might require a valid password within the last 10 minutes.. Of course, the best authentication system for banking I've seen is from UBS. They send you a scratchlist of around 100 numbers. Every time you login you use one of the numbers and cross it off. Very slick. -- Paul Lindner[EMAIL PROTECTED] | | | | | | | | | | mod_perl Developer's Cookbook http://www.modperlcookbook.org Human Rights Declaration http://www.unhchr.ch/udhr/index.htm
Re: weird problem. Lost of the POST data
> Ummm yes... you know, I'm using the Template Toolkit. Try using the Perl stash instead of the XS stash, and see if your problem goes away. > It seems as if the > httpd child executes the processing of the template so fast that CGI.pm has > no time to get the POST data. I don't think so. It seems to me like your processes are getting corrupted by some C code or an improperly shared file handle or socket. I doubt this has anything to do with CGI.pm, since so many people use it and don't report having the same problem. If you want to experiment, you could replace CGI.pm and see if it improves thing for you. There are plenty of other modules you can use to parse POST data. - Perrin
Re: Single login/sign-on for different web apps?
> > 3) Perl-based applications can just use the module and the common key > to decrypt the contents of the cookie to find the authenticated > username. If the cookie is not present redirect to the central > authentication page, passing in the URL to return to after > authentication. Hmmm... Can I do it securely without using Kerberos? I think so. Looks like if I use https instead of http, people won't be able to steal my (encoded) session information as it is transmitted. And I can also add the IP address to the cookie information. But the cookies file might be readable by other people! If they can steal that file and change the IP address of another machine to yours, they can pretend they are you! I wonder if there is a way out of this... Simon -- Simon (Vsevolod ILyushchenko) [EMAIL PROTECTED] http://www.simonf.com [EMAIL PROTECTED] "A man who feels himself a citizen of the world whose loyalty is to the human race and to life, rather than to any exclusive part of it; a man who loves his country because he loves mankind, and whose judgement is not warped by tribal loyalties." Erich Fromm
RE: weird problem. Lost of the POST data
> -Mensaje original- > De: Perrin Harkins [mailto:[EMAIL PROTECTED]] > Enviado el: jueves, 17 de enero de 2002 0:06 > Para: [EMAIL PROTECTED]; Oscar Serrano > Asunto: Re: weird problem. Lost of the POST data > > > > There is something that may give a clue. When I restart apache, it takes > > some minutes to throw the first error. But the error get more and more > > frecuently. But not always I get the error. It seems as if some httpd > child > > get corrupted and then, when one of those corrupted childs processes a > > request, it throws this error. > > I've seen that sort of thing before. A common cause of this is > opening some > resource before the fork that shouldn't be shared across processes, like a > file handle or a socket. Check for that. Also, are you using any cleanup > handlers? Do you have any in-house code that uses XS to call C libraries? Ummm yes... you know, I'm using the Template Toolkit. It seems as if the httpd child executes the processing of the template so fast that CGI.pm has no time to get the POST data. I has no sense, because the script, the first thing it does is the $in=$query->Vars(), and the last thing it does is to process a template. But it seems as if it could process the template before getting the POST data. And that would explain why the POST data is mantained in STDIN and then appears concatenated to the very next request: a .gif file the template calls. But I repeat, it has no sense the script processing the template before reading the POST data :-? I'm not using any cleanup handlers. Somebody suggested me to use one to destroy CGI.pm data. But, the true is that the problem is CGI.pm I'll kick CGI.pm away because I only use it to get the variables from a GET or POST data. Thank you very much. > - Perrin > >
RE: weird problem. Lost of the POST data
> -Mensaje original- > De: Ged Haywood [mailto:[EMAIL PROTECTED]] > Enviado el: miercoles, 16 de enero de 2002 23:30 > Para: Oscar Serrano > CC: [EMAIL PROTECTED] > Asunto: Re: weird problem. Lost of the POST data Thank you Ged for your detailled information. I'm now debugging my scripts. I'm still not sure if the problem is in the way I code, in CGI.pm or in the Template Toolkit. Thank you very much. > > Hi Oscar, > > On Wed, 16 Jan 2002, Oscar Serrano wrote: > > > So, one mod_perl CGi can cache several modules and several > mod_perl cgis? > > It's not really a "mod_perl CGI", it's an Apache child process with > its own built-in (persistent) Perl interpreter. In that sense it's an > ordinary copy of the Perl interpreter which can load whatever Perl > modules you have the memory for. The child sits around waiting for > something to do. You give it something to do by handing a request to > Apache (usually from a browser) which may or may not be configured to > cause the Perl interpreter to do something with it. If it does > something with the request it may change things inside the memory > pages of that child's Perl interpreter which aren't changed in the > interpreters of any of the other apache children. > > > Apache::Registry which I'm interested in. > > Apache::Registry provides the Apache+mod_perl process with an environment > similar to what you see when you use mod_cgi in an ordinary (non-mod_perl) > process. But it's only similar, it's not identical. There are all sorts > of things (mentioned in the Guide) that you have to look out for, mostly > because it's only similar and because the Perl interpreter is persistent. > There are alternatives to Apache::Registry which might be better for you, > but none provides an exact replica of the CGI environment. > > > So the maximum size the httpd can grow is the size of all modules and > > mod_perl cgis cached in memory. Am I right? > > Not quite, there are reasons for example why the child might grow > without bound. It's covered in the Guide in great detail, including > methods of calculating the process sizes and ways of dealing with > any processes which misbehave. > > > print "Content-type: text/html\nPragma: no-cache\n\n"; > > $query=new CGI; > > $in=$query->Vars(); > > > > Now I have everything in $in. > > To be sure of it, why not print everything in $in to the error_log or > something like that? (There's a whole chapter on debugging techniques > in the Guide. :) > > > 501 Apache Error? > > In a properly written program, the ideal would be that no request > could cause a server error. I suspect that there's something wrong > with the way your code handles the request or (less likely) there's > something wrong with the build of the server. > > 73, > Ged. > >
Re: weird problem. Lost of the POST data
At 3:11 PM +0100 1/16/02, Oscar Serrano wrote: >Here I put the beggining of the file: > >#!/usr/bin/perl -w >use CGI; >use strict; >use varcomunes; #library of my own >use lib $LIBRERIAS_AT; >use EnlacesAT; #library of my own >use Idioma; #library of my own >use DBI; >use OrdenesComunes; #library of my own >use Template; #template toolkit 2.03 >my ($rentafijapup, $rentafijapumm, $accionesp, $accionesmm); >#many other my (whatever) definitions... >my($query,$in); > >print "Content-type: text/html\nPragma: no-cache\n\n"; > >$query=new CGI; >$in=$query->Vars(); > Check to make sure that you do not have some strange version of CGI in $LIBRERIAS_AT. I've been bitten by this in the past when a developer pointed some code to his home directory and had bad/debug copied of modules in there. Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: Single login/sign-on for different web apps?
Vsevolod Ilyushchenko wrote: > Yes, but I still should be able to propely handle people who go to any of > the protected sites first thing in the morning. I don't think I can get > away with only exit-point authentication that you propose. If the > entrance-point authentication works well, there should be no need for this > additional level. (Please correct me if I am wrong. :) Do cookies get set if returned via an image? If so, once the user has logged in, you could return a page with invisible images on it, where each image is from each site that the user needs to be authenticated to. Each image is unimportant. The important bit is that an authentication cookie is set for each domain the image is returned from. This leaves one tricky point as far as I can see: you need to securely identify which image request comes from each user. The obvious/easy way would be to put some sort of unique identifier in the path or query string, but this may not be secure enough for your purposes. Oh yeah, it'd break if they didn't have images on. :-( Steve -- Steve Piner Web Applications Developer Marketview Limited http://www.marketview.co.nz
