Check Permissions throws exception (SharePoint 2010)

I am working on a claims provider module for SharePoint 2010. I completed almost all the functionality, and now it was time to test the provider using the UI. It passed all the tests except one. When I try to check permissions for a secruity group, I was getting an exception, and SharePoint was displaying the default exception window. At first; I thought it was my code; and I debugged the code, and did not see any problem with the code. Then I decided to do the thing that I was supposed to do first; check SharePoint logs with ULSViewer. When I check the logs, the error message was:
System.InvalidOperationException: Operation is not valid due to the current state of the object. at Microsoft.SharePoint.SPUserToken.GetClaimsUserLoginName()
It was obvious that this could not be my code, as I don't call GetClaimsForUserLoginName, so I decided to google this error message; and bumm first hit was to MSDN. I installed this patch, and it fixed my problem. I wonder how did this bug not catch before SharePoint 2010 release? It is one of the very core functionality for a provider (check permission).


E-mail | Permalink | Trackback | Post RSSRSS comment feed 0 Responses


Infinite loop between STS and SharePoint

    If you setup SharePoint to use a STS for authentication, you may have an infinite loop problem like I did :) Here was my scenario:

I have a custom STS, and I setup a trust relation between this STS and SharePoint. When I try to login to a site, as expected, the browser is forwarded to STS login page. I typed in my username and password, then browser started redirection to SharePoint and then again back to STS. This was an infinite loop, and it was weird that Internet Explorer does not complain when there is an infinite loop.

Anyway, when I googled this situation, first link was: Setting the Login Token Expiration Correctly for SharePoint 2010 SAML Claims Users. I applied the suggestions which basically were changing the default timeouts. However this did not fix the problem.

I started thinking about the scenarios that could cause this problem. I know from the logs that STS login worked perfectly ok, and it created claims, and sent it to SharePoint. SharePoint was probably refusing the claims, and sending the user back to STS, STS was redirecting to SharePoint again (as there was a session cookie after then authentication) … The problem was when I was setting up the claims, I had a typo, and SharePoint was expecting another claim from STS, and hence causing the infinite loop.

I fixed the claim typo problem, and tried it again, nope again infinite loop. with the help of my one of my colleagues, we found the problem. When I click the site from IIS manager (click browse link next to the site), IIS is using localhost address, and this was causing the infinite loop. However when I type in the real address (not the localhost one), everything was working as expected :)


E-mail | Permalink | Trackback | Post RSSRSS comment feed 1 Responses