Bob Fleischer wrote:
Lee wrote:
On 7/28/17, Bob Fleischer <bobnos...@nospamduxsys.com> wrote:
I have Seamonkey V 2.48 running on 64-bit Windows 10 (v 1703). I just
upgraded from V 2.46.

A certain internal corporate web page I use no longer works, but only
when accessed from Seamonkey 2.48 on this system.  On other browsers,
and from an absolutely clean v2.48 installation on a "virgin" Windows 10
(v 1703), everything works as before.

Which means it's not a problem with v2.48 in general, but a problem
with your particular install on that machine.
Have you tried running Seamonkey in safe mode?  with a new profile?
with no addons?

Regards,
Lee



The error page I get seems to come from the server and seems to blame
the server:


You are not authorized to view this page
You do not have permission to view this directory or page using the
credentials you supplied.

Please try the following:

    Click the Refresh button to try again with different credentials.
    If you believe you should be able to view this directory or page,
please contact the Web site administrator by using the e-mail
address or
phone number listed on the partners.duxburysystems.com home page.

HTTP 401.2 - Unauthorized: Logon failed due to server configuration
Internet Information Services

Technical Information (for support personnel)

    Background:
    This is usually caused by a server-side script not sending the
proper
WWW-Authenticate header field. Using Active Server Pages scripting
this is
done by using the AddHeader method of the Response object to request
that
the client use a certain authentication method to access the resource.

    More information:
    Microsoft Support


Note that I am not prompted for a login.

_______________________________________________
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Well, of course it's a problem with my particular install (or profile)
on that machine, but it was a profile that worked correctly in 2.46 (I
use that server every day).  It could mean that a valid but non-default
setting in 2.46 either migrated incorrectly to 2.48 or is implemented
incorrectly (or at least differently) in 2.48.

How do I go about diagnosing that?

(In case it makes a difference, this web server is a very old
version--Windows 2000.  This web site require authentication but is
non-secure--straight http.)

Bob
Well, in case anyone else sees this issue. The problem seems to be fixed, although I don't know why:

I restarted in "add-ons disabled" mode, connected to the problem server, authenticated, and the page displayed properly.

I exited SeaMonkey, started SeaMonkey normally, and I was able to access that server normally.

All I can figure is that the stored cookie or authentication for the server was damaged in some way, but this persisted even after I removed all records of that server in the data manager.

Bob
_______________________________________________
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Reply via email to