Closed Bug 87417 Opened 23 years ago Closed 23 years ago

this secure URL fails logging in.

Categories

(Core :: DOM: Core & HTML, defect, P1)

Product:
Core
Component:
DOM: Core & HTML
Platform:
PowerPC
Mac System 9.x
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla0.9.5

People

(Reporter: tarahim, Assigned: paulkchen)

References

(
URL
)

Details

(Whiteboard: hard to reproduce)

Attachments

(1 file)

stack trace of the crash accessing this secure site
2.18 KB, text/plain
Details 
2001062116 trunnk.
Goto URL.
You get the security warning and you click OK.
The result:crash.
This crash occurrs regardless of TLS setting in Pref|Security|SSL.
WFM using 2001062104 Win2k. Maybe a Mac only bug?
Keywords: crash
Wfm with 2001062204 / Win98SE.
Well, in 2001062209 trunk, crash does not occur. However, the URL which is a
page with login form, does not work. Sending form bring you back to the same
login dialog.
This despite Cookie is enabled. Seems like a regression of some bug I saw in May.
FYI, this login works with 2001060709 build.
Summary: crash accessing this secure URL → crash accessing this secure URL and failure of logging in if no crash.
-> PSM
Component: Security: Crypto → Client Library
Product: Browser → PSM
Target Milestone: --- → 2.0
Version: other → 2.0
The stack trace is from the wallet code. Re-assgning.
Assignee: ddrinan → morse
Component: Client Library → Password Manager
Product: PSM → Browser
QA Contact: junruh → tpreston
Target Milestone: 2.0 → mozilla0.9.2
Version: 2.0 → other
reporter, I'm very confused.  You said that this is a login form.  That's not 
what I get at all.  I get a page with lots of japanese characters (which of 
course I can't read) but having no fields to fill in.  And the source of that 
page does not contain any <input> tags or <submit> tags.  So this can't possibly 
be a login form.  
reassigning to pchen for mac work
Assignee: morse → pchen
nav triage team:

need to investigate, marking p1 and nsbeta1+, also setting target milestone to
mozilla0.9.3
Status: NEW → ASSIGNED
Keywords: nsbeta1+
Priority: -- → P1
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Running 2001062809 0.9.2 commercial mac build, I can't reproduce this crash. I
go to the URL, click OK on the security warning dialog, and the page loads fine.
This is on a US English MacOS 9.1 system. I'll go and try and trunk mozilla build.
Ok, just ran 2001062808 trunk mac mozilla build, and it doesn't crash either
(same system as before). I'm really tempted to mark this worksforme unless
there's something else I'm missing. Adding "hard to reproduce" in status whiteboard.
Whiteboard: hard to reproduce
Hmm, works for me too mac branch build 2001062809
In 2001062914 trunk, it does not crash, but logging in is impossible.
Pressing LOGIN returns to the same page with "you have requested insecure
document" warning as well as "low grade encryption" warning.

Downgrading the severity and removing keywords.
Severity: critical → major
Keywords: crash, nsbeta1+
Summary: crash accessing this secure URL and failure of logging in if no crash. → this secure URL fails logging in.
Keywords: nsbeta1
Does it fail to login on a branch build also?
Keywords: nsbeta1 → nsbeta1+, nsBranch
I am wondering if this problem has anything to do with cookies.
I have expxerienced in another non-secure site where I could not log in and the
server kept responding that the session was expired.
The URL is http://www.epsonphoto.ne.jp/ and you login using ID=mio and PW=mio .
Both the URL for this bug and this URL work with NS4.7.
URL: https://selfpage.dion.ne.jp/cgi-bin/c... → https://selfpage.dion.ne.jp/cgi-bin/c...
See also bug 88060.
Hmm, I just tried my branch mozilla mac build from today, and I don't have any
problems logging onto http://www.epsonphoto.ne.jp/.

Hirata, how about moving your cookies.txt file out of your profile and see if
you still have problems logging in.
Same thing. No difference.
I am wondering if there is any problem with time stamping.
The failure of both URL seem to involve timing.
The first one calcultes time consumed in ISP account.
The second one returns time out error.

Sorry Paul, still unable to reproduce with branch build 2001070903 :-(
Please ignore my comment about www.epsonphoto.ne.jp
That turned out to be my mistake about accepting cookies.
However, the secure URL is still returning to the same login page even after I
have cleared all the cookies sites and set to accept all cookies.
in light of Paul's and Terri's comments on hard to reproduce on branch, removing 
nsBranch
Keywords: nsBranch
I strongly suspect that this is a cookies problem. Login at the URL always
returns to the same page, and in other pages that can be reached by login at 
https://selfpage.dion.ne.jp/cgi-bin/cust/daa_menu.cgi
the server returns an error that states that could be translated to "Page
request was from wrong page".
There are some cookies bug that may be related:
bug 88968, bug 91206, bug 91238 seem to describe something similar.
Component: Password Manager → Form Submission
nav triage team:

Moving out to mozilla0.9.4, needs more investigation
Target Milestone: mozilla0.9.3 → mozilla0.9.4
nav triage team:  moving to 0.9.5.
Severity: major → normal
Target Milestone: mozilla0.9.4 → mozilla0.9.5
This is now WFM in 2001080608 trunk build.
Are other login failure bugs working now, too?
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Seems like a dupe of bug 89995
Depends on: 89995
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: