Results 1 to 7 of 7
  1. #1
    Join Date
    Jun 2008
    Posts
    6

    Question Unanswered: Session.abandon in ASP.NET closes all active sessions

    Dear All...

    I am pulling my hear off at the moment trying to find why the heck ASP.NET v2.0 is behaving so strangely with the session.abandon().

    Basically, I use DevStudio2008 and IIS6 with .NET2.0 (main) and (3.5) additional... etc.

    In my code, I have a global.asax file, which uses the session_start and session_end functions, in the session_start I am creating a new directory with the generated sessionID to store some user-stuff... and then deleting that directory from the session_end folder subsequently (either by clicking logoff which then calls session.abandon to fire the session_end), or timing out the page, which would then fire the session_end anyway, either way; the code works fine when testing from one browser.

    However, when more than one browser is opened from the same PC to test multiple sessions, I can see when launching more than one browser (an IE and a FireFox) 2 different SessionIDs there in each browser,

    The problem is when one of the open browsers' click's log-off, upon tracing, I can see that the session_end is fired up, doing the cleanup, but the problem is that the session_end is re-called again and kills all other active sessions causing all other browser's sessions to invalidate!.

    From the docs and the net etc, session.abandon should only close one session. What I don't understand here is why is it closing all other active sessions altogether?!

    The result is that one user logg's off, and then all other users' directories are deleted!

    I've already used the following different combination in the web.config:

    regenerateExpiredSessionId="false" (or true), same results
    cookieless="true", "false", "Auto...", etc. same results

    It's a very annoying problem, and no documentation seems to be very accurate on describing the behaviour of the session.abandon() and how it really works.

    If I use session.clear, then the session variables clear up fine, but the session_end from global.asax does not get fired-up which means the DIRectory would remain undeleted.

    I appreciate if anyone has seen this before?

    Thanks & Regards
    Heider

  2. #2
    Join Date
    Jun 2008
    Posts
    6
    Just found the culprit...

    I'm sure you're probably thinking; "Hey, the ASP.NET session management works fine for me, without having any problems closing sessions etc", but not quite...

    If you use the following line within your session_end sub/code inside your global.asax file, hell break's loose:

    System.IO.Directory.Delete(SessionFolder, True)

    Where "SessionFolder" from the above code is a directory somewhere on your application with permissions correctly set etc. Once you do a session.abandon anywhere in your web/application it would invoke session_end from global.asax, which is normal so far, in fact it looks so normal that even the above line still execute normally without anything obvious, but once the session_end function finishes execution (if you have a breakpoint set on it already), you will notice that the application would start killing all your sessions one after the other by firing calls at the session_end for each and every single session you have, and then finally it would execute application_end code in your global.asax file.

    Well, at least you know now that using the above line will cause this problem, I will continue to check and see why is this occuring and what alternative you can use to fix this .

    Regards
    Heider

  3. #3
    Join Date
    Jun 2008
    Posts
    6
    I've tried a lot of things so far, still the same painful result which is probably a nasty bug in the .NET framework...

    Any attempt to access (delete/kill) a directory would result in the application killing all it's sessions and invoking application_end at the end.

    I've tried replacing the "system.io.directory.delete..." line with the following:

    FileSystem.Kill(SessionFolder & "\*.*")
    FileSystem.RmDir(SessionFolder)

    Still the same results.

    I was also crazy enough to try the direct access to the windows API below:

    RemoveDirectory(SessionFolder)

    Where "RemoveDirectory" comes from:

    Private Declare Function RemoveDirectory Lib "kernel32" Alias "RemoveDirectoryA" (<System****ntime.InteropServices.MarshalAs(System ****ntime.InteropServices.UnmanagedType.LPStr)> ByVal lpPathName As String) As Integer


    Still the same nasty result, removing a DIR would do this nasty effect.

    Well, I've gone through 90% of the way in finding out about this bug and what not to do when doing your web so far...

    Anyone seen this before?, any ideas would be good to have.

    Regards
    Heider
    Last edited by Heider; 06-01-09 at 01:00.

  4. #4
    Join Date
    Jun 2008
    Posts
    6

  5. #5
    Join Date
    Jun 2008
    Posts
    6
    I finally found the workaround for this problem to fix...

    Well, not sure if you like to call it *again* a bug or a "feature" !...

    Anyway, the bottom line, if you keep your spool DIR (i.e. the DIR you want users or your application to write into) inside your application's web directory then it will give you the same grief I've been having so far. To fix it, you need to create a directory outside your web-main-directory and then use IIS to create a Virtual-Directory to point it to the newly created folder.

    Also, make sure you give NO SCRIPT/EXEC permissions to this directory, the main reason to prevent someone from uploading a nasty ASP code to execute on your server.

    For an example, if your application main directory is sitting under "X:\DocRoots\MyTestPage", then you would create a new directory; say "F:\App Spool", and then use IIS to create a new virtual directory inside your application; say "users" which then points to your "F:\App Spool" with read+write and no-script permissions allowed, your users would then be able to upload into your http://(...webapplication URL...)/users/user_xyz/whatever, and then once your user log's off, then you either call session.abandon or leave the session to expire, to call session_end which would then delete your "F:\App Spool\userxyz" from the spool to save some space.

    I hope this helps.

    Good luck

    Regards
    Heider

  6. #6
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10
    Wow, well done for perservering and sharing your findings!
    George
    Home | Blog

  7. #7
    Join Date
    Jul 2009
    Posts
    1
    Quote Originally Posted by gvee
    Wow, well done for perservering and sharing your findings!
    Thanks Heider !!!!

    I was also suffering from the same annoyed problem .... but after searching a lot, i found this post ... which helps me a lot ..

    Thanks again .. your both the answers are correct and helpful ...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •