Page refresh after postback from UpdatePanel in Sharepoint 2013

Hello!

Strange behavior appears when using Updatepanel on Apllication page or usercontrol in Sharepoint 2013.

In FF and Chrome postback leads to full page refresh after small idle between requests (around 30 seconds). Example: we have a page with button and label inside UpdatePanel. We open this page and click the button -> updatepanel refreshes its content without page reload. If we will wait more than 30 seconds and click the button again, page will reload. 

In Firebug or Fiddler we can see follow:

1) POST-request from updatepanel to server

2) Response from server will contains 

1|#||4|53|pageRedirect||/_login/default.aspx?ReturnUrl=<my page url>

3) After there will be request to /_login/default.aspx and then redirect to  /_windows/default.aspx?ReturnUrl=<my page url>

4) And then it will be redirected to my initial page.

Users see only page reload.

But if we will wait a long time (around 20 minutes) there will be not page reload and updatepanel refreshes only their content.

This error happens in different environment in defferent domains. We use standart Claims based authentication and Minimal Download Strategy feature is disabled.

In IE this error occurs, but not so often.

I found that error disappears if Form Authentication is disabled in IIS web application (but in this case there are some problems in another pages in portal).

Can anyone help me with this problem. Thanks

February 16th, 2014 1:16pm

did you ever find a solution to this?
Free Windows Admin Tool Kit Click here and download it now
March 2nd, 2014 3:41pm

No. Do you have the same problem?

I found that it is related with claims based authentication and maybe it is related with authentication between servers. Bug occurs if AD, SQL and Sharepoint are installed on different servers. And there is no bug if AD, SQL and Sharepoint are on the same server.

If web application is configured to classic windows aunetnication there is no bug.


March 21st, 2014 7:00am

Hi,

I've got the same symptoms. Can't figure it out at all. The funny thing is update panels had been working fine on this environment for months and it's just stopped working all of a sudden. I don't think anything in the environment has changed and I can't see code changes which would affect it.


Free Windows Admin Tool Kit Click here and download it now
June 5th, 2014 2:21pm

Hi.

Can you describe your farm topology? How many servers and what is installed on them?

June 5th, 2014 6:04pm

Hi Dmitry,

It's like you said, separate machines for AD, SQL and SharePoint. We have 2 AD, 2 SQL and 2 SharePoint servers. We have live environment with the same setup where it seems to work fine. The only difference is that the problem environment is a subdomain of the corporate domain, and there's less resources allocated to it. But I don't think that's the problem. I've spent a long time looking at this now, and all I can think of is it's some type of security/authentication issue. Why is it redirecting the request to a login page?

Dan

Free Windows Admin Tool Kit Click here and download it now
June 6th, 2014 7:31am

Hi Dan.

As i understand redirect occurs when system cannot determine user claims. In fact it cannot determine claims after ~30 seconds idle.

We made some experiment: we have added js script to page which calls any sharepoint web service every 15-20 seconds. And this bug  has particulary disappeared. In other words if there is any request from browser to server with period less than 30 second, it works almost fine:) 

But i believe that problem is related with environment settings or (maybe) permissions between services in environment.  I've seen this problem in several different companies and i don't think they have any strange settings. Problem must to be related with some main settings of claims auth, IIS or service accounts permissions.

In one of the previous posts you have written "update panels had been working fine on this environment for months and it's just stopped working all of a sudden". Are you sure that there was no change in authenticaation settings for web application?

Dmitry

June 6th, 2014 8:48am

Hi,

That's very interesting thanks.

Hmmm, I'm not 100% confident now that it ever worked in this environment. But no one's ever noticed it before. But there's the possibility if could have never worked.

It's frustrating because it works perfectly in the production environment (thank god), so I know it can work. I just don't know what the problem is.

Thanks very much for your help

Free Windows Admin Tool Kit Click here and download it now
June 6th, 2014 10:11am

Dan, maybe we can join our forces to find the reason of this problem? We could to make contact in LinkedIn to  share experiences on this issue. This is link to my profile.

Dmitry

June 6th, 2014 2:34pm

Hi,

This is happening because ViewState architecture has been changed in SharePoint 2013. Right click and open ViewSource of the page, search for _VIEWSTATE, you will see only a GUID rather than actual viewstate of controls.

To improve the client-server network performance, Microsoft has introduced the concept of Distributed Cache, and all the controls view state is getting stored in DistributedViewStateCache [on server side]. 

So if you will not scale out your SharePoint environment to meet the timeout requirement, then during partial post back you will get this experience - "full post back".

Fix - if you are using lot of asp.net concepts/.ascx user controls then I would say opt for managing view state on client side[asp.net style]

  • $contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService;
  • $contentService.ViewStateOnServer = $false;
  • $contentService.Update();

But if you want to keep out of box architecture, then consider changing timeout values.

Not only DistributedViewStateCache timeout can cause this, DistributedLogonTokenCache timeout can also be issue. So set the values like below:-

$DLTC = Get-SPDistributedCacheClientSetting -ContainerType DistributedLogonTokenCache

$DLTC.ChannelInitializationTimeout = "60000"
$DLTC.ConnectionBufferSize = "131072"
$DLTC.MaxBufferPoolSize = "268435456"
$DLTC.MaxBufferSize = "1073741824"
$DLTC.MaxOutputDelay = "2"
$DLTC.ReceiveTimeout = "60000"
$DLTC.ChannelOpenTimeOut = "60000"
$DLTC.RequestTimeout = "60000"
$DLTC.MaxConnectionsToServer = "100"

Set-SPDistributedCacheClientSetting -ContainerType DistributedLogonTokenCache $DLTC

Restart-Service -Name AppFabricCachingService

Get-SPDistributedCacheClientSetting -ContainerType DistributedLogonTokenCache

Also update the App fabric of the servers to CU5+, there is a memory leak bug with oob version... http://support.microsoft.com/kb/2787717/en-us

Hope this will help you to resolve your issue...

If you are migrating from SharePoint 2007 to 2013, there could be other issues also you may need to consider like classic to claims based authentication..



  • Edited by Pardeep Bassi Monday, September 22, 2014 6:34 PM
  • Proposed as answer by Pardeep Bassi Monday, September 22, 2014 6:36 PM
Free Windows Admin Tool Kit Click here and download it now
September 22nd, 2014 6:08pm

Hi,

This is happening because ViewState architecture has been changed in SharePoint 2013. Right click and open ViewSource of the page, search for _VIEWSTATE, you will see only a GUID rather than actual viewstate of controls.

To improve the client-server network performance, Microsoft has introduced the concept of Distributed Cache, and all the controls view state is getting stored in DistributedViewStateCache [on server side]. 

So if you will not scale out your SharePoint environment to meet the timeout requirement, then during partial post back you will get this experience - "full post back".

Fix - if you are using lot of asp.net concepts/.ascx user controls then I would say opt for managing view state on client side[asp.net style]

  • $contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService;
  • $contentService.ViewStateOnServer = $false;
  • $contentService.Update();

But if you want to keep out of box architecture, then consider changing timeout values.

Not only DistributedViewStateCache timeout can cause this, DistributedLogonTokenCache timeout can also be issue. So set the values like below:-

$DLTC = Get-SPDistributedCacheClientSetting -ContainerType DistributedLogonTokenCache

$DLTC.ChannelInitializationTimeout = "60000"
$DLTC.ConnectionBufferSize = "131072"
$DLTC.MaxBufferPoolSize = "268435456"
$DLTC.MaxBufferSize = "1073741824"
$DLTC.MaxOutputDelay = "2"
$DLTC.ReceiveTimeout = "60000"
$DLTC.ChannelOpenTimeOut = "60000"
$DLTC.RequestTimeout = "60000"
$DLTC.MaxConnectionsToServer = "100"

Set-SPDistributedCacheClientSetting -ContainerType DistributedLogonTokenCache $DLTC

Restart-Service -Name AppFabricCachingService

Get-SPDistributedCacheClientSetting -ContainerType DistributedLogonTokenCache

Also update the App fabric of the servers to CU5+, there is a memory leak bug with oob version... http://support.microsoft.com/kb/2787717/en-us

Hope this will help you to resolve your issue...

If you are migrating from SharePoint 2007 to 2013, there could be other issues also you may need to consider like classic to claims based authentication..



  • Edited by Pardeep Bassi Monday, September 22, 2014 6:34 PM
  • Proposed as answer by Pardeep Bassi Monday, September 22, 2014 6:36 PM
September 22nd, 2014 6:08pm

Hi,

This is happening because ViewState architecture has been changed in SharePoint 2013. Right click and open ViewSource of the page, search for _VIEWSTATE, you will see only a GUID rather than actual viewstate of controls.

To improve the client-server network performance, Microsoft has introduced the concept of Distributed Cache, and all the controls view state is getting stored in DistributedViewStateCache [on server side]. 

So if you will not scale out your SharePoint environment to meet the timeout requirement, then during partial post back you will get this experience - "full post back".

Fix - if you are using lot of asp.net concepts/.ascx user controls then I would say opt for managing view state on client side[asp.net style]

  • $contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService;
  • $contentService.ViewStateOnServer = $false;
  • $contentService.Update();

But if you want to keep out of box architecture, then consider changing timeout values.

Not only DistributedViewStateCache timeout can cause this, DistributedLogonTokenCache timeout can also be issue. So set the values like below:-

$DLTC = Get-SPDistributedCacheClientSetting -ContainerType DistributedLogonTokenCache

$DLTC.ChannelInitializationTimeout = "60000"
$DLTC.ConnectionBufferSize = "131072"
$DLTC.MaxBufferPoolSize = "268435456"
$DLTC.MaxBufferSize = "1073741824"
$DLTC.MaxOutputDelay = "2"
$DLTC.ReceiveTimeout = "60000"
$DLTC.ChannelOpenTimeOut = "60000"
$DLTC.RequestTimeout = "60000"
$DLTC.MaxConnectionsToServer = "100"

Set-SPDistributedCacheClientSetting -ContainerType DistributedLogonTokenCache $DLTC

Restart-Service -Name AppFabricCachingService

Get-SPDistributedCacheClientSetting -ContainerType DistributedLogonTokenCache

Also update the App fabric of the servers to CU5+, there is a memory leak bug with oob version... http://support.microsoft.com/kb/2787717/en-us

Hope this will help you to resolve your issue...

If you are migrating from SharePoint 2007 to 2013, there could be other issues also you may need to consider like classic to claims based authentication..



  • Edited by Pardeep Bassi Monday, September 22, 2014 6:34 PM
  • Proposed as answer by Pardeep Bassi Monday, September 22, 2014 6:36 PM
Free Windows Admin Tool Kit Click here and download it now
September 22nd, 2014 6:08pm

Thanks for your effort Pardeep.

It'll take me a while to validate if this works for me or not. It's definitely the best idea I've heard.

Dan

September 23rd, 2014 7:49am

I also have this problem, and I don't believe that changing Distributed Cache timeouts will help anything in this case.

The full postback (while they are actually redirects to the _login page and then back to the ReturnUrl) sometimes happens instantly on first async postback, sometimes on 5th async postback, sometimes it takes more.

It's more or less random.

Also in SP2013 when you disable Distributed Cache service, the full (old style) __viewstate is visible in the page, so it works the old way, and I still get full postbacks (while they are actually redirects to the _login page and then back to the ReturnUrl).

One quick test that I did, was disabled the redirects to from the _login page, like it is mentioned here:

http://amilagm.com/2010/11/prevent-forms-auth-from-redirecting-to-login-page-in-restful-wcf/

The only thing that surely helps is to disable Forms Authenticaation in IIS for that web application, but that is also not an option.

Free Windows Admin Tool Kit Click here and download it now
September 23rd, 2014 11:26am

Please disregard my above post, this is a known issue with SharePoint and Microsoft is working on to release the fix as cumulative update.

Basically the fix will deploy an IHttpModule , this module will check if REQUEST is partial post back or request header contains ["X-MicrosoftAjax"] then set SuppressFormsAuthenticationRedirect to true.

October 7th, 2014 7:36pm

Please disregard my above post, this is a known issue with SharePoint and Microsoft is working on to release the fix as cumulative update.

Basically the fix will deploy an IHttpModule , this module will check if REQUEST is partial post back or request header contains ["X-MicrosoftAjax"] then set SuppressFormsAuthenticationRedirect to true.

Hi,

Where did you get this info that this is a known bug?

Also it seems that this fix will only prevent for the automatic redirect to the initial page (Or the ReturnUrl that is mentioned in the first page).

But we need the fix on why the user gets logged out in the first place and gets the 401 error.

http://haacked.com/archive/2011/10/04/prevent-forms-authentication-login-page-redirect-when-you-donrsquot-want.aspx

This is a post on how to add the suppression, but I think it would only prevent from redirecting to the ReturnUrl, but not fix the problem itself.

Free Windows Admin Tool Kit Click here and download it now
October 8th, 2014 9:50am

We created a ticket with Microsoft for this issue, and the above one is the only workaround till they release CU.
October 9th, 2014 3:40pm

We created a ticket with Microsoft for this issue, and the above one is the only workaround till they release CU.

Hi again,

Did you try the proposed workaround? Did it work? If so, could you please share the source for the workaround?

Free Windows Admin Tool Kit Click here and download it now
October 10th, 2014 5:08am

Oh Guys,

I'm struggeling with the same issue for months...

Is there any further information about the release of the CU or a Hotfix?

I'd be very thankful if someone could provide more information if there is any.

October 14th, 2014 10:58am

Hello,

Did you find any new info on this issue? 
Free Windows Admin Tool Kit Click here and download it now
November 14th, 2014 2:52pm

Hello,

Did you find any new info on this issue? 
I recieved a call from MS-Support yesterday. "This Issue will be fixed in the next CU in December or January."
November 20th, 2014 7:55am

http://support2.microsoft.com/kb/2910943 

The Hotfix is here ;)

  • Proposed as answer by normalo Wednesday, December 10, 2014 11:26 AM
Free Windows Admin Tool Kit Click here and download it now
December 10th, 2014 11:23am

http://support2.microsoft.com/kb/2910943 

The Hotfix is here ;)

  • Proposed as answer by normalo Wednesday, December 10, 2014 11:26 AM
December 10th, 2014 11:23am

http://support2.microsoft.com/kb/2910943 

The Hotfix is here ;)

  • Proposed as answer by normalo Wednesday, December 10, 2014 11:26 AM
Free Windows Admin Tool Kit Click here and download it now
December 10th, 2014 11:23am

this hotfix is for foundation... what about Sharepoint Server 2013?

December 19th, 2014 1:15pm

Also hotfix did not fix the issue...
Free Windows Admin Tool Kit Click here and download it now
December 19th, 2014 2:59pm

Same here, only:

1. it happens if the page is idle a bit, much more than 30 seconds.

2. it also happens after a full page refresh with no cache - every time. this is a 100% reproducible scenario: either ctrl+r on IE to refresh the page, or clear browser cache to refresh the page, and click on the ajax update button within 4 seconds. if you wait longer the issue will be gone, if you do an ajax update within the 4 seconds - it will redirect to login and back in what looks like a refresh.

In my scenario:

1. using claims

2. all installed on the same machine expect the AD and claims which is on separate ADCX machine.

