on premise user credentials only works for 1 API call

[patrickjane]

I have implemented the SP authentication as advised in your wiki (https://github.com/s-KaiNet/node-sp-auth/wiki/SharePoint-on-premise-user-credentials-authentication), and the login procedure as well as a following folder listing works well.

However, as soon as the first API call was made, no more API calls can be made and will be rejected with HTTP 401.

Example code to reproduce:

    spauth.getAuth('https://[ROOTURL]', { username: 'xxx', password: 'xxx', domain: 'xxx' })
    .then(options => {
            options.headers['Accept'] = 'application/json;odata=verbose';

            let httpOptions = {
                    url: "https://[ROOTURL]/_api/web/GetFolderByServerRelativeUrl('/sites/my/site/folder')/?$expand=Folders,Files",
                    method: 'GET',
                    headers: options.headers,
                    encoding: 'utf8',
                    rejectUnauthorized: false,
                    agent: options.options.agent
            };

            request(httpOptions,(err, res, body) => {
               console.log(res.statusCode);                 // prints 200

               request(httpOptions,(err, res, body) => {
                    console.log(res.statusCode);            // prints 401

               });
            });
    })
    .catch((err) => {
            console.error( 'Failed to connect to sharepoint (' + err + ')');
    });

[s-KaiNet]

Hi,

I recommend you to try sp-request module. It handles everything inside and uses node-sp-auth under the hood.

[patrickjane]

Hi,

thanks for your response. I can confirm it works when using your sp-request module. However, there are some issues I am having in my particular case:

• I will need to download larger files from sharepoint, thus I was using the stream interface of the request module, so I can avoid loading large files into memory. It seems like sp-request does not offer this kind of functionality?
• With issue Option to set the local network interface #47 you introduced the setup option which allows to add settings for the request module (in my case I needed the localAddress option). This feature does not seem to exist in the sp-request module

In addition, I think I found a bug in issue #47's implementation. On our companies sharepoint, everything works when I call the setup() function with localAddress option. However, on the customers sharepoint instance, calling the function will result in all API calls return 401. When I comment out the setup function call, the (first) API call on customer sharepoint instance will be okay with 200.

Our companies sharepoint instance is sharepoint online (user+pw authentication), the customer's sharepoint is on-premise/user/pw (so the setup feature seems to have issues with sharepoint on-premise authentication).
Should I create a separate issue for this?

[s-KaiNet]

• I will need to download larger files from sharepoint, thus I was using the stream interface of the request module, so I can avoid loading large files into memory. It seems like sp-request does not offer this kind of functionality?

Nope, sp-request doesn't offer streaming functionality.

• With issue Option to set the local network interface #47 you introduced the setup option which allows to add settings for the request module (in my case I needed the localAddress option). This feature does not seem to exist in the sp-request module

That's true, I will think about how to introduce it in sp-request.

Should I create a separate issue for this?

Yes, please.

[koltyakov]

My 2 cents on the topic if you don't mind.

sp-request uses request-promise a nice lib, but... The downside of the promise's implementation that it does not support streams as Sergei mentioned.

On one of the projects, I got to implement files download using request lib with streams support and node-sp-auth of course. Maybe it will be helpful - https://github.com/koltyakov/sp-download/blob/master/src/api/Download.ts#L77, to reuse the lib or just "steal" the implementation part.

Yet, I've never experienced the issue with network interfaces @patrickjane described before.

[patrickjane]

Well, I have an existing implementation which uses the request module itself & streams, and it can download files from sharepoint just fine. I have been using node-sp-auth for the authentication stuff so far, however, as mentioned in the initial post, it turned out that only 1 API call is possible when using on-premise user/pw authentication.

Of course, one alternative would be to do the authentication step via node-sp-auth before each API call, however @s-KaiNet suggested to use sp-request instead.

Yet, I've never experienced the issue with network interfaces @patrickjane described before.

What do you mean exactly? Are you using the localAddress option via setup({ requestOptions:..}) together with on-premise user/pw authentication, and it works for you?

[koltyakov]

What do you mean exactly?

I just meant that on a variety of machines and different auth strategies have never faces the issue and the necessity of providing localAddress at all. That’s why wasn’t sure that sp-download suits you for that reasons.

[patrickjane]

I just meant that on a variety of machines and different auth strategies have never faces the issue and the necessity of providing localAddress at all. That’s why wasn’t sure that sp-download suits you for that reasons.

Well, if you're having multiple network interfaces, on linux the interface to be used is determined by several factors, and you might end up on an interface which does not have a connection to the IP you're trying to connect. This can also change over time, so it works when initially deploying your software, but stops to work after a while when network configuration changes.

This is why you're usually using the bind function in linux network programming, and all network-related libraries should support this feature, otherwise you cannot be 100% safe.

On the hosts of our customers, there is always multiple network interfaces, and routing/firewall setups which are out of our scope/control, so we are bound ( :D ) to use the bind function in all of our software.

Maybe for the time beeing, I will try to use node-sp-auth and request, and fire the authentication right before each API call, although this is pretty much a big overhead.

[koltyakov]

To be honest, to little Linux experience on my end. Thank you for detailed case description.

Btw, node-sp-auth caches the data, so even a number of sequential runs should end up with a “single” phisical auth request until the cache is expired.

[patrickjane]

Btw, node-sp-auth caches the data, so even a number of sequential runs should end up with a “single” phisical auth request until the cache is expired.

Thats good to know, so this is going to be the best solution for our case.

BTW the other issue I was having (API calls fail if I use setup method with { requestOptions: { localAddress: 'xxx' }} could be resolved.
I don't fully understand why this was happening, but it worked as soon as I also gave the parameter to the request module when doing the HTTP call via options. If you only supply either of them, the API call will fail with 401.

Of course, from what I wrote earlier, it perfectly makes sense to supply the bind parameter in both cases, otherwise you could end up with one of both calls unable to reach its remote host, however I don't understand how it can make a REST API call fail (but network-wise work perfectly).

Just wanted to leave this here, in case anyone else comes across this, or someone wants to take a further look. Of course its not an issue anymore.

[patrickjane]

By the way, if node-sp-auth caches the authentication, what is the technical reason I still have to re-apply the authentication for each API call? Is it not possible for getAuth to return something which is valid for more than one API call?

[azamsolix]

Hi,
I am also facing with same issue unable to call more than one api.Could you please help me with this @s-KaiNet