I know that this issue has been written about in other posts, both here in DNN and "out there" elsewhere on the web. But the problem persists.

The symptoms are that you have a module that functions as expected when installed in a main/parent portal. When it's installed in a child portal, it doesn't work very well, because users get logged out after taking some action or another. There have been posts indicating it was fixed in 4.4.0, broken again in 4.5.0, "being looked at again", and who really knows?

Is there some generic solution to this problem? It is possible that specific manifestations of the problem have been fixed. In my case, I have a module that opens a new window (target="_blank"), collects some information, and passes that information back to the main DNN app. When the new window gets closed, the user is taken back to a login request for username and password. The only halfway "good" thing about this behavior is that when the login info is entered, the user is put back on the correct page rather than the main page, but that's pretty cold comfort.

I just tried this on a new 4.8.0 install, so even if the problem is fixed in some use cases and/or DNN releases, it's definitely not fixed in all of them.

Can anybody offer some insight/help? Cathal? Thanks.

Sebastian -

Thanks, but I fon't think I'm quite all the way there yet. When I return to the login page, my browser's url contains the following: http://localhost/dnn480/problemchild/WebPlanner/tabid/74/ctl/Login/Default.aspx?returnurl=%2fdnn480%2fproblemchild%2fWebPlanner%2ftabid%2f74%2fDefault.aspx

where localhost = my development machine, dnn480 = the local IIS Virtual Directory alias, and problemchild = the name of my child portal. You mentioned including the moduleid or portalid - isn't that what the second "problemchild" in the returnurl is doing? Or are you referring to something else?

And in any event, I'm not convinced that's what's going on here. The when child (target="_blank") window gets its own postback, it validates the input, writes it to a database, then registers a startup script that does exactly two things: 1) tells the parent window to do a postback (thereby refreshing itself when it recognizes that its session info has changed), and 2) the child window closes. Specifically, the script contains the lines "window.opener.__doPostBack('','');" and "window.close();" As far as I can tell, this really shouldn't have much more effect on the parent window than if a button were clicked (or any other event triggered the postback). About the biggest difference I see (thinking out loud here) is that the __doPostBack has no arguments, and everything I see when donig "ViewSource" on the rendered page does, so perhaps I'll try faking some arguments. Beyond that, I certainly don't know enough about javascript to understand why telling a parent page to post itself back should trigger a login request, so any other thoughts you might have would be appreciated.

Thanks.

It's not a bug in DNN core.  It's a bug in the custom module.  Sebastian is correct.

The most common cause of this is the use of pages that contains "makethumbnail.aspx" to display images where the portal ID or module ID is not passed as part of its parameter.  It's hard to spot because this call is made within a custom module "somemodule.ascx".  What happens is when "somemodule.ascx" is called within a child portal, the first call will work because the user is still authenticated.  After the page is rendered the first time, the encounter with "makethumbnail.aspx" will cause the DNN core to log the user out.  The very next page the user navigates to, DNN sees that they are not authenticated, will direct them to the login page with the correct return URL set.