*quick update*

I've opened this as an issue http://support.dotnetnuke.com/Default.aspx?p=2&i=3013 . The logout problem is caused when a request to an extension mapped to the asp.net is made. If this request does not have a portalID or tabID (from which portalID can be derived), then a portalID of 0 is assumed (as it's the primary portal - this allow's for wildcard portals). Later on in code, a check is made to see if the current portalID is different from the previous, and if so the cookies are expired, and the new portalID cookies are created. This is how we move between portals and maintain security. The two main causes of unwanted logouts are:

1) requests to asmx (webservices) or axd(either webresource.axd generating javascript for pages with validators, or the freetextbox editor using it's axd to serve resources). The fix for this was trivial and has been added to source, and will be in the next release. This is far and away the most common issue.

2) some 3rd party modules (a hitcounter, and a popular 3rd party articles module were the two that came up a few times), build requests without including portalID and tabID. This means they are not following dotnetnuke standards and requirements (their developers did not test them in a childportal, so may be unaware that they are broken).  Whilst we could ignore this as it's not DNN at fault, I've been trying to add code to detect this, and if there is an existing formsauthentication cookie, read it's portalID, and use it as a fallback, as it's easier (in theory) for us to code the exception in DNN than have you all chase down various module developers. However i'm having problems getting this correct, as I can't step through the code in debug mode because it causes corrupted formsauthentication tickets . I have to put this on hold for now, as I have a few other issues more bugs & enhancements I have to complete for release. I've left the gemini issue open, and hope to return to it and find a fix, but am not sure when I'll get a chance to do this.

Cathal

The actual change ended up taking into account other .net extensions so was actually like the one below (from memory, as i'm in work at present and cant see the code). Llamil, the trace you sent me doesn't correspond to any of the other traces, in line 292, theres a correctly formatted request with a tabid, but in line 293, the portalrolesid cookie has been exprired. As I mentioned in my email to you, I've had reports of unexplainable logouts on brinkster hosting for quite some time, and we've never been able to track it down as it appears to be a host specific issue. I've long suspected that brinkster have their sites in incorrectly configured webfarms, as from hearsay evidence many people have noticed a dramatic change for the better when they added a session("") variable to the top of their default.aspx (a session variable would create session affinity in a webfarm ensuring all requests go to the same machine, and are not passed around multiples in a webfarm [which would cause random logouts]). Sadly, theres little I can do to help with this as I do not have brinkster hosting. You could create a test page that creates a cookie, and then refresh the page a number of times and see if you get logged out at any point.

If Request.Url.LocalPath.ToLower.EndsWith(".aspx")=false Then

Exit Sub

End If