The Future of Client Side Development in SharePoint and Office 365
So on the one hand we have an admittedly less-than-ideal client solution model in SharePoint Hosted Apps but an incredibly robust set of web, mobile and even enterprise applications that use the same fundamental framework. Microsoft has made it clear that their preferred route is legacy .NET applications running on IIS outside of the SharePoint framework entirely, which makes sense considering the company wants to sell as many Windows server licenses as they possibly can. But is that approach realistic in light of the fact that the entire web is moving in the opposite direction? Are we once again going to be put in a position where SharePoint is years behind every other technology on the market (remember having to suffer through .NET 2.0 when 3.5 was already in widespread use everywhere else)? And just what is it that so many people, including those within Microsoft, seem to have against pure client-side applications?
I’ve collected a few of the most common complaints I hear when speaking to developers about the App/Add-In model. Naturally, most of them come from existing SharePoint and .NET developers, who have a vested interest in the status quo of compiled server-side code, but I’ve even heard a few from so-called “architects”, IT professionals, system administrators, and developers transitioning from other platforms. These are my thoughts on the subject, which will most likely generate some controversy, so feel free to add your own perspective in the comments and tell me why you think I’m right, wrong, or missing the point entirely.
SharePoint Hosted Apps Aren’t Secure
Complaints regarding app security are really complaints about OAuth, which replaces the tried-and-true method of every app having distinct authentication with a token-based authorization scheme designed to operate – sacre bleu! – over HTTP. Is this scheme inherently secure? Of course not! It’s susceptible to all kinds of attack vectors, from Man in the Middle, to Session Fixation, Covert Redirects and more. All those tokens flying around are just begging to be hijacked and exploited.
But guess what? None of that makes any difference. All – and I do mean ALL – of the major web players have embraced OAuth as the de facto standard for interoperability. So it doesn’t really matter that it’s inherently insecure or susceptible to exploits because everyone is using it and will continue to use it until something else comes along. For years Microsoft has forged their own path in the web standards world, going it alone even when they were sometimes in the right, and they’ve been marginalized in the greater web development community for it. They have now, wisely, chosen to change their ways and go along with what everyone else is doing. That means if you’ve written apps that integrate with Facebook or Twitter you know pretty much all you need to know to write Office 365 and SharePoint apps. That’s a win for Microsoft no matter how you look at it.
One thing the detractors of SHA’s often forget is that from the customer’s perspective an SHA is actually MORE secure because it runs inside of their SharePoint environment (or Microsoft’s, in the case of Office 365) and they don’t have to worry about a third-party vendor’s servers being compromised. Is this more perception than reality? Certainly. But that doesn’t change the fact that each add-in the customer installs increases their risk profile because it explicitly allows a third-party access to sensitive company data. But don’t take my word for it – sit down with a Chief Information Security Officer and tell them you are going to permit vendors to copy company data to their servers with the only barrier being a single “Trust It” button clicked by a site administrator and see what they say (it’s worth it just to watch their face turn purple). Just because an app vendor tells you they aren’t copying your data who is to say that’s the truth? Every PHA that runs on a server not owned by the company is acting with full permissions on behalf of the user or as agreed upon by the site admin; you may think all is well because your users are happily clicking away on that fancy CRM add-in but behind the scenes it’s downloading every document in every library in the site and storing it away on somebody else’s servers. And you’ll never know it’s happening because it’s all being done outside your firewall; even worse, you blindly accepted a set of generic permission statements so you gave the vendor permission to do it! Could this also happen in an SHA? Potentially, yes, but the data can’t be stored in the SHA itself so the perceived risk is much lower (the app could, of course, just upload the data to a remote endpoint from the client). Remember, there is no cloud – it’s just somebody else’s computer and one little click can give them the keys to your kingdom.
The App Web Concept is Terrible
On this one we can all agree. App webs ARE terrible. They make lifecycle management a nightmare because developers cannot predict the URL of each app across farms or even across multiple deployments in the same farm. Users don’t understand them because they kind of look like a regular site but they really aren’t. A nonsensical proxy method is required just to communicate with the host web, which is where we all want to provision assets in the first place. And configuration makes IT Pros gnash their teeth dealing with wildcard certificates and DNS. They really, really suck. And don’t get me started on app parts because those are even worse. But that’s what we have to work with so until the situation changes there’s no point in getting all worked up over it.
It’s no secret that a lot of people, including many within Microsoft, would like to see the app web concept – and SHA’s along with it – go the way of Sandbox Solutions (which, when you really think about, is all the app web concept really is: Sandbox 2.0). There’s a reason nearly every sample in the Office Dev PnP GitHub repo is a PHA even though most of them don’t require any PHA-only features like remote event receivers; however, PHA’s also require an app web if they want to communicate with the host web in any way so this problem isn’t applicable only to SHA’s. I’ll agree with half of the sentiment, that app webs do need to go away. Like, right now. Today. But just scrapping them altogether doesn’t actually solve any problems. In many (actually, most) enterprises it is very difficult to get a web server provisioned. It requires numerous approvals, business justifications, allocation of scarce resources, etc. And before you say it, no, Azure is NOT the answer. Business units and IT shops can not increase costs from a usage-based resource any easier than they can spin up a new virtual machine. Just because an EA has Azure on it doesn’t magically transform compute units into freely available (or free) resources. Those costs have to be justified and applied to a cost-center; they are coming out of somebody’s budget somewhere and whomever holds the purse strings has to approve the spend. Besides, the customer bought SharePoint in the first place so they wouldn’t have these kinds of problems. Force them into spinning up a bunch of web servers alongside it and they’ll just go back to Full Trust Solutions. Guaranteed.
SharePoint Hosted Apps Don’t Support Forms Based Authentication
Very true. SHA’s and FBA don’t play nice together. But, when you stop and think about it, PHA’s don’t actually support FBA, either. You can create a PHA that uses FBA but it’s not the same credential that’s coming from SharePoint. There is no true single sign-on for apps unless you are building Azure web applications. So even if the user can login to SharePoint via FBA they still have to log into your app separately. Which doesn’t actually achieve anything since OAuth is required to communicate back to SharePoint. So the reality is that apps don’t support FBA period. The only difference is one of perception – the user thinks FBA works because they log into SharePoint once and get redirected to a PHA that uses OAuth behind the scenes to establish context. An SHA, because it runs on a separate web application, hits them with another login prompt so it appears not to work with FBA. But apply forms auth to the PHA and the user gets the same result. What is really needed is for Microsoft to fix the FBA problem altogether instead of developers fooling users into thinking something works when it really doesn’t.
I’m sure there are other arguments that people can raise against SharePoint Hosted Apps but those are the ones I hear most often. Now let’s move on to some of the positives, shall we?
Ease of Deployment
There is no denying the reality that SHA’s are so much easier to deploy than PHA’s, especially on-premise. Add the app, trust it, and you’re done. No certificate issues (well, no additional certificate issues, anyhow). No Client ID’s, Secrets and hidden expiration events. No PowerShell scripts with arcane TrustedSecurityTokenIssuer commands. No vendor servers and uncomfortable conversations with InfoSec. And despite the fact that they run inside of SharePoint, no WSP’s or IISRESET operations.
It. Just. Works.
Most importantly, SHA’s don’t require any additional infrastructure. There is no need to request a new web server or justify additional cloud compute expenditures. They run where SharePoint stuff should run – in SharePoint (what a concept!). You can leave your resources free for those apps that actually need their own servers and which shouldn’t ever have been deployed to SharePoint in the first place. And you never need to have this ridiculous conversation:
DEVELOPER: “We need to deploy a solution for SharePoint branding.”
IT MANAGER: “Ok. Schedule a maintenance window and do it.”
DEVELOPER: “Um, we need to provision a web server for our solution.”
IT MANAGER: “What? Why? Can’t you just deploy the WSP via PowerShell?”
DEVELOPER: “Well, Microsoft says we shouldn’t do that anymore and instead we should be building provider hosted apps now which don’t run in SharePoint. So we need a separate web server.”
IT MANAGER: “Let me get this straight. You need to stand up a web site in order to apply branding to another web site?”
IT MANAGER: “Come back to me when you have a WSP.”
Modern App Development
Even better, the code you write for your SharePoint add-in can be virtually the same as what you write for that fancy mobile app that’s going to take the world by storm one of these days (as soon as you get around to writing it, of course). Have an existing mobile app that is mostly an HTML + JS front end that talks to a set of distributed web services (perhaps even running Azure)? Put it on a web server, code up a quick App solution and it runs with minimal modification as an App Part in an Office 365 site. Boom! Mic drop.
Availability of Resources
For companies trying to manage an ever-shrinking IT personnel budget (which is pretty much every organization on the planet) this is a huge boon. For years the biggest complaint about SharePoint development has been the inability to find people who actually know what they are doing. With apps, especially SHA’s, that’s no longer such a huge concern. Sure, you still need some quality SharePoint devs to lead the charge but you can now pair them up with web and mobile devs and watch the semi-colons fly about in a swarm of productivity.
Does this mean, as is often claimed, that Full Trust solutions are dead? Heavens no. Not by a long shot. On-premise SharePoint development still requires proper compiled solutions for implementing serious customizations. There just isn’t any real replacement for timer jobs, feature receivers, web parts and web templates in a real-world SharePoint deployment. But apps give you options, like not having to completely rewrite a web application as a set of application pages and web parts. Instead, that web app can continue to stand alone but gain some nice hooks into the company’s Intranet, such as remote data integration and ribbon integration.
So what’s the takeaway from all this? From this developer’s perspective, client-side SharePoint Hosted Apps play a vitally important role in SharePoint and Office 365 extensibility. They are modern, easy to deploy, require less infrastructure and fewer scarce personnel resources. Are they perfect? Nope, there are important security concerns and the product engineering team really needs to come up with a better solution for hosting them than the app web concept and find a way to implement PHA-only features like remote event receivers. But in my opinion the advantages (or potential advantages) outweigh the drawbacks. The deployment story alone is enough to proclaim them superior to Provider Hosted Apps for on-premise and hybrid environments in my opinion. I’m sure many people will disagree with me on this but if you find yourself coming down on my side of the argument then you need to make your voice heard to the powers that be inside Microsoft lest they really do become the next version of the Sandbox and suffer a similar fate.