Manglende session på prod-miljø

Styring af session baseres sig oftets på at browseren tillader ikke-persistente cookies. Alternativt kan man oftes sætte app-serveren op til at benytte URL-rewrite istedet (dvs. at den tilføjer noget lign ";JSPSESSION=XXXXXX" til din url).

kan du uddybe det lidt nærmere ?

Du skal checke prod og test app-server konfiguration for:
  - cookie only eller cookie alternatively url rewriting for session
  - session timeout

Man skal huske at ens kode skal være forberedt på url rewriting hvis det
skal virke.

(det bør man selvfølgelig altid gøre, men det kan jo smutte)

Er der andre forskelle på prod og test - såsom en HTTP server foran prod ?

Vi kører på en tomcat server, hvilken fil skal jeg kigge i ?

Vi har kørt et op mod et mediomiljø den sidste uges tid, og alt har virket fint. Vores kunde har inkluderet os i en iframe på deres testside og det har virket.
Vi har hidtil haft en index.html liggende i webapps/ROOT og den er nu fjernet. Den blev blot brugt af os, så vi havde et sted hvor vi havde vores site i en iframe. Det skulle vel ikke gøre den store forskel ??
Har det betydning hvilken side der inkluderer os ??

http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/context.html

context har en cookie attribut

Jeg var 99% sikker på at session timout også blev sat i server.xml, men jeg
kan kun finde den i web.xml ...

Principielt bør det ikke betyde noget i hvilken sammenhæng en side loades.

(man skal passe på hvad relative URL'er kan blive transformeret til, men
det skulle ikke betyde noget for session)

Vi er på sporet af noget med tredie parts coocies, for hos nogle virker det og hos andre ikke. Det er vist også noget med IE6 ?
Kender du noget til forced sessionID

Vi ser ud til at kunne løse problemet således:
i server.xml disables cookies
på alle links bruges href="<%=response.encodeURL("min url")%>"

Som jeg skrev 01/06-2004 11:24:15, så bør man altid bruge den.

Docs er også ret klar:

For robust session tracking, all URLs emitted by a servlet should be run through this method. Otherwise, URL rewriting cannot be used with browsers which do not support cookies.

Margit, problemet er som du rigtigt er inde på at de cookies i sætter for browseren er tredjeparts cookies fordi i kører i en IFRAME.
IE 6 blokerer som standard 3.parts cookies.

Du behøver ikke at ændre sessionshåndteringsstrategi til URL-rewriting, der er en bedre løsning. Det kan iøvrigt også være du får brug for cookies til andre ting.

LØSNING:
Hvis du på alle HttpResponses lægger en header, med en P3P compact policy, så blokerer IE6 ikke 3. parts cookies. :o)

Du kan fx gøre det med et filter a' la det her:

<code>
public class P3PFilter implements Filter {

    public P3PFilter() {
    }

    public void destroy() {
    }

    public void init(FilterConfig filterconfig) throws ServletException {
    }

    public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) throws IOException, ServletException {
        ((HttpServletResponse)response).addHeader("P3P", "CP=\"CAO DSP COR CURa ADMa DEVa OUR IND PHY ONL UNI COM NAV INT DEM PRE\"");
        filterChain.doFilter(request, response);
    }
}
</code>

Arne, jeg er uenig i at ens kode nødvendigvis skal være forberedt på url-rewriting.
Cookie-baseret sessionshåndtering virker fortrinligt, og brugerne slipper for at have mærkelige koder i deres urler, som kan gøre det vanskeligt at bookmarke.
Hvor stor andel af de sites du bruger anvender url-rewriting? Ikke mange.

Der er rent faktisk folk som f.eks. disabler cookies i deres browser.

Det er anerkendt som best practice i JavaDoc, J2EE totorial og alle de
bøger jeg har læst at man altid kalder encodeURL - bare for at være helt sikker.

Containeren bør være smart nok til at foretrække cookies og kun falde
tilbage til URL rewriting hvis cookies ikke virker.

Derfor understøtter et professionelt site muligheden for URL rewriting men
99% af brugerne ser det ikke fordi de accepterer cookies.

Nå - nu skal jeg heller ikke gøre mig mere hellig end jeg er - jeg glemmer
stort set altid selv at kalde encodeURL.

Iøvrigt et meget smart lille trick. Som ligger langt uden for hvad jeg kender
til (jeg er absolut ikke kyndig ud i browsere).

Virker det generelt eller er det en MSIE specifik header ?

Tazly
Det ser temmeligt kompliceret ud, jeg er ikke lige en haj...
Det jeg har lavet er rent teknisk rigeligt simpelt, jsp med beans og nogle klasser der styrer navigeringen, men ikke noget med at sende HttpRequest/response op til mine klasser....
Så hvor vil jeg kunne implementere den kode du angiver ?.
Vil jeg kalde den der doFilter i starten af mine jsp sider ?
og hvad er det for noget konfiguration der skal bruges ??

Jeg har for nu løst det med encodeURL - det var let og overskueligt, da al trafik på siden er intern og igennem ialt 5 form's der bliver submittet. Altså INGEN <A> tags.

Et filter er noget kode som kaldes før enhver servlet kaldes.

http://www.javaworld.com/javaworld/jw-06-2001/jw-0622-filters.html
http://javaboutique.internet.com/tutorials/Servlet_Filters/
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Servlets8.html#wp64572

Jeg lukker denne, vi fandt selv svaret

Arne>> Ok, jeg troede at du ville bruge URL-encoding som sessionhåndtering til alle, og ikke defaulte til cookie-baseret.

Problemet med default-blocking af 3.parts-cookies er SVJV kun hos IE6. Men P3P compact policies burde virke generelt, da det er W3C, som har gang i at standardisere dem. http://www.w3.org/P3P/2003/03-compact.html
Ikke-compact P3P policies er iøvrigt ret besværlige at have med at gøre.

Margit>>
Filtre er ikke komplicerede, men en nem og elegant løsning på aspektet at kalde den samme kode i sin webcontainer ved hvert request.

1) Du kan compilere filter-klassen uafhængigt af resten af din kode med javac eller dit yndlings-java IDE.
2) NEJ, doFilter kaldes automatisk af Web-containeren - du skal intet gøre i dine JSP'er
3) Filtre sættes op i web.xml. Du kan sætte dem til at køre på alle request med et givent url-pattern. Fx /