Dependency to NTLM proxy?

[kasperg]

Does PHP-SharePoint-Lists-API depend on having an NTLM proxy such as ntlmaps (or perhaps cntlm?) available?

As far as I can tell the code suggests so

• proxy_port has a default value of 8080
• there seems to be no way to set the proxy_host and proxy_port values (FALSE, NULL etc.) so that a proxy will not be used

If this is intentional do you care to share the reason why?

Thank you in advance!

[thybag]

Hello,

If you need to use NTLM authentication (rather than basic auth), then currently it will do.

I don't actually have access to a SharePoint installation with NTLM set up myself, so all the NTLM features have all been contributed by other developers (I've avoided changing them due to lack of a good way to test them).

The paradigm used by the author of the NTLM component is a little different from what I've used myself, instead making use of inheritance to set the inner variables rather than passing them in to the constructor.

Hopefully this example should clarify it a little: examples/ExampleSharePointAPI.php

[Quix0r]

Hello,

I have written the NTLM-auth component. The constructor in SharePointAPI.php requires two parameters, so I had no other way of calling the parent constructor. If I wouldn't call it, that code needs to be duplicated to everyone's constructor, which is bad coding style.

Better style is to write "generic code" that is far generalized and if you need special code, then write a decorator for this special case. This avoids duplicate code and make everything "compatible" to each other. If your/someone else code has a type-hint on SharePointAPI and your class extends SharePointAPI then it can still be passed to that method requiring the type-hint.

Well, in general terms, better write an interface (additional) and type-hint on that interface instead on the "super class". This can still be done at this point. Just all all public methods (except constructor/destructor) to it.

To come back to kasberg's question: Yes, you need such proxy to run. And you you need to download the WSDL file to a local directory and use that local reference instead the online. I tried it (when I had practicum with a local company) to implement it without ntlmaps but I only got errors. One came when I tried the "online" WSDL reference (via HTTP) and an other error came when I tried not to use no proxies such as ntlmaps.

With ntlmaps, and local WSDL file, the script worked.

Hope this explains it a little.

[kasperg]

Thanks for the explanation @Quix0r.

I would prefer a solution without this dependency so I might attempt a change using one of the stream wrapper based implementations of combining NTLM and SOAP.

I'll look into a pull request if it becomes useful.

[thybag]

@kasperg Having NTLM support baked directly in to the library would be awesome if you can get it working like that :)

@Quix0r "Assuming" getting NTLM working without a proxy is possible, do you think it would be worth keeping the support for the ntlmaps method as well - or just to dropping it in favour of the proposed baked-in solution.

*Sorry, accidentally posted this originally from my work account.

[kasperg]

I have a version using the stream wrapper based approach up and running here: https://github.com/reload/PHP-SharePoint-Lists-API/ if you are interested.

I need to test some more before deeming it ready for a pull request.

[Quix0r]

If you can get rid of ntlmaps usage alltogether I like your version then. :) Please execuse me that I can no longer test it for you as I'm not at the practicum anymore.

[kasperg]

Thank you for the feedback @Quix0r.

This change requires further testing before introducing it into the main branch. I only have access to three Sharepoint environments with very little variation (test, staging and production for a single project) which only supports NTLM authentication but you are more than welcome to give my changes a spin if you have access to any other setups: Without authentication, using basic/digest auth or the like.

[thybag]

Hello @kasperg ,

Just been having a play with your branch locally to try and get up to speed with the changes. It appears I'm unable to authenticate using non-NTLM when the authentication details are passed via SoapAuthClient so I've re-added the $NTLM = true\false switch to enable or disable use of the class over the standard SoapClient.

Was wondering if you could clarify how the changes to the delete/deleteMultiple methods work? Playing with them locally it appears that SharePoint is pretty much ignoring anything other than the ID field itself? (its possible I'm just using it wrong though)

Thanks, Carl

[kasperg]

Thanks for the update @thybag. Contributing our changes back to the library would be great.

The reasoning behind the changes to delete are related to situations where you want to delete file items. In this case it seems like you have to specify the FileRef as well as the ID.

I thought that there might be other situations where you might need to specify such additional fields so instead of just adding a optional $FileRef argument I made it an array of fields instead.

Note that I am by no means a SharePoint export nor user so my terminology might be off.

[thybag]

Ah, thanks for the info - that makes sense :)

I've pushed a more up to date copy to develop which includes your changes (hopefully in a still working state) https://github.com/thybag/PHP-SharePoint-Lists-API/tree/develop

The primary difference is you now need to pass in a 4th parameter to the constructor in order to enable the NTLM auth.

[kasperg]

Great. I will kill our fork an revert our project to using your repo then :).

When working with SharePoint lists and file items in specific we also needed to use the SharePoint Copy web service. The two services seem very related and perhaps it could be useful to integrate that into the project as well at some point to create a consistent PHP interface.

[thybag]

I've not had cause to play with the SharePoint copy web services thus far, but I'd certainly be happy to include support for it if you can get it working :)

[kasperg]

We have it working but we call the service directly through SoapClientAuth - not through an extension of the SharePoint List API. I will have it in mind if we continue this integration.

I will close this issue. The conversation has extended well beyond the original topic.