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