Click here to Skip to main content
15,886,806 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
Last week I discovered a bug where, after session timeout, any ajax request would be automatically redirected back to the Login action. The ajax request would then 'blow up' on the client. I easily reproduced the bug by deleting cookies and attempting a new ajax request. Then I thought I had solved the problem with the following code combination.

Client:
JavaScript
$.acme.global.dataAccess = function() {
	var dataAccess = {};

	Object.defineProperty(this, "httpHeaderAjax", { value: "Acme-Is-Ajax-Request", writeable: true });

	var defaultHeaders = {};
	defaultHeaders[httpHeaderAjax] = true;
   
	dataAccess.genericErrorFunction = function (response) {
		
		if (response.status == 401) {
			var returnUrl = location.pathname + location.search;
			location.href = "/Account/Login?returnUrl=" + encodeURIComponent(returnUrl);
		}
		else if (!(response.status == 302) && !(response.status == 0) &&!(response.status==200)) {
			location.href = "Error/?exceptionMessage=" + response.responseText;
		}
	};

	dataAccess.submitAjaxPostJsonRequestWithErrorFunction = function (targetUrl, jsonData, successFunction, errorFunction) {
	   
		var jsonString = JSON.stringify(jsonData);
		
		$.ajax({
			type: 'POST',
			url: targetUrl,
			data: jsonString,
			headers: defaultHeaders,
			crossDomain: true,
			success: successFunction,
			error: errorFunction,
			contentType: "application/json",
			dataType: 'json'
		});
	};

	return dataAccess;
}();

Server:
C#
public class AccountController: BaseController
{
	[AllowAnonymous]       
	public  ActionResult Login(string ReturnUrl = "")
	{
		var ajaxHeader = Request.Headers[HttpConstants.RequestHeaders.ThreeFifteenIsAjaxRequest] ?? "false";
		if (ajaxHeader == "true")
		{
			return new HttpUnauthorizedResult("Ajax request was redirected to Login action.");
		}
		if (ReturnUrl == "/Home/LogOff")
		{
			ReturnUrl = "/";
		}

		return View(AuthenticationProvider.Providers(ReturnUrl));
	}
}

This works fine on my local machine, and on our dev environment, an Azure Web Site, but when I deploy it to our staging site, another Azure Web Site, the ajax problem is still unresolved. Putting a browser break-point in genericErrorFunction shows an expected 401 response locally and on dev, but on staging all I can see on the response object are the functions set by the ajax call.

Nothing in the code above seems to be environment dependent - it feels pretty hard and explicit to me - but I am desperately looking for possible explanations here.
Posted
Updated 8-Dec-14 18:01pm
v2
Comments
Nathan Minier 9-Dec-14 7:27am    
This smells of an IIS configuration issue to me. I wish I could tell you offhand exactly which one it is, but the differential between IIS and IIS Express is often apt to....surprise.

1 solution

It turns out it was a web.config setting, not IIS config, over which I have minimum control - it's hosted as an Azure Web Site. It was actually a federated identity setting, passiveRedirectEnabled="false", which meant that my identity provider, Azure, was trying its own redirect to login, at the same time as mine, but without the ajax marker custom header.
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900