netscape authentication info persists

Does anyone know why, under the following conditions, netscape stores authentication info:
1. navigator and messenger are both open
2. I authenticate to a directory structure on the web server with .htaccess
3. I close all navigator windows, but leave the messenger window open
4. I start up navigator again and go to the same directory that's protected with .htaccess then....
5. Netscape lets me in without challenging me for my username and password again.

Why?? Can it be fixed?? Using Communicator 4.75 on Win95 workstation, Linux/Apache server.

Appreciate any insight,
Sharry

Because messenger is part of Netscape. It's launched with netscape.exe -mail.

If you press Ctrl+Alt+Del while messenger is running, you would eventually see "netscape".

<BLOCKQUOTE><font size="1" face="Verdana,Arial,Helvetica">quote:</font><HR>Originally posted by freebsd:
Because messenger is part of Netscape. It's launched with netscape.exe -mail.

If you press Ctrl+Alt+Del while messenger is running, you would eventually see "netscape".[/quote]

Thanks for your reply. Yes, I know messenger is part of communicator, but that seems like odd behavior, that if you close your browser windows and restart them that you are still logged in to a directory which is supposed to be secure. Do you know of any way to correct this problem, or any kind of workaround that can be done without having to force the user to log in at every visit to the directory?

Again, appreciate your response,
Sharry

No, it's not weird behavior. Perhaps you don't understand how basic authentication works. Each request to a protected directory file requires a valid username/password. If your page includes 10 images that are in the protected directory as well as the page itself, there would be 11 challenges made.

Now, when you are prompted for a username/password on a protected directory, your browser remembers what you typed in and will pass this with each request made to that directory (so you wouldn't have to type it in on each page and/or image, etc).

This data is kept in a cache until (usually) ALL instances of the browser are closed. NS Messenger IS an instance of Netscape so the cache stays open and is available when you return to that directory.

That's why. There is nothing "to fix."

If you don't like this behavior you'll have to use some sort of server side scripting using a session id that is passed via GET or POST (not a cookie as cookies will behave the same).

<BLOCKQUOTE><font size="1" face="Verdana,Arial,Helvetica">quote:</font><HR>Originally posted by rod k:
No, it's not weird behavior. Perhaps you don't understand how basic authentication works. Each request to a protected directory file requires a valid username/password. If your page includes 10 images that are in the protected directory as well as the page itself, there would be 11 challenges made.

Now, when you are prompted for a username/password on a protected directory, your browser remembers what you typed in and will pass this with each request made to that directory (so you wouldn't have to type it in on each page and/or image, etc).

This data is kept in a cache until (usually) ALL instances of the browser are closed. NS Messenger IS an instance of Netscape so the cache stays open and is available when you return to that directory.

That's why. There is nothing "to fix."

If you don't like this behavior you'll have to use some sort of server side scripting using a session id that is passed via GET or POST (not a cookie as cookies will behave the same).[/quote]

OK, now I understand a little more. Thanks for explaining it to me! I was afraid that the only fix was going to be server side scripting... Oh well. Unless.... Is there a way to clear this "cache" you mentioned where the login info is stored? I could try and do a JS function in onUnload to clear it out, if there's a way to access it.

I guess I saw this as needing a "fix" because IE doesn't behave this way, and plus it seems strange that the browser cache has anything to do with the mail app being open ("browser" to me means just that - web browser - not email).

Thanks again for your help,
Sharry

Not that I'm aware of, but then again I'm not a JS guru.

Netscrape decided to make it the way they did. Microsloth took a different approach (i.e. IE and Outlook* are not integrated as tightly).