Bug #47815 | Session expires is incorrect | ||
---|---|---|---|
Submitted: | 4 Oct 2009 22:47 | Modified: | 15 Oct 2009 15:30 |
Reporter: | Poul Bak | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | Connector / NET | Severity: | S3 (Non-critical) |
Version: | 6.1.2 | OS: | Any |
Assigned to: | Vladislav Vaintroub | CPU Architecture: | Any |
Tags: | MySqlSessionProvider |
[4 Oct 2009 22:47]
Poul Bak
[4 Oct 2009 22:55]
Poul Bak
Running asp.net 3.5 sp1 MySql Serverversion: 5.1.35 This happens both on local iis server (IIS 5.1 windows xp sp3) and production server (IIS 6.0 Windows server 2003).
[7 Oct 2009 1:37]
Poul Bak
Now I can easily reproduce: Simply set timeout to a non-default value, like 60. Make sure you use session in your site (set some session values). Run the website: Notice first request looks correct, following requests use the default value! I also found the bug. Line 135 in SessionProvider.cs: Configuration webConfig = WebConfigurationManager.OpenWebConfiguration(null); That opens the ROOT web config, not the application web.config. Use "~/" instead of null! The reason the first request succeeds, is that you get the timeout parameter when creating the session, on updates you use the value from YOUR incorrect config.
[11 Oct 2009 13:19]
Poul Bak
Not even a comment?
[12 Oct 2009 7:26]
Tonci Grgin
Sorry Poul. I have two problems here, first one is that I was on vacation and the second one is that I find it hard to jump between API's/frameworks on a daily basis and I'm currently working on ODBC. Will see what I can do.
[13 Oct 2009 12:40]
Tonci Grgin
Poul, can you please attach sample web site project demonstrating this behavior?
[13 Oct 2009 17:48]
Poul Bak
Hi, assuming you have a website using MySqlSessionProvider: Set 'timeout' in the application's web.config to a non-default value, like this: <sessionState mode="Custom" timeout="60" Make sure, you're actually using session in the website by setting a session value in a page, like this: protected void Page_Load(object sender, EventArgs e) { Session["ABC"] = "X"; } Although the bug is actually quite triggy to debug (sometimes it seems to work correct), here's a fast method and the simple solution: In 'SessionProvider.cs', set a BREAKPOINT at line 139, compile and run the website: Now, in VS, examine the 'sessionStateConfig' variable at line 136. Note that 'timeout' has the default value of '20' !! Reason (the bug) can be found at line 135: Configuration webConfig = WebConfigurationManager.OpenWebConfiguration(null); This opens the DEFAULT (ROOT) web.config (the one in same folder as Machine.config), which always return the default value for timout. Solution is quite simple, change line 135 to: Configuration webConfig = WebConfigurationManager.OpenWebConfiguration("~/"); Try to run again and see the correct value.
[14 Oct 2009 14:15]
Tonci Grgin
Poul, I am working exclusively on this now.
[14 Oct 2009 14:23]
Tonci Grgin
After long discussion with Wlad I'm setting this bug to "Verified" and assigning him to check/fix it.
[14 Oct 2009 21:21]
Poul Bak
I'm sad to hear that, after clicking on the 'Assigned to' link above, I can see that all bugs related to Connector.net have the status 'verified', some are almost a year old. In other words, assigning this bug to him result in no fix?
[14 Oct 2009 21:49]
Vladislav Vaintroub
Defending myself, I'm less than 1 year in Connector.NET. I actually started in May:)
[14 Oct 2009 22:59]
Poul Bak
I apologize, if I was wrong.
[14 Oct 2009 23:16]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/86876 777 Vladislav Vaintroub 2009-10-15 Bug#47815 : fix SessionProvider to read timeout from the application specific web.config, not from the root web.config
[15 Oct 2009 5:28]
Poul Bak
Thanks! Apology triggered :-)
[15 Oct 2009 15:30]
Tony Bedford
An entry was added to the 6.1.3 and 6.2.0 changelogs: The Session Provider created invalid “session expires” on a random basis. This was due to the fact that the Session Provider was incorrectly reading from the root web.config, rather than from the application specific web.config.