3. distributed cache is completely disabled, so no view state on the server

4. the user does have a valid login cookie, and form digest when this happens, since I clear cache not cookies he is still logged in.

This is driving my customers crazy!!! Hotfix - I will try it now...

February 24th, 2015 6:14pm

http://support2.microsoft.com/kb/2910943 

The Hotfix is here ;)

I can confirm the hotfix doesn't fix it for me. My scenario listed below with 100% chances of reproduction.

If you make the ajax update within a few seconds of the page load - it does a refresh for the first time after clear cache (or ctrl+r in IE).

Free Windows Admin Tool Kit Click here and download it now
February 24th, 2015 6:40pm

Hi,

We also ran into the described issue.  We ended up creating the following work around solution.

The solution details

The main goal of the implemented solution was to ensure that NTLM connection is established before UpdatePanel submits a request. 

To achieve this goal we implemented the following components:

  1. a JavaScript function that  asynchronously calls one of the SharePoint's out of the box web services and effectively re-establishes NTLM connection (if it was lost)
  2. a JavaScript function that intercepts any postback request from any of the update panel on the page and cancels that.  But in order to later re-issue the request, this function also captures and preserves the required metadata about the request right before the request is canceled
  3. a JavaScript function that reissues the request after we ensure that NTLM connection is up and ready

Below is the complete JavaScript code that performs the described above actions

Code

<<

var isNtlmActive = false;
var updatePannelsToUpdate = [];
var eventTarget = '';
var eventArgument = '';
var causesValidation = false;
var validationGroup = '';
var requestBody = '';

function initializeRequestHandler(sender, args) {
    var onSuccess = function () {
      //At this point the NTLM connection is re-established 

      var  pageRequestManagerInstance;
      isNtlmActive = true;

      pageRequestManagerInstance = Sys.WebForms.PageRequestManager.getInstance();

     // re-issuing the 'original' request
     pageRequestManagerInstance.beginAsyncPostBack(updatePannelsToUpdate, eventTarget, eventArgument, causesValidation, validationGroup);
    };

    var onError = function () {
      // do something here if error occurred
    }

    if (!isNtlmActive) {
      // capturing and preserving the body as well as some other meta data about the original request
      requestBody = args.get_request().get_body();
      updatePannelsToUpdate = sender._postBackSettings.panelsToUpdate;
      eventTarget = sender._postBackSettings.asyncTarget;
      eventArgument = '';
      causesValidation = false;
      validationGroup = '';

      // NOTE: the variable '_spFormOnSubmitCalled' is a global variable that gets injected by the logic iplemented in the 'init.js' file.  
      // Based on our observation of the logic in 'init.js' the varialbe '_spFormOnSubmitCalled' is set to true when HTML form's

      // 'onsubmit'  function is called and it is never set back to false (after we cancel the postback)
      // As the result, any subsequent attempts to submit the form do not work.
      // Thus, we excplicetely set the value back to false before we cancel the original post back request.
      //
      //'init.js'is autoatically referenced by SharePoint and included on to the 'master' page.
      // The HTML form as well as the functionality to handle submit is also provided by SharePoint.
      if (typeof _spFormOnSubmitCalled === "boolean") {
         _spFormOnSubmitCalled = false;
      }
      args.set_cancel(true);

      callServerSideServiceToReviveNtlmSession(onSuccess, onError);
    }
    else {
      // resetting the body of the request with the value captured from the original request
      args.get_request().set_body(requestBody);

      isNtlmActive = false;
      updatePannelsToUpdate = [];
      eventTarget = '';
      eventArgument = '';
      causesValidation = false;
      validationGroup = '';
    }
}

function getCurrentSiteCollectionUrl() {
    var url;

    url = window.location.protocol + "//" + window.location.host + _spPageContextInfo.siteServerRelativeUrl;

    return url;
}

function callServerSideServiceToReviveNtlmSession(successHandler, errorHandler) {
    var siteCollectionUrl;
    var testServiceUrl;
    var spRequestExecutor;
    var request;

    siteCollectionUrl = getCurrentSiteCollectionUrl();
    testServiceUrl = siteCollectionUrl + "/_api/web/title";

    spRequestExecutor = new SP.RequestExecutor(siteCollectionUrl);
    request = {
        url: testServiceUrl,
        method: "GET",
        headers: { "Accept": "application/json; odata=verbose" },
        success: successHandler,
        error: errorHandler
    };
    spRequestExecutor.executeAsync(request);
}

try {
    $(document).ready(function () {
        try {
            var pageRequestManagerInstance = null;
   
            //Note: Sys.WebForms.PageRequestManager gets injected into your page the minute you use ScriptManager (and UpdatePanel)
            pageRequestManagerInstance = Sys.WebForms.PageRequestManager.getInstance();

            pageRequestManagerInstance.add_initializeRequest(initializeRequestHandler);
        }
        catch (ex) {
            //alert('INNER EXCEPTION: document ready - ' + ex.message);
        }
    });
}
catch (ex) {
 //alert('EXCEPTION: document ready - ' + ex.message);
}

>>

As a prerequisite for the code above, You must have references to the following JavaScript files(libraries)

  1. jQuery
  2. <script src="/_layouts/15/SP.RequestExecutor.js" type="text/javascript"></script>

 

Based on my observations (in Development using Google Chrome), after implementing the solution the undesired behavior does not occur.  Meaning, SharePoint does not cause redirection to the login page when UpdatePannel control submits a partial(async) "post back".

Best Regards

April 13th, 2015 11:11pm

Hi,

We also ran into the described issue.  We ended up creating the following work around solution.

The solution details

The main goal of the implemented solution was to ensure that NTLM connection is established before UpdatePanel submits a request. 

To achieve this goal we implemented the following components:

  1. a JavaScript function that  asynchronously calls one of the SharePoint's out of the box web services and effectively re-establishes NTLM connection (if it was lost)
  2. a JavaScript function that intercepts any postback request from any of the update panel on the page and cancels that.  But in order to later re-issue the request, this function also captures and preserves the required metadata about the request right before the request is canceled
  3. a JavaScript function that reissues the request after we ensure that NTLM connection is up and ready

Below is the complete JavaScript code that performs the described above actions

Code

<<

var isNtlmActive = false;
var updatePannelsToUpdate = [];
var eventTarget = '';
var eventArgument = '';
var causesValidation = false;
var validationGroup = '';
var requestBody = '';

function initializeRequestHandler(sender, args) {
    var onSuccess = function () {
      //At this point the NTLM connection is re-established 

      var  pageRequestManagerInstance;
      isNtlmActive = true;

      pageRequestManagerInstance = Sys.WebForms.PageRequestManager.getInstance();

     // re-issuing the 'original' request
     pageRequestManagerInstance.beginAsyncPostBack(updatePannelsToUpdate, eventTarget, eventArgument, causesValidation, validationGroup);
    };

    var onError = function () {
      // do something here if error occurred
    }

    if (!isNtlmActive) {
      // capturing and preserving the body as well as some other meta data about the original request
      requestBody = args.get_request().get_body();
      updatePannelsToUpdate = sender._postBackSettings.panelsToUpdate;
      eventTarget = sender._postBackSettings.asyncTarget;
      eventArgument = '';
      causesValidation = false;
      validationGroup = '';

      // NOTE: the variable '_spFormOnSubmitCalled' is a global variable that gets injected by the logic iplemented in the 'init.js' file.  
      // Based on our observation of the logic in 'init.js' the varialbe '_spFormOnSubmitCalled' is set to true when HTML form's

      // 'onsubmit'  function is called and it is never set back to false (after we cancel the postback)
      // As the result, any subsequent attempts to submit the form do not work.
      // Thus, we excplicetely set the value back to false before we cancel the original post back request.
      //
      //'init.js'is autoatically referenced by SharePoint and included on to the 'master' page.
      // The HTML form as well as the functionality to handle submit is also provided by SharePoint.
      if (typeof _spFormOnSubmitCalled === "boolean") {
         _spFormOnSubmitCalled = false;
      }
      args.set_cancel(true);

      callServerSideServiceToReviveNtlmSession(onSuccess, onError);
    }
    else {
      // resetting the body of the request with the value captured from the original request
      args.get_request().set_body(requestBody);

      isNtlmActive = false;
      updatePannelsToUpdate = [];
      eventTarget = '';
      eventArgument = '';
      causesValidation = false;
      validationGroup = '';
    }
}

function getCurrentSiteCollectionUrl() {
    var url;

    url = window.location.protocol + "//" + window.location.host + _spPageContextInfo.siteServerRelativeUrl;

    return url;
}

function callServerSideServiceToReviveNtlmSession(successHandler, errorHandler) {
    var siteCollectionUrl;
    var testServiceUrl;
    var spRequestExecutor;
    var request;

    siteCollectionUrl = getCurrentSiteCollectionUrl();
    testServiceUrl = siteCollectionUrl + "/_api/web/title";

    spRequestExecutor = new SP.RequestExecutor(siteCollectionUrl);
    request = {
        url: testServiceUrl,
        method: "GET",
        headers: { "Accept": "application/json; odata=verbose" },
        success: successHandler,
        error: errorHandler
    };
    spRequestExecutor.executeAsync(request);
}

try {
    $(document).ready(function () {
        try {
            var pageRequestManagerInstance = null;
   
            //Note: Sys.WebForms.PageRequestManager gets injected into your page the minute you use ScriptManager (and UpdatePanel)
            pageRequestManagerInstance = Sys.WebForms.PageRequestManager.getInstance();

            pageRequestManagerInstance.add_initializeRequest(initializeRequestHandler);
        }
        catch (ex) {
            //alert('INNER EXCEPTION: document ready - ' + ex.message);
        }
    });
}
catch (ex) {
 //alert('EXCEPTION: document ready - ' + ex.message);
}

>>

As a prerequisite for the code above, You must have references to the following JavaScript files(libraries)

  1. jQuery
  2. <script src="/_layouts/15/SP.RequestExecutor.js" type="text/javascript"></script>

 

Based on my observations (in Development using Google Chrome), after implementing the solution the undesired behavior does not occur.  Meaning, SharePoint does not cause redirection to the login page when UpdatePannel control submits a partial(async) "post back".

