0

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.

Update:

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.

Improve this question
4
  • It should work as expected. Have you seen any issues or errors?
    – Amal Hashim
    May 15, 2015 at 14:03
  • @Amal Hashim: It authenticates the user as the old domain1\myUser instead of the new claims user i:0#.w|domain1\myUser that I would like.
    – Maria Ioannidou
    May 15, 2015 at 14:05
  • Is something broken? I don't recall ever having to do any sort of claims mapping or anything like that in SPServices.
    – Eric Alexander
    May 15, 2015 at 15:43
  • @EricAlexander: As mentioned in my previous comment, the fact that authenticates the user as the old domain1\myUser dms user profile instead of the new claims user i:0#.w|domain1\myUser actually 'breaks' the functionality, as the claims user profile is the one that I would like to use.
    – Maria Ioannidou
    May 18, 2015 at 8:52

1 Answer 1

Reset to default
0

I managed to overcome the problem with the current checked out user check 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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.