# Tomcat/java-Session-Problem



## qeldroma (25. Jan 2006)

Hallo zusammen,

wir haben hier eine kleine Benutzerverwaltung in jsp-Seiten vorliegen. Diese haben wir nun angepasst, was die Textfelder der Benutzereingabe angeht.
Das wiederum erkläre ich, damit klar ist, das am Login sich nichts verändert hat 

Nun ist das so, das jede Seite eine "header.jsp" includiert, in der die Session auf Gültigkeit getestet wird. Die Session wird vom Server verwaltet, ist also nicht "selbstgebaut".

header.jsp-Code:

```
<%@ page contentType="text/html; charset=ISO-8859-15" %>
<%
        if(!request.isRequestedSessionIdValid()){
                response.sendRedirect("index.jsp?session");
        }
%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
....
....
```

Wenn die "index.jsp" mit "?session" aufgerufen ist, wird die Session ungültig erklärt und der Login neu aufgerufen.

Nun zum Problem:
Nachdem wir diese Änderungen im "backend" durchgeführt haben klappt der Login nicht mehr auf allen Rechnern, so gibt es nun zwei von sieben Rechnern, auf denen durch die "header.jsp" sofort nach dem Login die Session für abgelaufen erklärt wird.

Alle Rechner MÜSSEN den jeweils installierten IE verwenden, ich darf weder die Version ändern, noch einen anderen Browser installieren (Bitte nicht thematisieren, ist einfach so).

1. Erst dachte ich an ein Cookie-Problem, habe also auf allen "kaputten" die Cookies und die "temporären Internetdateien" gelöscht.
Fehlanzeige.

2. Dann habe ich die IE-Sicherheitseinstellungen allesamt auf den niedrigsten Level gestellt.
Fehlanzeige.

3. Dann habe ich, nach dem Löschen dieser Daten, die entsprechenden Rechner mal verzweifelt neu gebootet.
Wieder Fehlanzeige.

Merkwürdig ist, das dieses unabhängig von Windows-Version und IE-Version ist. So  habe ich bei den beiden "kaputten" die Kombination IE5.5/NT4 und IE6/W2k. Genau diese Kombinationen sind aber auch bei den anderen 5 auf denen es klappt ?!?!?

Jemand eine Idee?

Grüße, Florian


----------



## bronks (25. Jan 2006)

qeldroma hat gesagt.:
			
		

> ...Wenn die "index.jsp" mit "?session" aufgerufen ist, wird die Session ungültig erklärt und der Login neu aufgerufen ...


Das macht man definitiv so:
	
	
	
	





```
...eb/dpviewersamjs.jsp;jsessionid=aaac3aH6SsFnox?aktion=w...
```
Zu den anderen Problemen hab ich eine Frage: Kann es sein, daß genau in der Zeit wo Du die App umgebaut hast das Netzwerk umgebaut wurde. Evtl. irgendein Proxy?


----------



## Bleiglanz (25. Jan 2006)

die index.jsp darf natürlich NICHT die header.jsp einbinden

genausowie die seite auf der die Session erzeugt wird

ganz schlechter Stil: erst ein Redirect UND dann noch HTML Daten schicken, das ist Quatsch und nicht unbedingt ideal...


----------



## qeldroma (25. Jan 2006)

Bleiglanz hat gesagt.:
			
		

> die index.jsp darf natürlich NICHT die header.jsp einbinden
> 
> genausowie die seite auf der die Session erzeugt wird



Sorry, war unklar formuliert:
Die index.jsp hat NICHT diese header.jsp, sondern eine eigene. Die header.jsp mit der Session-Überprüfung wird nur von allen "backend"-Seiten benutzt, das Login steht für sich allein, ergo index.jsp!

Moment.....
index.jsp:

```
<%
/*****************************************
**** index.jsp
******************************************
**** Dient der Darstellung der Login-Seite
******************************************/%>
<%
// Einige generelle Sitzungseigenschaften
session.removeAttribute("mandant");
session.setMaxInactiveInterval(300);
%>
<script language="JavaScript" type="text/javascript">
//Fehlermeldungen zum Login
if("<%=request.getQueryString()%>"=="error"){
        alert("Fehler beim einloggen!\nBitte berprfen Sie nochmal die Daten.");
}else if("<%=request.getQueryString()%>"=="session"){
        alert("Ihre Sitzung ist abgelaufen!\nBitte melden Sie sich erneut an.");
}
</script>
<%@ include file="templates/headerLogin.jsp" %>
```

