This project has moved and is read-only. For the latest updates, please go here.

Problems in SPServices functions and Claims based authentication

May 15, 2015 at 12:51 PM
Edited May 15, 2015 at 2:50 PM

I am new to Sharepoint and SPServices and I would like to ask whether it is possible to achieve the following:

I have a web application using SPServices to communicate with a SP 2010 site that has been upgraded to SP 2013. Both my application server and the SP server reside in the same domain, let's call it domain1.

Until now, the SP 2010 worked with basic Windows authentication and everything worked OK with the SPServices from my website. I did not specify any authentication in the SPServices, current Windows user credentials were used for the connection with the SP site. Let's call the windows login user: domain1\myUser

Now, the SP 2013 site uses Claims based authentication and I can see that there are 2 users in SP now, one is the old domain1\myUser and the other is the claims user i:0#.w|domain1\myUser.

Is it possible to still have the user connect to windows using the same login domain1\myUser but have SPServices authenticate the user as i:0#.w|domain1\myUser instead of the old one?

I can provide more details/clarifications if needed.

Thank you in advance,
May 18, 2015 at 3:15 PM

It's a little hard to know what the absolute answer is here. In general, if you are working as an end user, the authentication layer just works; no work involved. However, it sounds like you are sunning a Web app somewhere else, and trying to force a login from that external app. At this point, you should be looking at the new App Model for your external authentication.

May 19, 2015 at 12:46 PM

Thank you for the answer.

To be more specific, my actual problem is the following:

In my SP 2013 I have 2 user profiles for the same user, the windows user profile and the claims user profile, which have different SP ids.

SP services functions are using the windows logged in user profile like domain1\myUser. However, when for example I checkout a document item, the item's checkout user id attribute is equal to the equivalent claim's user id and not the windows user id.

In order to check whether an item is checked out to current user (to allow editing, checkin, etc) I used to check the current SP services user id with the item's checkout user id. And based on the above, after installing the claims based authentication, this check fails now.

I managed to overcome this problem with the following workaround:
First, I'm getting the id of the equivalent claims user (user.claimsId), using GetUserInfo function with userLoginName: "i:0#.w|" + user.login
And then, I'm checking whether a document item's checkout user id is equal to the user.claimsId.

Except from this case, as you have mentioned, the authentication layer seems to just work. I'm still facing some "access denied" issues with the GetVersions function for version history, but I have to further investigate it.
May 19, 2015 at 4:04 PM
It sounds like something in your upgrade didn't go correctly, because you should have only one account per user. I'd go back upstream to that and figure out how to fix it.

May 25, 2015 at 1:36 PM

Thank you for that. Although I do not have access to the Sharepoint configuration but only to this client application, I will inform the SP team to check it out.