Closed Bug 79851 Opened 24 years ago Closed 23 years ago

Session information lost when Java Plugin applet loaded

Categories

(Core Graveyard :: Java: OJI, defect, P1)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: jheight, Assigned: edburns)

References

Details

(Whiteboard: [oji_working][HAVE_FIX], ptd+)

Attachments

(5 files)

Ok, I have some source code that reproduces the problem. Although it is a java servlet/java applet combination (I hope that this isnt a problem). That source code is at the end of this bug. The problem is that between a http get and a http post the session information is lost when the http get returns html code to startup a java applet. This was not the case in mozilla 0.8.1 and has only appeared in mozilla 0.9. I tested the following code segment on the sources from the 8th May 2001. Here is the output (from my servlet) that I see: Starting tomcat. Check logs/tomcat.log for error messages 2001-05-10 08:18:45 - ContextManager: Adding context Ctx( /agile_inf ) 2001-05-10 08:18:45 - ContextManager: Adding context Ctx( /moz_test ) 2001-05-10 08:18:47 - PoolTcpConnector: Starting HttpConnectionHandler on 8080 2001-05-10 08:18:47 - PoolTcpConnector: Starting Ajp12ConnectionHandler on 8007 doGet Session ID is efrep4nqv1 doGet Session ID is efrep4nqv1 doPost Session ID is 43xgf2nqx1 As you can see between the doGet and doPost the session is invalidated and a new one is created. (They should remain the same). Note: I have confirmed that a html form post does not exhibit the same behaviour, that is the session ID remains the same. Anyhow here is my test code for the servlet (applet follows later). I hope that you wont have a problem getting a servlet container up and running and the class files in the appropriate places: All output goes to system out on both the server and the applet (plugin window) package mozilla_session_bug; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.servlet.http.HttpSession; import javax.servlet.http.HttpUtils; import javax.servlet.ServletException; import java.io.*; public class Untitled1 extends HttpServlet { public Untitled1() { } protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException { HttpSession session = req.getSession(); System.out.println("doGet Session ID is "+session.getId()); session.setAttribute("myattribute", "myString"); resp.setContentType("text/html"); PrintWriter out = new PrintWriter(resp.getOutputStream()); String myUrl = HttpUtils.getRequestURL(req).toString(); out.println("<html><body><form method=\"post\" action=\""+myUrl+"\">"); out.println("<input type=\"submit\" name=\"doPost\" value=\"Do Post\" />"); out.println("</form>"); out.println("<embed"); //out.println("codebase='mozilla_session_bug'"); out.println("code='mozilla_session_bug.UntitledApplet'"); out.println("align='baseline'"); out.println("type='application/x-java-applet;version=1.3'"); out.println("width='100%' url='"+myUrl+"'>"); out.println("<noembed>No support for Java 2 applets </noembed> </embed>"); out.println("</body></html>"); out.flush(); out.close(); } protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException { HttpSession session = req.getSession(); System.out.println("doPost Session ID is "+session.getId()); resp.setContentType("text/html"); PrintWriter out = new PrintWriter(resp.getOutputStream()); Object value = session.getAttribute("myattribute"); if (value == null) { out.println("Oiii! The session lost the correct value"); } else if (value.equals("myString")) { out.println("<html><body><h1>Yes the session contained the correct value</h1></body></html>"); } else { out.println("<html><body><h1>No! the session did not contain the correct value (Wanted myString got "+session.getAttribute("myAttribute") +"</h1></body></html>"); } out.flush(); out.close(); } } APPLET CODE: package mozilla_session_bug; import javax.swing.JApplet; import java.io.*; import java.net.*; /** * Title: * Description: * Copyright: Copyright (c) 2001 * Company: * @author * @version 1.0 */ public class UntitledApplet extends JApplet { public UntitledApplet() { } public void start() { try { System.out.println("Started ..."); String serverURL = getParameter("url"); URL url = new URL(getDocumentBase(), serverURL); URLConnection connection = url.openConnection(); connection.setDoInput(true); connection.setDoOutput(true); connection.setUseCaches(false); connection.setRequestProperty("Content-Type", "text/xml"); PrintWriter out = new PrintWriter(connection.getOutputStream()); out.println("POST!"); out.flush(); out.close(); BufferedReader in = new BufferedReader(new InputStreamReader (connection.getInputStream())); String line = null; do { line = in.readLine(); System.out.println(line); } while (line != null); in.close(); } catch (Exception ex) { ex.printStackTrace(); } } }
Reporter, I've compiled the Servlet and the applet, but you need to supply the HTML. In particular, what should be the value of the URL param?
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
I've discerned that the HTML should be like this: <HTML> <BODY> <APPLET WIDTH="400" HEIGHT="400" CODEBASE="." CODE="mozilla_session_bug.UntitledApplet"> <PARAM name="url" value="http://127.0.0.1:8080/servlet/Untitled1"></PARAM> </APPLET> </HTML> But I only see that doPost is getting called. Here's the java console output: <HTML> <BODY> <APPLET WIDTH="400" HEIGHT="400" CODEBASE="." CODE="mozilla_session_bug.UntitledApplet"> <PARAM name="url" value="http://127.0.0.1:8080/servlet/Untitled1"></PARAM> </APPLET> </HTML> Applet Installation finished. Started ... Opening http://127.0.0.1:8080/servlet/Untitled1 Connecting http://127.0.0.1:8080/servlet/Untitled1 with no proxy Server http://127.0.0.1:8080/servlet/Untitled1 requesting to set-cookie with "jwssessionid=PIIAHOIAAAAABQEBMQBQAAA;Path=/" Oiii! The session lost the correct value null I don't think my test environment is correctly configured, because the code that does the session.setValue() never gets called.
Yes, Sorry. The URL you should enter into the webbrowser depends how you have setup the servlet container. I should have specified this earlier. Here is how i have it: 1) I created a web context named moz_bug in the servlet container. This was a folder located under the webapps directory of tomcat. 2) Underneath the moz_bug directory I created a folder named mozilla_session_bug and placed the compiled applet class in there. 3) Again, Underneath the moz_bug directory I created a WEB- INF/classes/mozilla_session_bug directory and placed the servlet class in there. 3) I ran up tomcat and used the following URL: http://localhost:8080/moz_bug/servlet/mozilla_session_bug.Untitled1 This should bring back a web page on the client with an applet and a button. The button was only to confirm that mozilla worked for html posts. It doesnt work now since as soon as the applet is loaded the session changes hence the bug. Look at the server console for the print out of the session ID in the get and posts. Let me know if this is still confusing... Jason
The session.setValue occurs on the servlet get. So the servlet get needs to be called to firstly setup the session and finally return the html to display the applet. So there is no html file per-se on the client. This is returned from the server.
I'm using JavaWebServer, not TOMCAT. What is TOMCAT? Is that some APACHE thing? Is there a way to test this using JavaWebServer and a static HTML page?
Let me download JavaWebServer and i'll give your detailed instructions.
Depends on: 80848
Whiteboard: [oji_working]
Attached file UntitledApplet.java (deleted) —
Reporter, I'm observing the bug with the Applet I just attached. Can you please review it and tell me if you think it will accurately reproduce the bug you're seeing? Thanks, Ed
YES! That Applet (inconjunction with the servlet earlier) produces the effect that I am seeing. You can see at the server end that the session ID changes. Hmm why didnt I do it that easily to start with ;-) Thanks Jason
I believe this is a bug in the Java Plugin/JDK. I have filed Sun internal bugtraq bug 4458973. I'm re-assigning this bug to Stanley.
Assignee: edburns → stanley.ho
Status: ASSIGNED → NEW
*** Bug 79424 has been marked as a duplicate of this bug. ***
*** Bug 80018 has been marked as a duplicate of this bug. ***
If this is a Sun JVM bug then why did the same JVM work on Mozilla 0.8.1 and now not on Mozilla 0.9. Surely this indicates that something in Mozilla has changed that has caused the fault. Since I cant see Suns internal bug, would it be possible to have a short explaination of why it is a JVM bug and not a Mozilla bug. Thanks Jason
p1
Priority: -- → P1
Try it with latest Mozilla build, and JPI does make the call to nsICookieStorage::getCookie, but the browser is not returning the right info. Since this is a browser side problem, reassign to Ed.
Assignee: stanley.ho → edburns
Thanks Stanley. I'll look into the getCookie path.
Status: NEW → ASSIGNED
Stanley, I think the problem really is in the Java Plugin side. Here's why. The applet makes the first get request on the servlet: debug: edburns: HttpClient.writeRequests: sun.net.www.MessageHeader@3bd23f{GET /servlet/Untitled1 HTTP/1.1: null} {User-Agent: Java1.3.1-rc1}{Host: 127.0.0.1:8080}{Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2}{Connection: keep-alive}{null: null}{null: null} {null: null} Here is the reply: debug: edburns: HttpClient.parseHTTPHeader: sun.net.www.MessageHeader@2799c{null: HTTP/1.1 200 OK}{Server: JavaWebServer/2.0}{Set-Cookie: jwssessionid=2XF1RLAAAAAABQEBMQBQAAA;Path=/} {Cache-Control: no-cache="set-cookie,set-cookie2"}{Expires: Thu, 01 Dec 1994 16:00:00 GMT}{Content-Type: text/html}{Connection: close}{Date: Mon, 04 Jun 2001 23:36:41 GMT} Server http://127.0.0.1:8080/servlet/Untitled1 requesting to set-cookie with "jwssessionid=2XF1RLAAAAAABQEBMQBQAAA;Path=/" We see that Java notices that the server is setting a cookie. However, on the following POST request, we don't see this cookie being sent: debug: edburns: HttpClient.writeRequests: sun.net.www.MessageHeader@18cb3d{POST /servlet/Untitled1 HTTP/1.1: null} {Content-Type: text/xml}{User-Agent: Java1.3.1-rc1}{Host: 127.0.0.1:8080} {Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2}{Connection: keep- alive}{Content-length: 7}{null: null} Thus the server replies with another, different, cookie: debug: edburns: HttpClient.parseHTTPHeader: sun.net.www.MessageHeader@2bc3f5{null: HTTP/1.1 200 OK}{Server: JavaWebServer/2.0}{Set-Cookie: jwssessionid=2XG0IAIAAAAADQEBMQBQAAA;Path=/} {Cache-Control: no-cache="set-cookie,set-cookie2"}{Expires: Thu, 01 Dec 1994 16:00:00 GMT}{Content-Type: text/html}{Connection: close}{Date: Mon, 04 Jun 2001 23:37:41 GMT} Server http://127.0.0.1:8080/servlet/Untitled1 requesting to set-cookie with "jwssessionid=2XG0IAIAAAAADQEBMQBQAAA;Path=/" You mention that the java plugin calls the browser's GetCookie, and it returns null. This is correct, because it never saw the set-cookie come back in the because the java plugin issued the HTTP request in the first place. The browser can't have cookies in its cookie store that are sent as the HTTP response from a request originated in the plugin. Re-assigning back to Stanley.
Assignee: edburns → stanley.ho
Status: ASSIGNED → NEW
I stand corrected, the plugin uses the browser's cookie store. Back to me.
Assignee: stanley.ho → edburns
a
Status: NEW → ASSIGNED
Unfortunately, this bug fix requires changes in both the browser and the plugin. That means the customer will have to wait a long time to receive the fix due to the rift between the java plugin schedule and the browser's schedule. I've notified the Sun engineer of the necessary action to take on the plugin side.
Whiteboard: [oji_working] → [oji_working][HAVE_FIX]
r=peterl
Keywords: patch
if inOutCookieSize == cookieStringLen, then inOutCookieBuffer would not be null terminated... could this cause trouble? and, if not, then why are you bothering to memset(0) the buffer?
inOutCookieSize is not necessarily == cookieStringLen. CookieStringLen is the length of the cookie from the cookie store. If cookieStringLen > inOutCookieSize, we return without writing to the buffer. In most cases, inOutCookieSize > cookieStringLen. I just memset the buffer to 0 for good measure. If you like I can simple set the inOutCookieBuffer[cookieStringLen] = '\0'. Ed
my point was that if the buffer size is equal to the length of the cookie string, then there would be no room for the null terminator. can this ever happen?
Darin, yes, that can happen. I will modify the comparison for size to be this: if (NS_FAILED(rv) || (!cookieString) || (inOutCookieSize =< (cookieStringLen = PL_strlen(cookieString.get())))) { return NS_ERROR_FAILURE; } This will ensure that a buffer of insufficient size is not written to. With that can you give sr=
ok, but i still don't understand why the memset is necessary. you will get the correct result by just using strcpy in place of memcpy. - nsCRT::memset(inOutCookieBuffer, 0, inOutCookieSize); - nsCRT::memcpy(inOutCookieBuffer, (void *) cookieString.get(), - cookieStringLen); + nsCRT::strcpy(inOutCookieBuffer, cookieString.get()); also, wouldn't it be really bad if the inOutCookieBuffer were too small? why isn't it dynamically allocated?
whoops, nsCRT::strcpy does not exist... PL_strcpy is what i should have wrote.
Bug 83625 specifies a bug that involved breakage of cookies that occurred around the same time as I logged this bug. Is that bug related to this one?
this 3rd patch looks a heck of a lot like the 2nd one ;-)
this line can be removed: + nsCRT::memset(inOutCookieBuffer, 0, inOutCookieSize);
If I remove that line do I have sr=darin?
*** Bug 86252 has been marked as a duplicate of this bug. ***
sr=darin (once you remove that redundant memset line)
*** Bug 85827 has been marked as a duplicate of this bug. ***
The fix for the java plugin side of this bug will go into jdk1.4. I'd like to get this on the 0.9.2 branch for netscape 6.1.
Keywords: nsBranch
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Ed, Did this fix actually get on the 0.9.2 branch for inclusion into Netscape 6.1?
*** Bug 90037 has been marked as a duplicate of this bug. ***
I think this bug needs to be reopened. We should *not* have to wait for JDK 1.4 to fix it. Fact: It worked in Mozilla prior to 0.9.x. Fact: It works in IE 5.5 with JDK 1.2.2, 1.3.0, and 1.3.1. So why can't it be made to work in Mozilla with JDK 1.3.1? Can't you go back to how it used to be? Are you telling us that we can't use Mozilla to access Tomcat servers? (Tomcat being Sun's reference implementataion for JSPs and servlets!)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Thad, in your opinion should this bug have worked with 0.8.1? Please let me know as soon as possible and we'll try it out with 0.8.1.
I know for a fact that this bug was not present in M0.8.1. The original comments at the top of this bug stated that it broke for the M0.9 release. I can still use the exact same JDK with Mozilla 0.8.1 without problems, as soon as I use > Mozilla 0.9 it fails. I am with Thad on this one, I am unsure why we need to wait for JDK 1.4.
I'm with Jason and Thad on this one too (have you guys added your votes for this bug?). I don't see how MSIE and Moz 0.8x worked with previous JDKs but not Moz 0.9x? It doesn't make sense that there was a problem in the JDK itself if it still works in MSIE? Also, does anyone know if this fix made it onto the Netscape 6 branch? If not, then this bug would force me (reluctantly) to recommend to my company that we can no longer support Netscape 6. We would also have to mention to our entire client base for our new application suite that we cannot support Netscape 6 as a browser and only MSIE5+ will be supported. This is not a decision I would like to make, but we simply cannot wait for JDK1.4 or Netscape 6.2 (or whatever it is deened to be) for our customers. I am now the sole champion for Mozilla/Netscape here and I am about to be crushed by the MSIE crowd. This is an important MAJOR bug if you can't use a servlet based solution for an application. I certainly hope this fix gets into the next release of Netscape 6. BTW: Ed, thanks for your work on this issue, it is appreciated.
It went in the trunk. I'm awaiting permission to put it in the branch. I'm also going to test it with 0.8.1.
I just pulled and built 0.8.1 branch on winnt and I can't even run it. I see lots of assertions: ###!!! ASSERTION: potential deadlock between CMonitor@26b6a30 and nsServiceManagerImplMonitor@a95040: 'Error', file F:\P rojects\0_8_1_BRANCH\mozilla\xpcom\threads\nsAutoLock.cpp, line 250 0[a924d0]: ###!!! ASSERTION: potential deadlock between Monitor@26afc50 and nsServiceManagerImplMonitor@a95040: 'Error', file F:\Projects\0_8_1_BRANCH\mozilla\xpcom\threads\nsAutoLock.cpp, line 250 ###!!! ASSERTION: potential deadlock between Monitor@26afc50 and nsServiceManagerImplMonitor@a95040: 'Error', file F:\Pr ojects\0_8_1_BRANCH\mozilla\xpcom\threads\nsAutoLock.cpp, line 250 0[a924d0]: ###!!! ASSERTION: potential deadlock between Monitor@26afc50 and nsServiceManagerImplMonitor@a95040: 'Error', file F:\Projects\0_8_1_BRANCH\mozilla\xpcom\threads\nsAutoLock.cpp, line 250 ###!!! ASSERTION: potential deadlock between Monitor@26afc50 and nsServiceManagerImplMonitor@a95040: 'Error', file F:\Pr ojects\0_8_1_BRANCH\mozilla\xpcom\threads\nsAutoLock.cpp, line 250 0[a924d0]: ###!!! ASSERTION: potential deadlock between Monitor@26afc50 and nsServiceManagerImplMonitor@a95040: 'Error', file F:\Projects\0_8_1_BRANCH\mozilla\xpcom\threads\nsAutoLock.cpp, line 250 ###!!! ASSERTION: potential deadlock between Monitor@26afc50 and nsServiceManagerImplMonitor@a95040: 'Error', file F:\Pr ojects\0_8_1_BRANCH\mozilla\xpcom\threads\nsAutoLock.cpp, line 250 And the browser never comes up. I made sure to make it so there were no profiles on my machine. I'd love to know why this worked with 0.8.1.
Status: REOPENED → ASSIGNED
Ed, I just tested this with the installer binary from build 2001032319 and it works perfectly on WinNT4. Perhaps if you grabbed that source and built it, you could see what we are talking about. Or you could install that binary first to see it working....then go to the source.
*** Bug 83647 has been marked as a duplicate of this bug. ***
For the record, this works with JDK1.3.1 and today's trunk on Linux. It doesn't work on the branch. Can someone please tell me how to get something checked in on the branch?
Ed, To check into the branch, you need to pull the MOZILLA_0_9_2_BRANCH tag. All you need is an r= and sr= for the patch and you must have a PDT+ in the status whiteboard of the bug. If you need that for this bug, Chofmann may help or you can send mail to pdt2@netscape.com
I just tested this with the stock JDK1.3.1 and today's trunk on winNT and it worked. This is without the JDK1.4 modification. I've asked pdt2@netscape.com for branch permission.
get it in on the branch. thanks
Whiteboard: [oji_working][HAVE_FIX] → [oji_working][HAVE_FIX], ptd+
Thanks for following up on this Ed. The big question I still have is, "will this fix make it into the next PR release of Netscape 6?". This is the build that _really_ needs this fix. Otherwise, even the next version of Netscape 6 won't work with any pages generated by servlet based servers (JSP, etc).
the answer to your question is yes, barring this patch doesn't cause any regressions.
Fix checked in to the branch.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
*** Bug 87775 has been marked as a duplicate of this bug. ***
qa->pmac
QA Contact: shrir → pmac
This bug's been fixed a while ago based on the reporter. Marking verified.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: