Closed Bug 128379 Opened 23 years ago Closed 22 years ago

Reloading login page let user into Siebel app without logging i

Categories

(Core :: Layout: Form Controls, defect, P1)

Product:
Core
Component:
Layout: Form Controls
Platform:
Sun
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.0

People

(Reporter: joe.chou, Assigned: radha)

References

Details

(Keywords: topembed+, Whiteboard: [eapp],AOLTW+, sun_621)

Attachments

(2 files)

Simplified testcase
3.86 KB, text/plain
Details
Updated patch from 108041
5.19 KB, patch
Details | Diff | Splinter Review 
This problem could let users get into Siebel's application without logging in.
Here was how it happened:

1) User logs into Siebel by submitting the login form.
2) After his/her session times out, their redirected back to the login
screen.
3) When the user clicks 'Reload', the previous form values are submitted
instead of reloading the current URL.
So we have a URL of:
http://<server>/callcenter/start.swe?SWECmd=Login&SWECM=S
<http://<server>/callcenter/start.swe?SWECmd=Login&SWECM=S> 

And a form containing the hidden field SWECmd with a value of 'null'

In a java script function called when the form is submitted, we assign
form.SWECmd.value = 'ExecuteLogin'

Now under IE, when the page is reloaded/refreshed we get SWECmd=Login.
Exactly what's in the URL.

Under Netscape, when the page is reloaded/refreshed we get
SWECmd=ExecuteLogin.  Not what's expected!
This is currently Siebel's #2 (#1 was 105292) top bug that blocks them from
releasing their application on Netscape 6.2.1..
Please help!!!
Severity: normal → blocker
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1
Would this be affected by the "reloading a page does not reset form values" bug?
Blocks: 125136
Whiteboard: [eapp]
Need reduced test case
Keywords: qawanted
Keywords: nsbeta1, topembed → nsbeta1+, topembed+
Target Milestone: --- → mozilla1.0
Second the need for a testcase (any testcase is better than none).  Is the URL
correct after step 2?
Over to John the submission guy.
Assignee: rods → jkeiser
Adding AOLTW
Whiteboard: [eapp] → [eapp],AOLTW
Attached file Simplified testcase — 
This servlet is simplified testcase for the reloading problem.
Steps to reproduce:

1. Go to login page /path/to/servlet/Stest?Cmd=Login
2. Type something in text fields and click on "Login" link.
3. Click on "error page" link
4. Close alert window. Now you should see the login page again. 

If you try to reload page, you will see the frameset again instead the login
page.

Note that this problem does not appears in the current trunk, but reproduce on
ns621beta.
(for me it is reproduced on Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.4)
Gecko/20020225)

Also note that if we use "top.location = someURL" instead
"top.location.replace(someURL)" then we also avoid this problem.
this bug is reproducible in mozilla 0.9.5 but is fixed in mozilla 0.9.6

cc'ing radha...

radha: do you recall the "clear form values" patches that went in between
mozilla 0.9.5 and 0.9.6?
I guess what it was fixed by fix for 109319, now I try to check it.
I think that it is bug 103850 that fixed this problem.
andrew: can you try the patch from bug 103850?
I tried fix for 103850 already - it do not help (at least for 0.9.4) :(((
Now I trying to find the workable fix.
Darin: Do you have any other suggesions?
radha: any other suggestions?  what else might have changed?
Let me dig in more  and I will update later today. 
I looked through all the checkins between 0.9.5 and 0.9.6. I still believe that
it is the patch to bug 103850 that fixed this problem. Andrew: Did you apply the
patch for bug 103850 to the 0.9.4 tree? Do you still see the problem after
applying the patch?

If I understand this right, the bug is not reproducible in the trunk but is
reproducible in the 0.9.4 branch.  I clicked on the testcase. It shows me the
java source, but no html page. Please update. 
Attached testcase is Java servlet
 source. You need for some supported servlet engine webserver or JSDK in order
to run this testcase. As I  understand the problem occurs when we use the
"top.location.replace(some_url)" statment inside the onload handler of the body
tag.

I  already tried to apply patch for the 103850 to the 0.9.4 tree and as I can
see it does not help. I going to try it again in order to be shure. 
andrew: Your latest comment on reproducibility puzzles me. I think there is 
also  another problem here, apart from 103850. A problem related to
location.replace. Please see bug 108041. Based on what you are saying, we
probably need 108041 also in the branch.  Is this problem clearly fixed in 0.9.6
and above? That will help me track this down faster.  

Anyways, Darin is trying to set up a local server with servelet support and I'm
pulling the 0.9.4 branch right now. I think  we can get to this fast. 
i setup the servlet app internally here:

http://unagi.mcom.com:4444/servlet/Stest

steps to repro:

0) load URL
1) enter any username:password
2) press login
3) press "goto error page"
4) accept alert dialog
5) notice that you are back on the login page
6) now observing network traffic, press reload.  notice that the first HTTP
request is a POST request w/ the old username:password (you can't see the
username:password, but the fact that this request is a POST request is enough to
demonstrate the bug).

Radha, you are right, the fix for 108041 solve problem!
Now I going to attach updated patch
This is updated patch from bug 108041. I change it a bit in order to make it
applicable to the 0.9.4
excellent news... thank you radha!!
I suspect that you would need both 103850 and 108041 in the branch.  who is
going to checkin the patch to the branch? This bug should be fixed on trunk and
in 0.9.9 branch. So, I don't see the need for a nsbeta1+. 
To radha.
Assignee: jkeiser → radha
Please see my latest comments to bug 108041 and 103850. I would like to check in
those individual patches to the 0.9.4 branch rather than  try to get reviews for
this one. Once those bugs are  checked in, I will mark this fixed. 
Thsi got fixed in the 6.2.2 branch last friday.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Plussing for AOLTW
Whiteboard: [eapp],AOLTW → [eapp],AOLTW+
This fix has been checked into the Sun 6.2.1 branch.
Whiteboard: [eapp],AOLTW+ → [eapp],AOLTW+, sun_621
I verified this fix in Siebel today with the new release build. 
We can close this bug now.
QA Contact: madhur → tpreston
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: