Hvorfor mister jeg min Session ved post i en iframe?

Sessioner kører på serveren og på det domænet, de bliver gemt på serveren. Så det vil sige at FF gemmer din sessioner i en cache. Du kan ikke ha' den samme session kørende på 2 forskellige domæner. Du må sende det afsted via QueryString eller en Applikation.

Eller nej, heller ikke med applikations scriptet kan du.

Jeg kan aldrig huske hvordan det vender, men der kan være forskel på om du skifter mellem http://ditdomæne.dk/ eller http://www.ditdomæne.dk/ - ellers må du lige forklare lidt mere præcist hvad du gør.

Nu ved jeg ikke hvilke former for data du vil overføre... men måske kunne det være bedre at gemme det i en cookie på brugerens computer i stedet...?

\Dan

Hejsa,

Jeg har leget lidt mere med det og kommet frem til at - jaeh, jeg fanme ikke ved hvad der sker :-)

Eksempel i PHP:

<?php
session_start();
if (!isset($_POST['FormSubmit'])){
$_SESSION['SessionValue'] = "Virker!";
setcookie('CookieValue','Virker også!');
}
echo"Form: ".$_POST['FormSubmit']."<br>Session: ".$_SESSION['SessionValue']."<br>Cookie: ".$_COOKIE['CookieValue'];

?>

<form method="post" name="login" >
<input type="text" name="FormSubmit" value="Test" />
    <input type=submit />
</form>

Eksempel i ASP:

<% if Request.ServerVariables("request_method")<>"POST"  then
    session("SessionValue") = "Virker!"
    Response.Cookies("test")("CookieValue") = "Virker også!"
  end if

%>

Form: <%=Request.Form("FormValue") %><br />
Session: <%=Session("SessionValue") %> <br />
Cookie: <%=Request.Cookies("test")("CookieValue") %>

<form method="post" name="login" >
<input type="text" name="FormValue" value="Jamen dog" />
    <input type=submit />
</form>

Bruger man dem her i en IFRAME virker de også perfekt - den holder værdierne som den skal. Problemet opstår i det man kører det cross domain - så forsvinder både Session og Cookie i ASP+IE, men spiller i FF... Det pudsige er at i PHP fungerer det fint (har jeg lige fundet ud af) med IE og FF - men her går den så helt i banan hvis man prøver i Safari...

Det kan da ikke passe det skal være så pløk umuligt! :-P

// Yoc.

Cookies og sessions overlever ikke crossdomain - hverken i den ene eller anden browser.

Well, må nu sige at hvis man laver det i PHP og bruger FF og IE, så _virker_ det altså :-)

Husk på, sessionen bliver både SAT og BRUGT af den side som er åbnet I IFRAME'en... Det er ikke noget med at sessionen skal overføres til siden som åbner IFRAME'en - det er ikke det det går ud på :-)

Så er det jo heller ikke cross domain. Hvad er det præcis du mener? Har du et link til en side?

Ja, jo - Siden som har IFRAME'en ligger på et domæne, og indholdet af IFRAME'en henter fra et andet domæne.

Jeg har sat ovenstående ASP-eksempel op her:

  - http://www.yocal.dk/test.asp

Når siden loader sætter den en session og en cookie. Når der submittes er disse væk. Prøv det i hhv. FF og IE, og du vil se der er forskel :-S... Jeg er pænt blank :-)

// Yoc.

Så giver det lidt mening. FF har en rigtig dejlig indstilling om kun at sætte cookies "For the originating site only". Det gælder bil'der, iframe, og andet. IE har det måske også, men det er måske ikke sat til. Prøv. (Jeg kan ikke prøve IE, det kræver en Windowsmaskine)

Hm, jeg rev sikkerhedsniveauet fra medium til lav... Det fiksede det faktisk.

Det er i sig selv en smule kikset - for at sikre mit login er brugeren nødt til at have lavere sikkerhedsindstillinger?! Det er, lidt skidt! :-)

Hele problematikken er at jeg ikke vil have at man kan lave en post til loginnet fra en anden side... Jeg kan ikke bare checke på referen, for den kan jo snildt ændres. Så derfor var min ide at bruge en Session som valideringsredskab - men det synes ikke at være helt holdbart når det ikke kan lade sig gøre med browserens standardindstillinger! :-/

Nogen forslag?

Hm, man kan jo overveje hvorfor det egentlig virker i PHP når det ikke gør i ASP?

Er der forskel på hvordan sessions håndteres i de to sprog?

Måske bruger din PHP en session id i adresselinien?

Hejsa,

Det tror jeg ikke? Nu er jeg ikke PHPer, men den skulle meget gerne gøre det ens i de to eksempler jeg har skitseret herover.

// Yoc.

Har du et link, så kan vi undersøge det.

Hejsa,

Jeg har ændret http://www.yocal.dk/test.asp til at benytte sig af PHP-eksemplet istedet. Nu spiller det helt fint her, selv uden den manuelle indstilling. Alt går dog totalt i blåt hvis man benytter Safari, heh... <suk>

// Yoc.

Men jeg har ikke en session eller cookie med over i FF i eksemplet med PHP. Så hvad med at gøre det på en anden måde? Hvorfor på 2 forskellige domæner?

Hejsa,

Hvad mener du? I min FF får jeg både session og cookie med - så hvilken anden måde? (Det er vidst ved at være lidt sent? :-))

Det kører på to domæner fordi det er meningen at man skal kunne bruge et fælles login... Loginnet returnerer så en ticket som man kan bruge til at få information fra brugeren - det er en API-løsning. Derfor IFRAME, derfor to domæner :-)

Så skal du blot lade være med at gemme sessionid i en cookie, men fx. sætte PHP op til at lægge det i URL-en. Eller lægge det i et hidden formfelt. At bruge cookie på tværs af domæner er ikke en holdbar løsning. Som du ser ;)  Men du vil da ikke for alvor udvikle en ny løsning i gammeldags ASP?

Se, så ryger vi pludselig over i problematikken at der ikke må kunne postes direkte til siden... Det er derfor jeg bliver "nødt til" at gøre det på den måde :-) Referer værdien sammen med en Session er det eneste jeg umiddelbart kan se sikrer mig imod det.

Og hvad er der nu galt i gammeldags ASP! :-) Det er det jeg udvikler i til hverdag - det er et udemærket sprog - og dejligt hurtigt og simpelt at kode i ;-)

// Yoc.

Der er li'som sket noget fra ASP blev opfundet for 10 år siden. Dog ikke synderligt med ASP. Derfor. Det er i min ringe mening spild af tid at lave nye ting i ASP.

Der er ingen forskel på sikkerhed om sessionid er gemt i en cookie eller i en URL. Begge dele kan fint manipuleres af en bruger. Men det er en helt anden boldgade at begynde at snakke om sikkerhed i dit loginsystem.

Hvad om brugerne loggede ind på det domæne de nu skulle ind på, og du via en webservice forespurgte "login"-domænet. Eller du gik til "login"-siden uden frames, og fik en token tilbage i en passende URL. Begge dele bruges i "virkeligheden" ;)

Hejsa,

Ja, og begge dele kan så vidt jeg lige kan regne ud omgåes ved remote posting - og det er det jeg vil undgå. Hvis du laver remote-post til den løsning jeg har bakset sammen vil jeg kunne fange dig på refereren - hvilket i sig selv ikke er synderlig sikkert - da den kan manipuleres ved at sende en anden header... Men bruger du et http-objekt af en eller anden slags til at gøre det, vil den tabe sessionen og jeg vil kunne fange et fuske-login-post på den måde.

Jeg ved ikke om der findes bedre løsninger, har ikke umiddelbart kunne finde på noget.

Om der er sket noget med ASP de sidste mange år - nej, det kan jeg sagtens give dig ret i. Men det ændre nu ikke på det faktum at det stadig bruges af (skræmmende) mange virksomheder derude og danner grundlag for store seriøse systemer. Derfor er det slet ikke en dum ting at kunne og holde ved lige :-)

// Yoc.