The launch of provider-hosted Add-Ins consists of 2 recurring steps:
- First, go to the SharePoint hostweb, and request AppRedirect.aspx
- The returned AppRedirect.aspx response contains a FORM structure, with as Action parameter the start-url of Add-In; via javascript embedded in the AppRedirect.aspx response the browser POST submits to request the Add-In start page.
See
Source: Chris Johnson, Launching SharePoint Apps, launch sequence, debugging and AppRedirect.aspxAn essential role and value of AppRedirect.aspx is to pass the authenticated identity of current user as context token from SharePoint WFE to the remote web. However, this only applies for OAuth based, low-trust authentication via Azure Access Control Service (ACS). In case of Server-2-Server, High-Trust authentication, SharePoint host(web) environment does not pass a context token at all. And thus there is no concrete added value nor necessity for the AppRedirect call before the launching of the provider-hosted Add-In.
The recurring invocation of AppRedirect.aspx per Add-In launch has some drawbacks:
- it involves an extra http request/response handling; in particular with longer network-distance, this costs noticable latency
- AppRedirect.aspx itself can take processing and elapse time. In IIS logs I observed that although not always, multiple times the server-side execution of this requests takes > 0.5 seconds to 1 second or more
- with higher load, I've earlier (Load testing SharePoint Add-in (former App) Model) noticed that the AppRedirect.aspx handling eventually becomes the bottleneck within the SharePoint WFEs
In the Add-In launch sequence, there is optimization possible as the AppRedirect.aspx step is avoidable in an High-Trust authentication situation. The added-value is in S2S authentication: zero. All the requested information to launch the Provider-Hosted Add-In is already included by SharePoint in the response of the host page that contains the Add-In(s): the 'src' value of provider-hosted Add-In iFrame element(s) exists of the pattern '<host>/_layouts/15/AppRedirect.aspx' and 'redirect_uri=<encoded uri of the Add-In startpage>'. Thus it is possible to shortcircuit the Add-In launch sequence by aborting the AppRedirect.aspx request, and replace it to instead immediate request as iFrame src the url-decoded 'redirect_uri' value.
Options to shortcircuit AppRedirect are:
- Server-side: via an HTTP-module, to intercept the HTTP response before it reaches the browser, and for every iFrame element replace the value of the src parameter from AppRedirect.aspx into it's redirect_uri value. Disadvantages of this approach are that it is non-discrimating: all responses returned will be parsed, thus also all those that do not even contain an Add-In structure; it requires custom server-side deployment, something that is nowadays not always allowed as companies aim for cloud-ready / future-proof deployments
- Client-side: on-the-fly change in browser / javascript-engine context, for every iFrame element replace the value of the src parameter from AppRedirect.aspx into it's redirect_uri querystring value. Disadvantage of this approach is that it is late, the browser typically already has requested the AppRedirect.aspx call. It still benefits to on-the-fly change the frame-src, and as such abort the waiting on AppRedirect.aspx response: in particular with longer network-distance, e.g. in case of a global company, it pays out to not wait for AppRedirect.aspx response to return, but immediate request the launch of the provider-hosted Add-In. And also it shortens in the scenario in which the processing time of AppRedirect.aspx would otherwise be [a] noticable bottleneck.
Snippet of the client-side approach:
<lSharePointWebControls:ScriptBlock runat="server">
function ShortCircuitLauchProviderHostedAppsInWPZone(webpartZone) {
var frmRedirectSnippet =
'<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"' +
'"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">' +
'<html dir="ltr" lang="en-US">' +
'<head><meta http-equiv="Expires" content="0" /><meta http-equiv="X-UA-Compatible" content="IE=8"/><title>Working on it...</title>' +
'<link rel="shortcut icon" href="/_layouts/15/images/favicon.ico?rev=23" type="image/vnd.microsoft.icon" />' +
'</head>' +
'<body>' +
'<div style="text-align:center;margin-top:40px;">' +
'<img src=\'data:image/gif;base64,R0lGODlh...'>' +
'<span style="color:#0072c6;font-size:36px;font-family:\'Segoe UI Light\', \'Segoe UI\', Tahoma, Helvetica, Arial, sans-serif;">' +
'Working on it...' +
'</span>' +
'</div>' +
'</body>' +
'</html>';
var iframesProviderHostedApps = webpartZone.querySelectorAll('iframe[src*="appredirect.aspx"]');
var i;
for (i = 0; i < iframesProviderHostedApps.length; i++) {
var src= iframesProviderHostedApps[i].getAttribute("src");
var redirect_uri = src.substring(src.indexOf("redirect_uri=") + "redirect_uri=".length);
var addInUrl = decodeURIComponent(redirect_uri);
iframesProviderHostedApps[i].contentWindow.document.write(frmRedirectSnippet);
iframesProviderHostedApps[i].setAttribute('src', addInUrl);
}
}
ShortCircuitLauchProviderHostedAppsInWPZone(document.getElementById("app_1"));
</SharePointWebControls:ScriptBlock>
The client-script approach enables yet another performance and resource usage optimization: delayed loading per Add-In until and only if it is in the visible part of the browser window. The user experiences the effect one is familair with on mobile devices: swipe the screen, and the application's content is on-the-fly retrieved + screen estate filled (Twitter, Facebook, ...).
Slightly modified snippet for lazy loading Provider-Hosted Add-Ins:
<lSharePointWebControls:ScriptBlock runat="server">
function isWithinVisibleViewport(element) {
var $w = jQuery(window);
var windowWidth = $w.width(),
windowHeight = $w.height(),
viewTop = $w.scrollTop(),
viewBottom = viewTop + windowHeight,
viewLeft = $w.scrollLeft(),
viewRight = viewLeft + windowWidth,
offset = element.offset(),
_top = offset.top,
_bottom = _top + element.height(),
_left = offset.left,
_right = _left + element.width(),
compareTop = _bottom,
compareBottom = _top,
compareLeft = _right,
compareRight = _left;
return ((compareBottom <= viewBottom) && (compareTop >= viewTop)) && ((compareRight <= viewRight) && (compareLeft >= viewLeft));
}
function ShortCircuitLauchProviderHostedApps() {
var nonVisibleInViewport = false;
var frmRedirectSnippet =
'<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"' +
.....
'</html>';
var iframesProviderHostedApps = document.querySelectorAll('iframe[src*="appredirect.aspx"]');
var i;
for (i = 0; i < iframesProviderHostedApps.length; i++) {
var delayedFrame = iframesProviderHostedApps[i];
var src = jQuery(delayedFrame).attr('src');
if (src != '') {
var redirect_uri = src.substring(src.indexOf("redirect_uri=") + "redirect_uri=".length);
var addInUrl = decodeURIComponent(redirect_uri);
} else {
addInUrl = jQuery(delayedFrame).attr('DelayedSrc');
}
if (isWithinVisibleViewport(jQuery(delayedFrame))) {
jQuery(delayedFrame).contents().find('html').html(frmRedirectSnippet);
jQuery(delayedFrame).setAttribute('src', addInUrl);
} else {
jQuery(delayedFrame).setAttribute('src', '');
jQuery(delayedFrame).setAttribute('DelayedSrc', addInUrl);
nonVisibleInViewport = true;'
}
}
jQuery('#s4-workspace').off('scroll', ShortCircuitLauchProviderHostedApps);
if (nonVisibleInViewport) {
jQuery('#s4-workspace').on('scroll', ShortCircuitLauchProviderHostedApps);
}
}
</SharePointWebControls:ScriptBlock>
