[Java] Appletviewer houdt geen sessieinfo bij

Pagina: 1
Acties:

  • Ghost
  • Registratie: April 2002
  • Laatst online: 04-02 19:07

Ghost

Phasma Ex Machina

Topicstarter
Ik ben al geruime tijd bezig met een servlet-applet Java project in Netbeans 5.5, waarbij de communicatie via het http-protocol verloopt. Vanwege het feit dat http stateless is, moet het servlet sessies gebruiken om de verschillende aanroepen van verschillende applets bij elkaar te houden.

Nu ik aanbeland ben bij het cruciale onderdeel waarbij ik het applet en servlet daadwerkelijk met elkaar wil laten praten, loop ik tegen het volgende probleem aan: als ik het applet start in de appletviewer, maakt de server met daarop het servlet iedere keer een nieuwe sessie aan, alsof de appletviewer geen manier ondersteunt om de sessies te bewaren.

Wanneer ik echter het applet in Firefox laad, werkt alles naar behoren en blijft de sessie bestaan.

Heeft iemand een idee waar het probleem zit. Ik verwacht dat het een beveiligingsinstelling is bij de appletviewer of NetBeans zelf, maar heb geen plaats gevonden waar ik dit kon instellen.

Voor de volledigheid: ik heb de volgende testcode gebruikt om mijn probleem uit te diepen:

Java: EchoApplet.java
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
    private void connectWithServer() {
        try {
            // connect to the servlet
            String servletLocation = "gemaskeerde url naar servlet"; // Gemaskeerd voor forumpost
            URL studentDBservlet = new URL( servletLocation );
            HttpURLConnection servletConnection = (HttpURLConnection) studentDBservlet.openConnection();
            
            // Don't used a cached version of URL connection.
            servletConnection.setUseCaches(false);
            servletConnection.setDefaultUseCaches(false);
            
            servletConnection.setRequestProperty("Content-Type", "testapplet/x-java-serializedobject");
            servletConnection.setDoInput(true);
            servletConnection.setDoOutput(true);
            
            ObjectOutputStream outputToServlet = new ObjectOutputStream(servletConnection.getOutputStream());
            
            outputToServlet.writeObject(jTextArea1.getText());
            outputToServlet.flush();
            outputToServlet.close();

            ObjectInputStream inputFromServlet = new ObjectInputStream(servletConnection.getInputStream());
            String testMe = (String) inputFromServlet.readObject();
            jTextArea1.setText(testMe);
        } catch (MalformedURLException ex) {
            ex.printStackTrace();
        } catch (IOException ex) {
            ex.printStackTrace();
        } catch (ClassNotFoundException ex) {
            ex.printStackTrace();
        }
        
    }


Java: EchoServlet.java
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
    private void sendObject(HttpServletResponse response, Object returnObject) {
        ObjectOutputStream outputToApplet;
        try {
            response.setContentType("java/x-serialized-object");
            outputToApplet = new ObjectOutputStream(response.getOutputStream());
            
            System.out.println("Sending student vector to applet...");
            outputToApplet.writeObject(returnObject);
            outputToApplet.flush();
            
            outputToApplet.close();
            System.out.println("Data transmission complete.");
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
    
    private String getString(HttpServletRequest request) {
        String gotIt = "Empty";
        try {
            ObjectInputStream input = new ObjectInputStream(request.getInputStream());
            gotIt = (String) input.readObject();
            input.close();
        } catch (IOException ex) {
            ex.printStackTrace();
        } catch (ClassNotFoundException ex) {
            ex.printStackTrace();
        }
        return gotIt;
    }
    
    private int timesVisited(HttpSession visitor) {
        Integer visitNum = (Integer) visitor.getAttribute("timesVisited");
        
        int realInt = 0;
        if (visitNum != null) {
            realInt = visitNum.intValue();
        }
        
        visitor.setAttribute("timesVisited", new Integer(realInt+1));
        if (realInt >= 10) {
            visitor.invalidate();
        }
        
        return realInt;
    }
    
    /** Processes requests for both HTTP <code>GET</code> and <code>POST</code> methods.
     * @param request servlet request
     * @param response servlet response
     */
    protected void processRequest(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
        HttpSession visitor = request.getSession();
        
        int visitNum = timesVisited(visitor);
        
        String extracted = getString(request);
        
        extracted += " <-- Read and returned";
        
        extracted += "\nYou have been here " + visitNum + " times before :)";
        
        if (visitor.isNew()) {
            extracted +="\nNew session created";
        }
//        
//        
        sendObject(response, extracted);
    }

When in doubt, press some random buttons.


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 02:32

Janoz

Moderator Devschuur®

!litemod

Om eerlijk te zijn verrast het me dat het in Firefox werkt, maar dat zal wel komen doordat een URL request van een applet via de browser afgehandeld wordt. In je applet code gebruik je namelijk helemaal niets wat ook maar iets te maken heeft met het kunnen bijhouden van de sessie. Normaal is dat een cookie (of heel soms een extra url parameter). Zeer waarschijnlijk zit er in de applet viewer helemaal niks qua code omtrend het bij houden van cookies en werkt het daarom niet in de applet viewer.

De vraag wat nu toe doen is eigenlijk de volgende. Is het gebruikelijk dat een applet de cookies kan gebruiken van de browser (test het applet ook eens in opera en IE). In dat geval zou je eigenlijk gewoon moeten overwegen om niet met de appletviewer te testen, maar gewoon een browser gebruiken. Is het niet gebruikelijk, dan zul je in je code wat meer met je request moeten doen. Je zult zelf de sessionID moeten achterhalen, bij moeten houden en met elk request mee moeten sturen.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • Ghost
  • Registratie: April 2002
  • Laatst online: 04-02 19:07

Ghost

Phasma Ex Machina

Topicstarter
Okay, als ik het dus goed begrijp zijn mijn opties als volgt:
  • schrijf een routine dat zelf de sessionID's bijhoudt om het zo zowel in de appletviewer als browsers te kunnen laten werken
  • ga verder weken met een browser, omdat die zelf om kan gaan met cookies
Als ik dit zo zie, ben ik afhankelijk van het beleid van de browser of ik een sessie kan bewaren. Kan ik dan niet beter sowieso het heft in eigen hand nemen en mijn applet zelf de cookiewaarden bijhouden? Op die manier kan mijn applet ook in striktere omgevingen werken, als, bijvoorbeeld de browser geen cookies ondersteunt.

Hoe zou ik dat het beste dan kunnen aanpakken? Onder andere via deze link ben ik er achter gekomen dat ik de 'set-cookie'-header kan uitlezen en opslaan. Werkt dit dan ondanks de instellingen van de browser waaronder het applet draait?

When in doubt, press some random buttons.


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 02:32

Janoz

Moderator Devschuur®

!litemod

Het cookie wordt sowieso wel meegestuurt met het response. Aangezien je applet zelf statefull is kun je die sessionID makkelijk onthouden en bij elk request meegeven. Wat je ook nog kunt doen is de sessionID al aan het applet meegeven in je jsp pagina. Gewoon middels een PARAM tag. Op dat moment hoef je in je applet helemaal niet uit te gaan vogelen wat het sessieID is, aangezien je die dan gewoon al meekrijgt.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'