Forum Moderators: open
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 appreciate if anyone has seen this before?
Thanks & Regards
Heider
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.
Thought about adding this in case you wondered.
Regards
Heider
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
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.Runtime.InteropServices.MarshalAs(System.Runtime.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
[blogs.msdn.com...]
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 [(...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
App_Data folder Contains Microsoft Access databases (.mdb files), XML files, and other data stored in local files. The user account that is used to run the application (for example, the local ASPNET account) has permissions to read, write, and create files in this folder. Various ASP.NET application features, such as the providers for membership and roles, as well as the Web Site Administration Tool, are configured to work with the App_Data folder specifically.
I have checked it, still the same issue when creating a folder inside App_Data, once deleting that folder, the application would restart.
I have no problems with Files at all.
Anyhow, my solution of creating a virtual directory works great now, in fact, I should've done this ages ago, it's also perfect from the security and backup perspective.
Kind Regards
Heider
sessionState Element [msdn.microsoft.com]
Session-State Modes [msdn.microsoft.com]
The Out of Process Session State might be more suited for your needs here.
StateServer Session state is using the out-of-process ASP.NET state service to store state information.
Please don't worry about it now, as you can see, I resolved it above with my earlier post without using any other external session-management products, besides, I need my code to reside inside the session_end since it's only supported by Microsoft/.NET to run when the session-mode is set to InProc mode.
Some might call it a bug... others might call it a "feature" !... :)
Thank you for trying to help anyway, I appreciate it.
Kind Regards
Heider
Your suggestion is nice
