Hej!

Jag har nyligen fått rapport om EN användare som inte kan logga in på netxtra.se
När jag kollade upp det visade det sig att jag inte heller kan logga in från en av mina datorer.

Denna enda användare (som har hört av sig iaf) kan heller inte lägga produkter i kundvagnen, de försvinner så fort hon gör något.
Från min dator som jag inte kan logga in från kan jag lägga produkter i kundvagnen, men inte logga in.

Scriptet fungerar så att det skickar inloggningsuppgifterna via GET (eftersom POST kan ställa till det i brandväggar. Jag körde POST tidigare, men ändrade nu, hjälpte inte) till en sida som använder ett användar-objekt för att logga in. Detta objekt returnerar OK, och när jag kontrollerar detta på samma sida, så är det okej. Användaren skickas sedan vidare med Response.Redirect till en sida där information visas till den som är inloggad. På denna sida körs en koll om användaren är inloggad, och här returneras ERROR, och användaren hänvisas tillbaka till inloggnignsformuläret.

Någon som har minsta aning om vad som kan vara fel?
Objektet som används för användarhantering har fungerat i över tre år utan förändringar, så jag tycker inte att felet ligger där. Dessutom fungerar det uppenbarligen för dom ca 300 användare som beställer varje dag.

/Stefan

Det är inte så det körs Session Cookies och det spökar hos användaren... Jag har varit med om
att folk har haft t.ex Norton/Symantec produkter installerade som tog kål på kakorna i minnet under
pågående körning

Jag har funderat på det också, men en kund jag pratade med igår lyckades stänga av sin brandvägg och det fungerade iallafall inte.

Det konstiga är att i min testmiljö fungerar det för mig, men inte i live-versionen. Inte ens från samma webbläsare, samma dator..

Mycket märkligt..

[edit]
Jag kan även logga in på administrations-sidan, där är det inga problem. Det är bara i butiken jag inte kan logga in.
[/edit]
[edit2]
Gjorde även en test, där jag skriver både en cookie och en sessionsvariabel på en sida, redirectar till en annan, och läser av. Detta fungerar utan problem.
[/edit2]

Knepigt... då låter det ju som att sessionsID´t på nåt sätt bara dör i hoppet mellan sidorna...

Man skulle nästan kunna lukta sig till ett IE / XP sp2 problem här men det är ju lite spekulation iofs, har haft problem med frames i senaste IE patchen från MS där den inte riktigt vill förstå innebörden i vilken frame man pekar på så att allt hamnar i _self ...

Jag kör en massa liknande saker i en del webshoppar där det kollas mot en sessionsvariabel på varje sida om användaren är inloggad och jag har aldrig upplevt ett problem med just de bitarna

knepigt också att det inte är fler som uppmärksammar problemet

Vi har nu två som har hört av sig.

Visst, absolut... Om det inte vore för att jag kör Windows 2000 Server på den maskin som det inte fungerar på.. Min maskin med XP sp2 fungerar det däremot utmärkt på.

Ja det övergår mitt förstånd i alla fall vad det kan bero på =)....

Känslan man får är ju att eftersom det funkat tidigare utan problem så är
det ju något som hänt den senaste tiden och mig veteligen så släpptes det
en IE patch nyligen och jag skulle nog börja att leta där, tror ju inte att det är
direkt kodrelaterat på serversidan utan att det är klienterna som spökar

Kan nog tyvärr inte hjälpa dig med detta problem, skall dock slå en liten kik
i MS KB o se vad som händer i den senaste patchen

Varför ställer "POST" till det i brandväggar?

/Zoran

Jag vet inte om det är så att POST ställer till det i vissa brandväggar, men jag har läst det någonstans.
Tänkte bara testa, å se om det blev bättre..

Om en brandvägg blockar POST beror detantingen på att den är trasig eller att den via sina regler skall blocka HTTP POST. Jag vet att det finns minst en brandvägg där det senare är möjligt, men det är knappast vanligt att man vill ha det på det viset (om man inte är extremt paranoid).

Jag vet även att vissa proxys inte agerar korrekt och därför klipper bort innehåll som vissa headrar och/eller content i requests, men även där rör det sig om produkter som inte uppträder som de borde.

Detta löser ju dock knappast dina problem...

Hur sker inloggningen? Exakt vilka cookies används? Finns dessa kvar när du kommer "tillbaka" och användaren är utloggad igen?
Eftersom du kan återskapa problemet borde det vara en smal sak att via loggning testa vad som saknas när autentiseringen misslyckas.

Så utomordentligt fånigt. Jag har aldrig hört fånigare. Det är som att bygga en bil och strunta i att montera några bromsar. Man har ju trots allt motorbroms.

Va fan, att låta brandväggen göra såna kontroller av trafik genererar oerhörd överhead. Vem fan är ens så dum att försöka implementera det i en brandvägg? Men jag antar att om man gör det och sen bakar in massa buzzwords i whitepapers så finns det en och annan inkompetent fåne som köper det och sen använder.

Nå, det var dagens dummhet.

I Apache krävs det väl inte mer än 3 rader i konfigfilen för att göra POST otillåtet.

/Zoran

Inga förändringar som har gjorts på sistonde? Updatering av objekt för (de-)kryptering av passwords etc???

Nu går vi fett off topic så en moderator är välkommen att splitta denna tråd...

Att göra en stateful inspection av ett protokoll i en brandvägg har visst vissa poänger. Det finns massor av program som kör på port 80 för att den "brukar" vara öppen men där trafiken sedan inte alls är HTTP trafik (spyware, maskar och t.o.m. icq kan väl också köra på port 80)
Så en brandvägg med stateful protocol inspection ger ett ökat skydd för den paranoide.

Och precis som jag skrev i mitt ursprungliga inlägg är detta knappast något som är speciellt vanligt. Eftersom det ger en del overhead.

T.ex. försvaret och en del andra offentliga instutitioner använder sig av en brandvägg som är specielaskriven för försvarets behov. Och de är ju betydligt mer intresserade av säkerhet än prestanda även om prestanda också är viktigt.

Så visst finns det folk som är paranoida nog att vilja ha statefulinspection och inte bara titta på portar och addresser. Men som sagt, jag tror inte det är problemet i detta fall.

Nej inga förändringar i några objekt. Objekten är gjorda av någon annan, innan jag började på det här jobbet. Vad jag vet (och vad som står i kommentarer här och där) är ingenting ändrat i dom de senaste tre åren.

Inloggningsfunktionen i användarobjektet skriver en cookie, och returnerar en kod för hur det gick. Här är det inga problem. Eftersom inga problem påträffades körs en Server.Transfer till sidan för den som är inloggad. På denna sida kontrolleras att användaren är inloggad, och jodå, det är han/hon. Denna sida kör ett javascript för att uppdatera frames, i dessa frames visas olika innehåll beroende på om användaren är inloggad eller inte. Innehåll för den som inte är inloggad visas i dessa.

Först hämtas användarnamn och sessionsnyckel från cookie, och sen körs kontrollen för inloggning. Fungerar alltså icke. Och detta fel uppstår för hittills två användare (och mig) sen vi lanserade nya sajten (mitten av augusti).

Jag har inte reagerat på detta tidigare, men jag är osäker om jag har försökt logga in tidigare. Det är på server-datorn som problemet finns, och jag använder inte den så mycket.

[edit}
Internet Explorer 6 (som jag använder) brukar ju säga till när cookies spärras också, som till exempel här på wn. Det upplever jag inte på netxtra
[/edit]

Jag har hittat information om "Cumulative Security Update for Internet Explorer (889293)"

Det verkar kunna vara denna som ställer till problem.

Då återstår frågan, hur löser man problem som Microsoft ställer till med?

Betyder detta att hämtningen från cookies går bra och att det är ditt objekt som gör kontrollen som genererar fel eller går det inte att hämta cookiesarna?

Det blir ingen cookie av någon anledning. Sitter här å klurar..

Lyckades hitta en kompis som hade Windows XP SP1 UTAN säkerhetsuppdateringen för IE6, och han kunde logga in. Fick honom att installera uppdateringen, men tyvärr kan han fortfarande logga in. Alltså beror det inte på den heller.

Hur ser setcookie funktionen ut ,cookie_path m.m ?
Hur ser eventuella redirects ut kodmässigt ?

Nu har jag löst det.
Jag kan tydligen inte längre skapa kakor som ser ut som Response.Cookies("netxtra")("user")

Konstigt.

utan du måste göra vaddå?

Ett allmänt tips:
Skaffa något för att kika på http kommunikationen mellan klienten och servern. Mycket bra i sånna här lägen, och annars mycket lärorikt.

IEWatch är bra, men det finns massa proxylösningar på sourceforge som också borde fungera.

varför inte ethereal t.ex...

Man använder Apache/PHP/Linux ... skämt åsido du verkar ha lite problem lite varstans, jag skapade precis ett konto och på sida 2 i registreringen så står det "Klicka här om du inte vill ha medlemsmailen" eller nåt sånt men det fanns ingen länk däremot så var adressen utskriven på sidan.
Sen var typsnittet skitfult och aslitet, gick knappt att läsa.

Så nu har jag spätt på problemen. ;)