...die headerLogin.jsp ist eine java-lose Datei, könnt ich auch in html umbenennen 

---------------------------------------------------------------------------------------
wie gesagt, es LIEF Monatelang, nur jetzt nimmer...

Grüße, Florian[/code]


----------



## Bleiglanz (25. Jan 2006)

na und, was genau habt ihr denn geändert

wo und wann wird zum ersten Mal die Session erzeugt?


```
if("<%=request.getQueryString()%>"=="error"){
        alert("Fehler beim einloggen!\nBitte berprfen Sie nochmal die Daten.");
}else if("<%=request.getQueryString()%>"=="session"){
        alert("Ihre Sitzung ist abgelaufen!\nBitte melden Sie sich erneut an.");
}
```

[edit]

AHEM, warum mit Javascript?


----------



## qeldroma (25. Jan 2006)

Die Session wird, dachte ich, automatisch vom Tomcat verwaltet? 

Schließlich habe ich ja das HttpSession Objekt, welches ich abfragen kann und welches in der Tat bei allen anderen 5 Rechnern das Timeout nach 10 Minuten auch auslöst? Dies zeugt ja davon, das es automatisiert ist, vermutlich über ein Speichercookie?

Ich habe das bisher so verstanden, das eine Session nur dann manuell erzeugt werden muß, wenn man KEINE Cookies zur Verfügung hat, also nicht in meinem Fall?!

Grüße, Florian


----------



## Bleiglanz (25. Jan 2006)

du kannst dir zwar eine Session automatisch erzeugen lassen, aber damit request.isRequestedSessionIdValid funktioniert muss MINDESTENS ein Round-Trip stattgefunden haben

Aufruf index.jsp zum ersten Mal in einer Sitzung

=> session erzeugt, cookie zum client

=> wenn cookies abgeschaltet, führt der POST zu einer url, auf der keine Session vorhanden ist und also zum Fehler

also: biste sicher dass auf den beiden Defekt-Rechnern Cookies aktiviert sind?

=>


----------



## qeldroma (26. Jan 2006)

Bleiglanz hat gesagt.:
			
		

> also: biste sicher dass auf den beiden Defekt-Rechnern Cookies aktiviert sind?



Soweit ich den "nierigsten Sicherheitseinstellungen" des IE vertrauen kann 
Wie gesagt, die kaputten IEs sind auf minimale Sicherheit eingestellt, das sollte wohl alles zulassen, was es so gibt..

Außerdem funktionierte dieser Login ja auch schon vorher, daher müssen die Cookies ja funktioniert haben, denn ich habe keine alternatives Sessionhandling eingebaut, insofern hätte es ohne Cookies früher genauso krachen müssen....

Ich finde dieses Problem inzwischen alles andere als trivial   ???:L 

Grüße, Florian


----------



## Bleiglanz (26. Jan 2006)

na und, was genau habt ihr denn geändert


----------



## qeldroma (26. Jan 2006)

In den betroffenen Seiten:
einfügen von  <%@ page contentType="text/html; charset=ISO-8859-15" %> am Anfang, um alles zu vereinheitlichen.
Dann in einer Folgeseite mehrere Formularelemente in ihrer Form oder Beschriftung.

Nichts auf jeden Fall, was irgendeinen Zusammenhang zur Session haben könnte, denn sonst wäre ich dem ja schon lange hinterhergestiegen.

Ich werd wohl als nächstes erstmal ein paar Ausgaben einbauen müssen, z.B. die Session-Erstellungszeit. Das habe ich bisher vermieden, weil ich dabei ja gezwungen bin, einem der beiden Benutzer den Arbeitsplatz zu blockieren, um das vernünftig auszuwerten, was nicht gerade gut ankommt.

Wer definiert eigentlich den Erstellungszeitpunkt der Session? Der Server, oder? Und der Server vergleicht dann die Zeit mit dem Timeout anhand der Systemzeit, oder?

Nicht das es irgendein Uhrzeitproblem ist 

Grüße, Florian


----------

