I too am experiencing this same problem. I'm running an unmodified version of DNN 5.4.2 CE on my own dedicated server (W2008 64-bit, IIS7, SQL Server 2008 Standard Edition 64-bit). I'm been researching the problem for several weeks and haven't found any workable resolution. If admin users on any of my portals click on certain pages, they automatically get logged out. Our QA department has impersonated client admin accounts and have confirmed this behavior is consistent. We've tested exhaustively and it has nothing to do with the client because the behavior is consistent across all computers tested (numerous ones across the country), all OS's, all browsers tested, etc. The host account is unaffected. We are using the standard DNN authentication service provider.

We've systemically tested and found offending modules that if removed from a page, cause the problem to go away and behavior to return to normal. Unfortunately, there are several modules that cause this problem such as the DNN Feedback form, NavXP, iWeb Feedback Designer, Markit: Slideshow, and numerous others. We've gone in and disabled specialized modules such as ifinity URL Master and DNNMasters Multi-User Portal Sharing Xtreme that we thought might be playing a role. Then, we flushed all server and client cache and restarted everything but no such changes have made any difference.

This problem is so severe it's caused major project launch delays that are jeopardizing our business. Any insights would be greatly appreciated.

Thanks,
John

Bruce,

Thanks a bunch for the response. I had done a lot of diagnostics on the problem using Fiddler and other tools to no avail - all normal parameters.

Thankfully however, I did find a solution from another user on (http://web3.dotnetnuke.com/Community/Forums/tabid/795/forumid/108/postid/369822/scope/posts/Default.aspx#369822) who had encountered the same problem.

As soon as we added the admin user accounts from child portal to the parent portal, all the log out problems went away. Since we were  building the sites in a staging mode prior to launching to the client's domains, we had to run them on one of our domains as child portals. For some reason, there appears to be a permissions bug in DNN where admin accounts running on a child portal will have problems if that same account and permissions do not also exist in the parent portal. This issue is only caused by certain modules such as the DNN Feedback module. The problem is very consistent so it shouldn't take much to repeat it for debugging purposes.

Thanks again for your help,
John

I just wanted to come back in on this topic, even though it is an old post.

Through researching another instance of this issue on a site using both the Url Master module and the Markit Slideshow on a child portal, I worked out some more relevant information.

In the case of the Markit slideshow, the symptom will show up as an immediate logout once logged into the child portal.  This will occur on any page that has the slideshow implemented as a module.  It may be incorrectly diagnosed as a logout on some other action (ie, click on another page, try and edit content, etc).  The problem is that the user is logged out immediately after viewing the page.  The cause is that the .ashx requests made by the Markit module cause the logout when the Url Master module is installed.

These .ashx requests are for resources like cssHandler.ashx, ImageHandler.ashx and perhaps others.  Each of these calls passes a long querystring to the handler.  It's not clear ot me what these calls do, and it's not really important anyway.  What happens is that these calls get processed by the Url Master module, and that causes the user to be logged out.  I don't know the exact cause, but my guess is that because they are made to the 'root' of the site (ie example.com) then the incorrect portal is loaded for the authentication (ie example.com/child should be used) and the authentication code in DNN logs out the user for requesting the wrong portal.

The solution is to stop these calls from being processed through the Url Rewriting code.  Stoppign them being processed prevents the portal settings code from being run, which prevents the authentication code from being run.  Thus the calls are made anonymously, and don't interfere with the authentication.

So, for the Markit module, you need to add on a regex pattern to the 'ignoreRegex' field.   I've detailed this in a KnoweldgeBase page for the module here: Url Master / Markit Slideshow Settings  - I haven't put the settings into this forum post as I try and keep a canonical resource for this type of thing should future releases change this.

For other modules behaving in a similar way, the solution is likely to be similar.  First, try and identify which requests might be doing the logoff action.  If you trace with Microsoft Fiddler, you'll often see a 302 instead of a 200 for some requests in the page.   This is a marker of something to look at - the 302 is caused by the logoff code redirecting back to a different page.  ALternatively, try removing/disabling modules on a module-by-module basis until it stops logging off.  If you find which it is, then look at the requests for that module more closely.

Putting a matching expression into the 'ignoreRegex' pattern means that, for the purposes of Url Rewriting (and by extension, portal identification and portal settings loading), the request will be totally ignored.   This is often the way to solve an issue like this.