Trying to build a Sharepoint 2013 app has probably been the worst experience of my coding life so far.
The Microsoft docs make it sound so easy; there are so many ways you can build an app! You can use any programming language you like! Look, we have a REST interface! Look, mobile app APIs!
Hey awesome, you think, looking through the initial introductory documentation, yeh all the different information is a bit confusing, but look, they have how tos and the APIs are documented properly, how hard could it be?
Well, after wasting A LOT of time following guides and trying to build solutions that work, here’s some information that happened to be crucial to the architectural decision making of the apps that I didn’t come across until much too late. Probably it’s wrong, because I’m finding it extremely difficult to get actual facts about the different ways you can build sharepoint apps, despite the millions of confusing articles on the Microsoft site (none of which seem to contain all the information you need to know), and lots of tutorials (written only by people coding in ASP hosting their sites on Azure or using OAuth).
Provider-hosted apps using the REST API:
- Using OAuth requires an account with Azure AD and you also need to configure your Sharepoint installation to use Azure AD (and obviously the Sharepoint installation needs access through firewalls etc to communicate to Azure AD). In addition, the app needs to be registered in Azure.
- I’ve seen some tutorials that say for testing you just need to register the app in SP and not Azure, and that you don’t need the Azure AD in this case; I couldn’t get this to work.
Provider-hosted apps using high trust:
- The how-to guides all use a couple of Microsoft provided C# files for the authentication, in addition to Windows Authentication for the site in IIS, and I can’t see any documentation on how the process actually works. Reading through the files, they get the Windows user information, so I have a feeling this method can only be used for apps built (1) in ASP/C# running on a windows machine, and (2) in the same domain as the sharepoint installation.
So if you want to build an app that can modify sharepoint data in any non-Microsoft language, and host it on a non-Windows machine, and don’t want to pay for an Azure subscription, and don’t want to change the authentication method of your sharepoint site, your options are:
- A high trust app to act as a proxy between your app and the sharepoint installation*
*I’m still trying to figure out how it would be possible to send the REST request I want to make to sharepoint to the proxy instead, and have that sign it and forward it on to sharepoint…