Best Regards

  • Proposed as answer by DizzyBlack Monday, June 22, 2015 3:54 PM
  • Unproposed as answer by DizzyBlack Monday, June 22, 2015 4:00 PM
Free Windows Admin Tool Kit Click here and download it now
April 14th, 2015 3:09am

Hi,

We also ran into the described issue.  We ended up creating the following work around solution.

The solution details

The main goal of the implemented solution was to ensure that NTLM connection is established before UpdatePanel submits a request. 

To achieve this goal we implemented the following components:

  1. a JavaScript function that  asynchronously calls one of the SharePoint's out of the box web services and effectively re-establishes NTLM connection (if it was lost)
  2. a JavaScript function that intercepts any postback request from any of the update panel on the page and cancels that.  But in order to later re-issue the request, this function also captures and preserves the required metadata about the request right before the request is canceled
  3. a JavaScript function that reissues the request after we ensure that NTLM connection is up and ready

Below is the complete JavaScript code that performs the described above actions

Code

<<

var isNtlmActive = false;
var updatePannelsToUpdate = [];
var eventTarget = '';
var eventArgument = '';
var causesValidation = false;
var validationGroup = '';
var requestBody = '';

function initializeRequestHandler(sender, args) {
    var onSuccess = function () {
      //At this point the NTLM connection is re-established 

      var  pageRequestManagerInstance;
      isNtlmActive = true;

      pageRequestManagerInstance = Sys.WebForms.PageRequestManager.getInstance();

     // re-issuing the 'original' request
     pageRequestManagerInstance.beginAsyncPostBack(updatePannelsToUpdate, eventTarget, eventArgument, causesValidation, validationGroup);
    };

    var onError = function () {
      // do something here if error occurred
    }

    if (!isNtlmActive) {
      // capturing and preserving the body as well as some other meta data about the original request
      requestBody = args.get_request().get_body();
      updatePannelsToUpdate = sender._postBackSettings.panelsToUpdate;
      eventTarget = sender._postBackSettings.asyncTarget;
      eventArgument = '';
      causesValidation = false;
      validationGroup = '';

      // NOTE: the variable '_spFormOnSubmitCalled' is a global variable that gets injected by the logic iplemented in the 'init.js' file.  
      // Based on our observation of the logic in 'init.js' the varialbe '_spFormOnSubmitCalled' is set to true when HTML form's

      // 'onsubmit'  function is called and it is never set back to false (after we cancel the postback)
      // As the result, any subsequent attempts to submit the form do not work.
      // Thus, we excplicetely set the value back to false before we cancel the original post back request.
      //
      //'init.js'is autoatically referenced by SharePoint and included on to the 'master' page.
      // The HTML form as well as the functionality to handle submit is also provided by SharePoint.
      if (typeof _spFormOnSubmitCalled === "boolean") {
         _spFormOnSubmitCalled = false;
      }
      args.set_cancel(true);

      callServerSideServiceToReviveNtlmSession(onSuccess, onError);
    }
    else {
      // resetting the body of the request with the value captured from the original request
      args.get_request().set_body(requestBody);

      isNtlmActive = false;
      updatePannelsToUpdate = [];
      eventTarget = '';
      eventArgument = '';
      causesValidation = false;
      validationGroup = '';
    }
}

function getCurrentSiteCollectionUrl() {
    var url;

    url = window.location.protocol + "//" + window.location.host + _spPageContextInfo.siteServerRelativeUrl;

    return url;
}

function callServerSideServiceToReviveNtlmSession(successHandler, errorHandler) {
    var siteCollectionUrl;
    var testServiceUrl;
    var spRequestExecutor;
    var request;

    siteCollectionUrl = getCurrentSiteCollectionUrl();
    testServiceUrl = siteCollectionUrl + "/_api/web/title";

    spRequestExecutor = new SP.RequestExecutor(siteCollectionUrl);
    request = {
        url: testServiceUrl,
        method: "GET",
        headers: { "Accept": "application/json; odata=verbose" },
        success: successHandler,
        error: errorHandler
    };
    spRequestExecutor.executeAsync(request);
}

try {
    $(document).ready(function () {
        try {
            var pageRequestManagerInstance = null;
   
            //Note: Sys.WebForms.PageRequestManager gets injected into your page the minute you use ScriptManager (and UpdatePanel)
            pageRequestManagerInstance = Sys.WebForms.PageRequestManager.getInstance();

            pageRequestManagerInstance.add_initializeRequest(initializeRequestHandler);
        }
        catch (ex) {
            //alert('INNER EXCEPTION: document ready - ' + ex.message);
        }
    });
}
catch (ex) {
 //alert('EXCEPTION: document ready - ' + ex.message);
}

>>

As a prerequisite for the code above, You must have references to the following JavaScript files(libraries)

  1. jQuery
  2. <script src="/_layouts/15/SP.RequestExecutor.js" type="text/javascript"></script>

 

Based on my observations (in Development using Google Chrome), after implementing the solution the undesired behavior does not occur.  Meaning, SharePoint does not cause redirection to the login page when UpdatePannel control submits a partial(async) "post back".

