Thank you Archilea, Please keep the reports coming in, I'd like to nail this problem for sure. At present I have enough evidence to suggest 2 main issues.

1. Some of the people are getting logged out as their 3rd party modules reference aspx pages, and don't provide either a portalID or tabid, so the portal can't be resolved. As aspx pages are a .net mapping, they pass through the http module layer and get logged out. This is the case for both the counter module, and an articles module.

2. some users reported that it failed in IE, but not in firefox. I've tracked most of these to requests for webresource.axd requests (which supplies the asp.net 2.0 javascript files), which fails for the same reason as above. I'm fairly sure that most of these users are running with debug=true (please check), which forces the javascript to be emitted each time validators etc. are referenced (ref: scott guthrie's post ). As .net mostly thinks that any non-IE browser (such as firefox) is a down-level client it doesn't emit clientside script, avoiding the request that causes the issue.

To fix this, after authentication to a portal, I'm going to add the portalID to a cookie. In cases where we can't establish the portal, we'll use this as the fallback value, to prevent unwanted logouts. I'll extend the logout code to expire this cookie as well. Hopefully this will fix the issues, without requiring users to get updated versions of 3rd party modules that aren't passing the necessary details for .net page requests.

Cathal