5

We are seeing an issue where the Session isn't being abandoned in DNN. I'm not sure if this is was a 4.5.x issue as we upgraded a while ago to 5.x and maybe referencing an older control.

The login/logoff control we are referencing in our module is DotNetNuke.UI.Skins.Controls.Login located in path DNN_Web_Root/admin/Skins/login.ascx

In there it looks like it does a redirect to logoff.aspx which then goes through the LogoffHttpHandler, which then goes somewhere to complete the logoff process however I cannot find where that process is to see if Session.Abandon is being called.

Can anyone answer the following:

  • Is there an issue with DNN where Session.Abandon is not being called on Logoff?
  • What is the process that actually handles the LogOff process?
thames
  • 5,833
  • 6
  • 38
  • 45

3 Answers3

2

Logoff is normally handled by Desktopmodules\Admin\Authentication\Logoff.ascx. The main action is to clear the authentication cookie, along with a few other cookies and some user specific cached data.

DotNetNuke NEVER uses Session for anything and does not clear Session during a log off.

ScottS
  • 8,455
  • 3
  • 30
  • 50
  • 2
    Is there a reason why DNN does not call Session.Abandon during a log off? There could be other modules that use Session or is that incorrect? If it is incorrect why is that practice incorrect? – thames Jun 08 '11 at 15:36
  • 2
    DNN does not touch Session ever, for any reason. If a module would like to use session, it is wholly responsible for dealing with session. I recommend against using session at all, most often it accumulates crud relevant to specific pages that is never removed, and it quickly gets awkward in a web farm where it needs to be stored out of process and be serializable. State is almost always better persisted in the database. Careful use of the DataCache API can ensure rapid access to that state. – ScottS Jun 08 '11 at 17:38
  • 1
    @thames There are other modules that use session state, I presume most of them simply let the session timeout, which it will often do anyway when the user doesn't bother to click on logout. If you really want to abandon session, you can customize the Logoff.ascx.cs or probably safer, make your own customized copy and update the LogoffControlSrc field in the Authentication table to point to it. – ScottS Jun 08 '11 at 17:41
0

I assume the threat you're worrying about is the shared computer environment scenario where someone logs off but does not close their browser, and the next user sits down and is able to access something they shouldn't because of a session variable still hanging around for 20 mins or so?

If you must use session, one work-around is to simply check

System.Web.HttpContext.Current.User.Identity.IsAuthenticated

in any place you are worried about a non-logged in user taking advantage of the previous logged in user's session variables.

That being said- calling Session.Abandon() in Logoff as @ScottS suggested may be the easiest way to go, though this option may not be available in a hosted environment.

TTT
  • 22,611
  • 8
  • 63
  • 69
0

it looks like Dan Rowe had some luck with the following code:

Response.Redirect(Globals.NavigateURL(TTSRoutines.giPunchinPage, "Logoff"), True)

Reference

Brian Webster
  • 30,033
  • 48
  • 152
  • 225
  • This is the redirect that I talk about in the question. I have not found what process handles this redirect to log out of the DNN session. However, I'm wanting to know if DNN is not calling Session.Abandon. – thames Jun 06 '11 at 13:38
  • It is not (but should), for an unknown reason. Would have to dive into the DNN source to find out. – Brian Webster Jun 06 '11 at 18:30