idiosyncrasies w/ scripted login security

[Humbert Suarez]

Certainly idiosyncratic behavior. Could it have anything to do
with the browser cache ? Just a guess. Try clearing the cache
and setting to "check everytime" before executing the CGI script
a few times, then try setting to "never check" before executing
the CGI script several times, and see if the behavior can be
switched on the same browser. I hope that this will be helpful.

Humbert Suarez
Medical World Search
humbert at mwsearch.com

>This question is primarily for those of you who write perl cgi scripts
>that handle user authentication to remote sites, though others may be
>able to offer useful perspectives on the subject. 
>
>One of the simplest methodologies for writing such scripts involves,
>as its final step, sending the user a redirect in the form of an HTTP
>"Location:" header -- for example,
>
>  print "Location: http://foo.org/login.cgi?username=xx&password=yy\n\n";
>
>We have avoided this strategy in the past, partly because establishing
>a full HTTP connection via the LWP library instead allows us much
>fuller information for logging purposes, but also because the
>"Location:" trick has not seemed fully secure. To wit, whenever I have
>tested scripts that use the above syntax, the URL that displays in the
>client browser's location window is the same as the one I sent, thus
>rendering the username and password visible to the end user. 
>
>Often, the vendors I deal with are unable to replicate this behavior,
>insisting that the URLs their browsers display are utterly innocent of
>password data. Occasionally one of them is able to elicit the same
>result I'm seeing; I got the following helpful diagnostic information
>from one such person:
>
>> I've had a look at it using various different machines and servers.
>> The results don't seem to be consistent, sometimes the URL shown is
>> the final one with the username and password and sometimes it's the
>> first one as I thought it would be.
>
>When I asked about any pattern among the results, he said,
>
>> It seems to be dependent on the version of Netscape you use. A
>> couple of the 4.0x versions don't show it, whether this is a bug
>> which they've fixed yet I don't know. I've now upgraded to 4.05 and
>> I get the same results you got.
>
>Now, this theory of browser-dependence made plenty of sense at the
>time, and still does--and I certainly don't have a reasonable
>alternate explanation. However, I now have need of other theories.
>
>Today I managed to get the same browser on the same machine to display
>both behaviors in a single afternoon. I cannot identify any
>differences either in browser settings or in perl syntax that could
>possibly account for the change. This afternoon, for the first time,
>my browser started behaving like everyone else's (displaying a secure
>URL rather than one containing a password), and I'm completely
>stumped. And now I can't get it to return to its usual behavior.
>
>Has anyone else seen both of these display behaviors? If so, have you
>gotten any farther in identifying the underlying trends? Can you
>suggest any new avenues of investigation?
>
>Many thanks for any light you can shed. 
>
>~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
> Lydia Ievins, Systems Librarian          Office for Information Systems
> phone 617/495-3724; fax 617/495-0491     Harvard University Library
>~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
>
>
>