SharePoint Apps – the dark side

Posted on 10/16/2012 @ 2:37 AM in #SharePoint by | Feedback | 2657 views

First of all, I am a proponent of SharePoint apps. As I have said many times over, SharePoint Apps make me very ‘appy, they are very app-propriate. But there are some points to consider that make a bit app-rehensive.

These are all mentioned in my book “SharePoint 2013 - Planet of the Apps”,

.. but here are some thoughts of the negatives of Apps that I think we need to consider before diving in,

Mutliple Servers, More Complexity

Apps, by definition will include an extra server. This excludes SharePoint-hosted apps of course. Extra servers by definition will add more complexity. As it is, when you introduce SharePoint to an organization, the number of servers multiply like bunnies. Now you will have additional servers, and these servers talking with each other. You will have to maintain trusts, and you will have to patch more stuff, reset more “admin” passwords – you get my point. Additionally, the cross-domain authentication isn’t exactly simple. Basically, just like Kerberos, this cross-domain auth is like a little bird. It’s pretty cute until it shits on your head.

Simpler tasks are easier to do in Sandbox solutions

Well first the good news, if you had written sandbox solutions in SP2010, your upgrade to SharePoint apps is going to be quite boring – which I like. In SP2013 however, there are some scenarios that are just easier to do in sandbox solutions, provisioning content types, branding artifacts, adding a list etc. You could do them in an app, but it’s just more straightforward to do them in a sandbox solution. Now since Microsoft is pushing us to use apps heavily, well, I sorta miss being able to do simple stuff in sandbox solutions. I’m frankly not very sure what the future of sandbox solutions is – on one hand Microsoft says they are deprecated, on the other hand, they still offer some value. I guess I’ll just stick with apps and bit the complexity.

JavaScript can no longer be considered 100% secure

Well here is another big consideration – for the longest time we have considered JavaScript to be a secure platform because it runs inside a sandbox – that is your browser. Well, no longer buddy. Yes it won’t hurt your machine, or your SharePoint server. But it could steal your data given that you have provided OAuth based permissions to let it do so. SharePoint apps do not let you specify access at a specific list or specific web level. Which means, if you can write to my “Announcements” list – you can also write to my all other lists. Ouch! Additionally, OAuth access to other applications is hijackable. Lets say your App OAuths you into your bank account – a sandbox solution in the parent page can potentially hijack your identity and do stuff on your behalf – without asking you for it. Plus, clickjacking is just too easy for me to get a good comfy feel around this. Not that there aren’t solutions to this, but it will require more thought from developers. Developers who are always under the gun to produce functionality because their customers do not understand the value of doing good homework and ensuring good security and architecture ahead of time, because it costs more.

Security of provider based apps is questionable

Whoaaa! WTF! Blasphemy, how dare I say “questionable”. Well, imagine that you install a provider hosted app. Now, you give it “Manage” rights. Life is all hunky dory because your app does a certain task and it does it quite well. So you give it manage rights .. sure! But, at a later date, nothing prevents the app provider from changing the server side implementation of his app and do stuff that you didn’t think they were doing. Ouch! This does not apply to azure autohosted apps, or SharePoint hosted apps, but still a concern.

UI Challenges

Allright, I’ll say it. SP2013 is UI challenged in many ways. No breadcrumbs? And that MDM strategy means frequently where business users are used to seeing a spinner spin in your browser’s TAB – well that no longer gives any feedback. Sometimes it says “Working on it” but sometimes it doesn’t. Add apps to it, and you have something that runs in a completely different context and doesn’t really blend well into the UI. The chrome control, I am sorry, doesn’t go far enough – especially when it comes to navigation. I think most app developers will end up reinventing the wheel in many different ways when it comes to common UI challenges – Microsoft, give us more guidance/tools on this please before letting the horse out of the gate.

SSL certs