Best Regards

  • Proposed as answer by DizzyBlack Monday, June 22, 2015 3:54 PM
  • Unproposed as answer by DizzyBlack Monday, June 22, 2015 4:00 PM
  • Proposed as answer by Kaushal Khamar Monday, September 07, 2015 11:03 AM
April 14th, 2015 3:09am

Sounds very clever way about it, I will definitely try and see if it helps in my scenario.
Free Windows Admin Tool Kit Click here and download it now
April 14th, 2015 4:32pm

I have been investigating an issue like this for approximately two months.

The issue manifested itself in our production environment during implementation of a new web application. A modal window had a number of tabs and a number of postbacks. Generally, the redirect to /_windows/default.aspx?ReturnUrl=<url> would be triggered resulting in the modal window being emptied.

There was a pre-release environment where the issue did not manifest and no amount of testing could reproduce it.

We considered every aspect of the solution, timeout values, session state, load balancing, sticky sessions, session persistence, the ASP Session State Service.

After a ground up comparison, we discovered that the Request Management Service was enabled in the production environment on the Web Front End servers but was not enabled in the Pre-release environment. No configuration had ever been done for the Request Management Service so it was started but effectively unconfigured. We were never able to reproduce the issue in the Pre-release environment, however, noticing this difference between the environments, the Request Management Service was then enabled in Pre-release on the Web Front End servers only.

The issue immediately manifested itself for the first time in Pre-release. We are currently still in the testing phase in Pre-release to confirm that the issue "goes away" again after the Request Management Service is disabled.

I realise of course that some of you may be using the Request Management Service for its intended purpose or in fact the Request Management Service may not even be enabled in your environments but this is the most promising lead we have up to now and the only thing that enabled us to repro the issue.

I'll report back on this thread in the event of success or failure..


  • Edited by Lewis Roberts Thursday, April 23, 2015 8:40 PM edits to clear up grammar
April 23rd, 2015 1:59pm

I have been investigating an issue like this for approximately two months.

The issue manifested itself in our production environment during implementation of a new web application. A modal window had a number of tabs and a number of postbacks. Generally, the redirect to /_windows/default.aspx?ReturnUrl=<url> would be triggered resulting in the modal window being emptied.

There was a pre-release environment where the issue did not manifest and no amount of testing could reproduce it.

We considered every aspect of the solution, timeout values, session state, load balancing, sticky sessions, session persistence, the ASP Session State Service.

After a ground up comparison, we discovered that the Request Management Service was enabled in the production environment on the Web Front End servers but was not enabled in the Pre-release environment. No configuration had ever been done for the Request Management Service so it was started but effectively unconfigured. We were never able to reproduce the issue in the Pre-release environment, however, noticing this difference between the environments, the Request Management Service was then enabled in Pre-release on the Web Front End servers only.

The issue immediately manifested itself for the first time in Pre-release. We are currently still in the testing phase in Pre-release to confirm that the issue "goes away" again after the Request Management Service is disabled.

I realise of course that some of you may be using the Request Management Service for its intended purpose or in fact the Request Management Service may not even be enabled in your environments but this is the most promising lead we have up to now and the only thing that enabled us to repro the issue.

I'll report back on this thread in the event of success or failure..


  • Edited by Lewis Roberts Thursday, April 23, 2015 8:40 PM edits to clear up grammar
Free Windows Admin Tool Kit Click here and download it now
April 23rd, 2015 1:59pm

I have been investigating an issue like this for approximately two months.

The issue manifested itself in our production environment during implementation of a new web application. A modal window had a number of tabs and a number of postbacks. Generally, the redirect to /_windows/default.aspx?ReturnUrl=<url> would be triggered resulting in the modal window being emptied.

There was a pre-release environment where the issue did not manifest and no amount of testing could reproduce it.

We considered every aspect of the solution, timeout values, session state, load balancing, sticky sessions, session persistence, the ASP Session State Service.

After a ground up comparison, we discovered that the Request Management Service was enabled in the production environment on the Web Front End servers but was not enabled in the Pre-release environment. No configuration had ever been done for the Request Management Service so it was started but effectively unconfigured. We were never able to reproduce the issue in the Pre-release environment, however, noticing this difference between the environments, the Request Management Service was then enabled in Pre-release on the Web Front End servers only.

The issue immediately manifested itself for the first time in Pre-release. We are currently still in the testing phase in Pre-release to confirm that the issue "goes away" again after the Request Management Service is disabled.

I realise of course that some of you may be using the Request Management Service for its intended purpose or in fact the Request Management Service may not even be enabled in your environments but this is the most promising lead we have up to now and the only thing that enabled us to repro the issue.

I'll report back on this thread in the event of success or failure..


  • Edited by Lewis Roberts Thursday, April 23, 2015 8:40 PM edits to clear up grammar
April 23rd, 2015 1:59pm

Thanks, but I just checked - this service was stopped on my server, never started.

It happens to me quite regularly especially when using ajax updates on a page shortly after the page has loaded.

Usually if i wait a minute before having ajax updates it works ok

Cannot explain this crazy thing... Only thing i know for sure is that it redirects me to the login and comes back.

Free Windows Admin Tool Kit Click here and download it now
April 23rd, 2015 6:01pm

Well, after further testing, the result is positive for us. Stopping the Request Manager on the WFEs resolved our issue.

