Kategoriarkiv: Provider Hosted App

Http to Https Redirect in Provider Hosted Apps

It is strongly recommended to use https in SharePoint Provider Hosted Apps. In many provider hosted apps I have seen, only https works. I would recommend to configure a simple http to https redirect in IIS and make solutions better. Many Provider Hosted Apps can be done in that way that they are available without SharePoint Context, e.g. for browsing information. In that case that is important to have an easy url and an automatic http -> https redirect.

In this post I’ll give a short manual for doing that. I would recommend this step for all provider hosted apps.

1. In the Provider Hosted Apps Server install the URL Rewrite IIS Module using Web Platform Installer:


2. Next step is to add the http binding to your solution (this is needed for the future redirect):


Then you can configure the automatic http to https redirect using the GUI or the web.config update. My instructions originally come from JPPInto.com blog.

I suggest updating the web.config file directly in the Provider Hosted App:


3. Add this section to the web.config file:


It is important to know that his web.config section will cause failure on the server if URL Rewrite module is not installed.


These steps are very easy to accomplish and I recommend it for every Provider Hosted App, especially those ones that are accessible without going through SharePoint (Web Content -> Apps). This also reflects the configurations in Azure Apps (WebSites).

How to stop the ItemUpdated-event from refiring itself in an remote event receiver

tl;dr: If you have trouble with stopping the updated-event from firing, compare what you want to change in the beforeProperties and afterProperties. If they are different, you should go ahead with your update, otherwise not.

This was my scenario: I had created a remote event receiver that was attached to a document library and was supposed to act whenever an item in the list was updated. The initialization of the event receiver looks like this:

And all was fine in the world. The event receiver was nicely attached and got busy when I uploaded a document. But then it started acting out and making trouble. I was trying to change permissions on an item and this was the part of my code that was creating the problems:

Inside my SPRemoteEventType.ItemUpdated I did an Update and making it trigger itself. Recursive SharePoint with no end in site.. If you’re dealing with a event receiver with access to server side code, this is not a problem.

Writing that makes your world pink and sparkly again. But this is the barren end empty world of the remote event receiver and no such this is available.

How I solved it

Googleing this helped me not one bit and my first solution was something I would like to hide at the bottom of some server (I don’t want to talk about it, let’s just say it had something to do with counting the seconds since the last update).

At your disposal on SPRemoteEventProperties you have afterProperties and beforeProperties, found by doing this:

And those were the key to the problem: how to act on the firing only when the user changes something and not when it updates itself? By comparing the values in the beforeProperties with the afterProperties I could see if they contained a difference. If it doesn’t, the updating event should not happen again.

In my case I was changing the value of a custom property named CMIsSecret, so if that property was the same in beforeProperties as in afterProperties (the values before and after the save) I should go on with the update, otherwise not. This was the method I created:

It checks if the property exists at all (it doesn’t if it is an ItemAdded-event and the property is custom made) and if it differs. It returns true if the property should be updated and the final usage looked like this:

Where ”ChangePermissionSettings” changes and updates the item.

Hope it helps!

Convert any web app to a SharePoint app


Have you noticed that you can right-click a web application project in Visual Studio and convert it to a provider hosted app? Well why not? Basically your own website and a SharePoint manifest is all what you need for a provider hosted app.


This discovery today made me think about all legacy web apps out there that can be converted to SharePoint apps.  Traditionally we had to add plain links to external applications or embed them into an IFrame by hardcoding it in an .aspx page or a Page Viewer WebPart.

A web application that should be converted to a SharePoint app can be any web app, not only asp.net web site.

For a year ago, I had a little nodejs project to try out mongodb and knockout.js: Anvaska which I published as a heroku app:

Now I want to try to convert this to a SharePoint app. I am satisfied when:

  1. A full page app is rendering Anvaska
  2. The SharePoint app renders the chrome control (suiteBar) if the app runs within a SharePoint context
1. A full page app

To create a link to Anvaska is simple. I only have to add the link in the manifest file:


But when I click on the app, there is a problem:


A “POST” to this site? Why? The reason is the application page called appredirect which makes a “POST” call:

  • /_layouts/15/appredirect.aspx?instance_id={F9049494-42D0-4077-9F34-88A35B7271B9}

In the hive you can see why. The redirect page uses a form and POST method:


Just of curiosity, I tried to change method=”post” to method=”get” and the app worked. Of course you never should change any SharePoint built-in controls or pages. So there must be another solution. The asp.net web sites are okay with the external POST calls, but pages like wordpress, *.herokuapp.com don’t allow external POST redirects.

The anvaska application uses nodejs, expressjs. To solve this issue in this particular application I can do a redirect in express js:

SharePoint Matryoshka

Russian Nested Doll: Matryoshka

To overcome this issue with the POST verb, a nested iframe can be used. Recently, I wrote a post about “Provider Hosted First Approach” where I presented the original idea of Thomas Deutsch. The implementation is an SPAppIframe which covers the whole html body. In an app part it would cause a nested iframe. But it would work.

2. SharePoint Chrome Control (suiteBar)

To add a SharePoint Chrome Control is easy. Just follow this MSDN article:

Add a javascript file to your project: spapp-chrome.js and refer to it from your website page. That’s it. Here is the screenshot:



With a little effort, any legacy web application can be converted into a SharePoint app and be part of a bigger intranet, can be added by users in the sites where it is meaningful rather than just adding links to all existing external applications. These SharePoint apps could even interact with SharePoint and even have appwebs if it makes sense. What do you think? Let me know.