It is not a bug, it is behaviour by design.

if a user moves between portals dotnetnuke automatically detects this and logs the user out i.e. user "john" on portal 1 is not necessarily the same user as user "john" on portal 2. This is done by detecting a change in path from the portal i.e. from portals/1 to portals/2. In your case it sounds like the module is accessing a .net mapped extension such as .aspx in desktopmodules - this is detected as a change of portal. It's easy to fix, all the module has to do is ensure that it passes the portalid as part of the path e.g. desktopmodules/somemodule/somepage.aspx?portalid=1 .

(Note: you might think that we could allow any requests to desktopmodules to not log you out, but in that case a user of one portal might be able to access content of a module that had only been installed for another portal.)

Cathal

John, you're correct, but in cases like this the aspx security is the responsibility of the module not dotnetnuke. When this type of scheme is used in core modules, such as createthumbnail.aspx (to create image thumbnails), during the security audits I check that the module retrieves the userid to ensure that the user has correct rights (and also other checks such as valid extensions, file sizes, portal space requirements etc.). In general I discourage additional endpoints such as aspx, as additional endpoints often offer additional attack vectors and as they do not live under dotnetnuke's security model as effectively they are often easier to exploit i.e. a hacker can try site.com/desktopmodules/somepage.aspx but can't invoke site.com/desktopmodules/somepage.ascx directly, without having module access.

Cathal