s-KaiNet/gulp-spsave

spsave: Direct login to WLID is not allowed for this federated namespace

williamwmy opened this issue ยท 9 comments

Hi,
I got the following error when trying to save the file.

spsave: Direct login to WLID is not allowed for this federated namespace

This is on SharePoint online.

It looks like you are using credentials for the user from active directory. This type of credentials won't work with spsave. As a workaround you can specify Office 365 user credentials.

This is related to s-KaiNet/spsave#16

Unfortunately it is usually not developer's call to decide which authentication mechanism to use...

Thanks for the replies, in my case, unfortunately, It's not an option to switch authentication.

It's not an option to switch authentication

This is not clear for me, sorry, may be I'm not good at cloud authentication scenarios. From my POV, when you setup federated authentication for Office 365 (you configure ADFS, setup AD Sync, configure trust, etc.) you can use your Acitve Directory user to login to Office 365. But you don't need to switch authentication, it's just another authentication option for your users. You can be logged with active directory user or with Office 365 user. When you type in active directory user into the login textbox, you redirected to your ADFS server, when type in Office 365 user (they name it "Work or school account") you get redirected to MS Online sign in experience.
So what you need to do is to create (or use existing) work or school account for spsave.
That's my POV and may be that's mistaken. Could you guys explain your case in more details, so I can get an idea how to move forward? For example why do you need to "switch" authentication, which authentication you are using right now (I guess federated through the ADFS?) and other information you think will be helpful.

Meanwhile I can recommend you to use alternative gulp plugins such as gulp-spsync which uses slightly different approach to establish authentication and works for online.

@s-KaiNet Sorry for the confusion. In my case, I don't believe I have the option to log in as "Office 365" user (something like lifan@mycompany.onmicrosoft.com?) I can only log in using my company email address (lifan@mycompany.com), which redirects me to my company ADFS where spsave failed to work.

I don't believe I have the option to log in as "Office 365" user (something like lifan@mycompany.onmicrosoft.com?)

If the user doesn't exist, you definitely don't have an option to log in. But you have an option to create a user (or ask somebody with permissions to create) inside Office 365 (not in your AD). This user will be considered as "work or school" user and will have login name similar to your example - [name]@[company].onmicrosoft.com. This user will use MS sign in experience and will work with spsave (don't forget to add permissions to the site for this user).
I think this is the only option I can propose you and @unwiLL right now. I strongly believe it is possible to implement ADFS authentication in nodejs in order to add support for federated scenario, but currently I'm absolutely don't have time for that. I will try to take a look into possible solutions may be by the end of the month.

@s-KaiNet Thank you for your suggestions and for this great tool.

I did some investigation around ADFS and didn't find appropriate solution. As a workaround I'm going to implement SharePoint addin app only authentication with server 2 server trust (exactly like SharePoint high trust apps do in TokenHelper.cs, but in nodejs).
Refer to this comment for details.

Good news, I found a way to add support for ADFS, please see this comment.
I'm closing current issue and proposing to track corresponding issue in sp-request module (you can click Subscribe button in the right if you want to receive notification updates for issue inside sp-request repository).