Apps will require you to provision new domains on the fly – this is done by some clever DNS settings so there are no manual steps involved. However, you must use HTTPS for apps to be considered ‘secure’. I cannot in good faith recommend apps without SSL, anyone can sniff your access token and do whatever the hell they please under your identity for up to 1 hour. Way too insecure – but with HTTPS is absolutely fine. OAUTH2 requires HTTPS BTW, it is not considered OAUTH2 unless you use HTTPS. The issue of course is, your company will have to buy a wildcard SSL cert, which costs mucho bucks. One alternative I recommend for intranet scenarios is to provision your own certificate server – not a solution for extranets or internet facing sites though. You could go around creating provider hosted apps, with a hardcoded launch URL though, but you lose some flexibility there.

SEO Concerns

Apps will launch either via complex javascript (usually), or run in a separate IFRAME, also called as the SEO walled garden. This basically means that if you use a discussion forum app on your internet facing site – you basically lose all the link-followage that dumb search robots use.

On-Premises and Office365 have some differences

Well, as of today, SP2013 On-Prem vs. Office 365 have some differences. I think these differences will continue to increase. This means, you can’t in many cases, just write an app and use on both. There will be workarounds etc. but something for you to consider.

Okay, I gotta run and catch a plane now, for more practical stuff like this, see my book “SharePoint 2013 - Planet of the Apps”,

Sound off but keep it civil:

Older comments..

On 10/16/2012 3:57:08 AM James said ..
"your company will have to buy a wildcard SSL cert, which costs mucho bucks" - this is peanuts... it's few hundreds in year compared to standard consulting hourly fees which range from 150 to 300$ for an hour... so for the price of few hours of having consultant drinking coffe in your office, you'll get the this done...

So - it's definately not mucho bucks in anyway we look at this.

On 10/16/2012 5:27:25 AM Sahil Malik said ..
James - fair point. But I think we are spoilt when we think of SharePoint. One of the primary markets Microsoft (I think) would like to hit with SP2013 are the mom & pop shops. They will use Office 365, and an additional 1000 bucks for 1-2 years is going to pinch a bit. Not crazy, but still.

On 10/16/2012 1:10:24 PM Ajay Sawant said ..
Thanks for the post Sahil, Here is what I believe is one more dark side of using the SharePoint App Model.

In 2010 in case of Farm or Sandbox solution design I had a liberty to separate my SharePoint artifacts into the the different set of solution packages. For example I bundle the Content Types and Site Columns into one WSP and Style components like Master Page, Page Layouts and XSLTs are maintained into the another WSP and one more for Web Parts. This helps me to deploy only specific WSP in case of any changes... but this is not the case with SharePoint apps. I am bound to bundle all this in one single app. Because of this in case of app update I am forced to deploy all these changes even though I don't want to update them.

On 10/17/2012 7:13:35 PM Natesan said ..
I always like sandbox solutions but really confused or puzzled to read they are deprecated. Any pointers on that please? App-roximately apps are the way onwards!

By the way awesome expressions, app-lause :D


On 10/18/2012 7:42:51 AM Sahil Malik said ..
Hey Natesan,

There was some basic architectural issues with Sandbox solutions.

They were quite limited in what they could do - but I suspect that issue was work-around-able with the oAuth investments they have done. But still seperating stuff into it's own URL makes it more secure.

The biggest unsolved/unsolvable issue was the basic underlying architecture I think. The WCF based round robin balancer is not the choice for a code-sandbox. It's too chatty, doesn't clean up properly after it, and you will eventually run into situations where the sandboxed service becomes unavailable. Not that these issues are completely unsolvable, but when you've gone down a wrong path to begin with, it's easier to just wipe clean and start over - which is what they did.

I see some such issues in apps as well, but I do feel that a major portion of our development will shift to apps.


On 10/22/2012 3:34:18 AM N & M said ..
Ah, we're not the only ones with doubts: It just seems Apps will be a good idea at the end, but if version 1.0 will be ok?