There is a forum application (YetAnotherForum) that is integrated with SharePoint and allows posting (and other things) for authenticated users in SharePoint.
- It has a customized membership provider that checks that SPContext.Current.Web.User and adds it to internal SQL storage and gives default permissions.
- Forum application is configured as an Application in specific sharepoint IIS site (membership, role and profile providers).
- SharePoint site and application use the same application pool
It works well when only Windows auth is enabled in Forum Application - users always identified correctly.
If anonymous auth is also enabled (together with Windows), it works fine for several minutes, then the SPContext.Current.Web.User is null. And forum considers user to be anonymous.
It works the same for all browsers, but FF and Chrome can recreate auth after one page view for anonymous. For example, user browse ok, then see access denied then browse ok a number of minutes.
For ie 9 - works fine, for ie 8 can restore auth for several requests and drop it again.
Current research status:
- For ie - disable Integrated Windows Authentication - works well in ie, but requires end users to do this on their machines and not solve issues with other browser, just major part
- http://geekswithblogs.net/mskoolaid/archive/2005/12/04/62164.aspx - this article seems to have a solution but is not available now
Known solutions (hacks)
I can create a httphandler or a web service, that will be placed on a normal site (_layouts), that will give me a correct user name or empty (if anonymous) using SPContext.Current.Web.CurrentUser, cause it works well on main site. Thus seems that the issue is in membership provider (change from SP to custom). But it'll give an additional call in each request and is very hackable.
If you know anything that can help in resolving the issue - please let me know.