We were able to reproduce and then resolve the issue by toggling Request Manager on (issue experienced) and off (resolved, no issue).

We rolled this forward in to the production environment and it was instantly resolved. My assumption for why turning off Request Manager for us worked is that the request pipeline was being intercepted by Request Manager during postback and sent to a server which the user had not authenticated to. The server that received the request responded in kind and forced the user to log on (claims, but NTLM) - the user would be bounced to the log on page, which was destroying (somehow) the viewstate information. Since this was done in the background, when the user next performed a postback, they were dumped back to an empty form.

Secondarily, we had an issue with massive ULS log utilisation on the WFE servers with dozens of the following messages every few seconds: "Cannot find site lookup info for request Uri http://<wfe-servername>/", these were usually followed by System.IO.FileNotFoundException messages.

Turning off Request Manager resolved this for us too.

I read this article from Spencer Harbar and Request Management indeed pings/polls the servers to get information from them very frequently. http://www.harbar.net/articles/sp2013rm1.aspx

Sorry it doesn't look as though it's going to resolve your issue though Shai.

April 23rd, 2015 8:25pm

Shai, have you tried setting AllowAnonymousImpersonation to false?

https://support.microsoft.com/en-us/kb/2686411

Still testing, but this seems to be working to resolve the same (or very similar) issue for me.  Good luck.

Free Windows Admin Tool Kit Click here and download it now
April 28th, 2015 4:49pm

Thanks, I'll give it a try and update
April 29th, 2015 12:26pm

Shai, have you tried setting AllowAnonymousImpersonation to false?

https://support.microsoft.com/en-us/kb/2686411

Still testing, but this seems to be working to resolve the same (or very similar) issue for me.  Good

Free Windows Admin Tool Kit Click here and download it now
May 15th, 2015 10:47am

Alexander Khaykin, Tried your code "as is" and it seems that it does fix the issue (have tested it in chrome). Will test it further, thank you!

  • Edited by DizzyBlack Monday, June 22, 2015 4:09 PM
June 22nd, 2015 4:07pm

Alexander Khaykin, Tried your code "as is" and it seems that it does fix the issue (have tested it in chrome). Will test it further, thank you!

  • Edited by DizzyBlack Monday, June 22, 2015 4:09 PM
Free Windows Admin Tool Kit Click here and download it now
June 22nd, 2015 4:07pm

I tried to use Alexander Khajkins JavaScript Version to solve a very similar Problem with a 3. Party Library.

But i have a little Problem:

If i add the given js-code with a Content Editor to Page, it works until the point where it should call the original function.

pageRequestManagerInstance.beginAsyncPostBack(updatePannelsToUpdate, eventTarget, eventArgument, causesValidation, validationGroup);

After this call nothing happens. This does apply to all Ajax calls on the site (therefore i can't edit the page anymore unless i delete the Content Editor.

Any idea why this happens?

Best regards,

lolsharp


  • Edited by lolsharp Tuesday, June 30, 2015 1:46 PM
June 30th, 2015 1:46pm

I tried to use Alexander Khajkins JavaScript Version to solve a very similar Problem with a 3. Party Library.

But i have a little Problem:

If i add the given js-code with a Content Editor to Page, it works until the point where it should call the original function.

pageRequestManagerInstance.beginAsyncPostBack(updatePannelsToUpdate, eventTarget, eventArgument, causesValidation, validationGroup);

After this call nothing happens. This does apply to all Ajax calls on the site (therefore i can't edit the page anymore unless i delete the Content Editor.

Any idea why this happens?

Best regards,

lolsharp


  • Edited by lolsharp Tuesday, June 30, 2015 1:46 PM
Free Windows Admin Tool Kit Click here and download it now
June 30th, 2015 1:46pm

Did you install DEC 2014 CU? here is the link https://support.microsoft.com/en-us/kb/2910945. This includes the hotfix.

July 27th, 2015 9:28pm

Are you sure the DEC 2014 CU addresses this issue?  I don't see the issue mentioned in KB link you provided.  Are you able to provide a link to a page showing this issue has been addressed?
Free Windows Admin Tool Kit Click here and download it now
August 3rd, 2015 5:46pm

Yeah, it's there:

"When you browse to a SharePoint 2013 page that contains an UpdatePanel control, the page may be refreshed randomly. Therefore, if you type something in a text field on the page, the text field may become empty."

I will confirm once I get a chance to test this.

August 5th, 2015 2:01pm

Hay anyone can tell me that is this issue has been resolved in this DEC 2014 CU hotfix?
Can anyone confirm?
Free Windows Admin Tool Kit Click here and download it now
September 7th, 2015 10:02am

Did you install DEC 2014 CU? here is the link https://support.microsoft.com/en-us/kb/2910945. This includes the hotfix.

just did. even got my hopes up.

alas, this huge update file ran, restarted my server, but the issue remains.

It seems non IE browsers are more affected by this issue. Chrome now has this issue every single time, before it was hit and miss, now it is consistent.

update: in Edge browser, and in IE, it happens first time only. like before. Now in chrome it happens every single time. Any ajax updatepanel update will get a response "redirect" since the authentication cookies are not sent to the s

September 14th, 2015 8:26pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics