Published the “September 2012” version of feetens to Windows Azure. The Intuit App Center “AppCard” to be updated imminently.
The curious case of resizing Google Maps in Firefox
I’ve resorted to a hack which causes me displeasure. I’ve been entirely unable to diagnose an issue I’ve encountered when attempting to programmatically resize a page containing a Google Map in Firefox. The problem only occurs in Firefox (but this does not entail that Firefox is behaving badly, it could be that the other browsers are consistently wrong), only on an iframe and, rather maddeningly, I’m unable to debug the JavaScript in Firebug. I can repro the bug every time in Firefox and never in Chrome/Safari and IE. However, I’m unable to repro the bug in another project in order to share it with others!
Perhaps someone reading this has a stunning insight and is able to provide a solution?
My app is hosted in an iframe by Intuit App Center. I have not experienced problems with this configuration previously. My app includes a DIV that references the Google Map. I new up the map per guidelines and without setting any dimensions beyond those of the DIV (width:100%):
new google.maps.Map(e, { zoom: c.zoom || 4, center: new google.maps.LatLng( c.center.lat, c.center.lng), mapTypeId: google.maps.MapTypeId.ROADMAP });
The problem is that, in Chrome/Safari and IE, the map renders correctly on the page and I have a snippet of JavaScript/jQuery code that attempts to resize the map to fill the height available to it:
$map.height($map.height() + ($(window).height() - $("body").height());
The problem appears (!) to be that, in Firefox, the page resize events aren’t finalized/ready in time for the jQuery script to adjust the map height correctly. In fact, it would appear that, in Firefox, $(window).height() is not revised until all the scripts on the page complete (callbacks aside). The unfortunate consequence of this is that, unless ‘fudged’ elsewhere, the map does not display correctly in Firefox because it’s height remains set at zero. You can observe this happening in the debug scripts below. After adding further debugging scripts, I was able to determine that this always happens immediately after the last line of any scripts on the page completes.
In Chrome/Safari and IE, the events occur more-or-less immediately and the script completes correctly; the map is displayed and correctly resized to fit the available space.
Firefox 16
Adding event listener for ’tilesloaded’
$map resizing
map.height = 0
window.height(150) – body.height(368) = –218
$map resizing done
[win] changed (771)
google.maps reports ’tilesloaded’. [height=0, width=960]
Chrome 21
Adding event listener for ’tilesloaded’
$map resizing
map.height = 0
window.height(776) – body.height(364) = 412
$map resizing done
[map] changed (412)
google.maps reports ’tilesloaded’. [height=412, width=960]
Internet Explorer 9
Adding event listener for ’tilesloaded’
$map resizing
map.height = 0
window.height(777) – body.height(365) = 412
$map resizing done
[map] changed (412)
google.maps reports ’tilesloaded’. [height=412, width=960]
The only way that I’ve been able to fix this is to detect the browser, for Chrome/Safari and IE, the script remains unchanged. For Firefox, I’ve had to move the resizing code and a Google Maps refresh to a point that’s artificially later in the thread in order to ensure that it occurs after the window height ‘settles down’.
$map.height($(window).height() - $("body").height()); google.maps.event.trigger(map, "resize");
One problem that hasn’t helped my diagnosis is that I’m unable to debug the iframe’s JavaScript within Firebug. I can access these scripts without problem under Chrome/Safari and IE but, of course, I need to be able to do this in Firefox/Firebug because this is where the problem arises. Even more curiously, if I open the frame in a separate tab, the Google Maps draw correctly and so I’m unable to debug the problem.
I did learn a new trick in Firebug for switching between frames thanks to this post on StackOverflow
cd(frames[0])
Embedding OAuth consent flow in an iframe
Hindsight is, as they say “20:20”.
I discovered a flaw in feetens that gave me serious pause as I wondered whether it was insurmountable. I know now that the problem I was experiencing is by design: OAuth flows should not be embedded within an iframe. This is for security reasons but, for a while, both the problem and its solution had me stumped.
I encountered the problem when I deployed the latest version of feetens to Azure. I’d been unintentionally avoiding the problem when deploying the app to the deployment fabric but it would have occurred there as well. The initial problem was that AJAX requests to the Azure DataMarket (OAuth) consent flow were being cancelled.
I’d not seen this error before but soon realized that it was generated for any URL to the Data Market. You can see the error for yourself with this jsFiddle. This led me to the conclusion that it was related to the iframes used by both Intuit’s Workplace and jsFiddle.
Clearly the solution is to run the consent flow outside of the iframe but, how to do this without disrupting the Intuit Workplace app and, given that this approach would continue to have access to the site’s cookies, is this approach secure and recommended?
Fortunately, folks on the MSDN forum were quick to help.
The (current) solution is to trigger the DataMarket’s OAuth consent flow in a new tab (target=”_blank”) when the user clicks the a login hyperlink:
@Html.ActionLink("Connect", "Connect", null, null, new { target="_blank" })
The ‘Connect’ action is trivial. If, the Data Market is inaccessible, the consent flow is triggered. This uses Adam Wilson’s elegant DataMarket OAuth Samples discussed previously.
public ActionResult Connect() { if (!this.MarketplaceAccessible) { DataMarket.Adaptor.Authorize(); } return View(); }
The view of the ‘Connect’ action is quirky. It’s reached once the consent flow is complete and it closes the current/consent flow tab, returning the user back to the application.
<script type="text/javascript"> window.opener.location.href = window.opener.location.href; self.close(); </script>
A convenient side-effect of the @Html.ActionLink is that, when it completes (as the consent flow tab closes), it refreshes the page, thus refreshing the state of the application with access to the Data Market.
jQuery Deferred Object (correction)
A minor but important correction to my post jQuery Deferred object. I realized during a refactoring exercise today that there is a flaw in the $.when(…).always() example that I posted at the end of the post.
After much consternation this morning when the code behaved incorrectly (it didn’t of course, it was me), I reread the jQuery documentation and saw “The [when] method will resolve its master Deferred as soon as all the Deferreds resolve, or reject the master Deferred as soon as one of the Deferreds is rejected”. The consequence of this is that the ‘always’ function in my example will be called if any of the batch of deferreds is rejected, not as I’d assumed, once all of them have either resolved or rejected.
My immediate response was to hack a solution by forcing all the deferreds in the batch to resolve. But, I was uncomfortable with this inelegance. Fortunately, Stack Overflow once again came to the rescue and Alnitak provided a clever answer introducing a secondary deferred that always resolves.
Here’s the corrected code that incorporates Alnitak’s suggestion with an updated jsFiddle. Thanks Alnitak!
$.when.apply($, data.map(function (letter) { var $def = $.Deferred(); async(letter).done(function (letter) { console.log(new Date().toLocaleTimeString() + ": done"); viewModel.success.push(letter); }).fail(function (letter) { console.log(new Date().toLocaleTimeString() + ": fail"); viewModel.failure.push(letter); }).always($def.resolve); return $def.promise(); })).always(function () { console.log("success"); });
Anti-Forgery with Web API in ASP.NET MVC 4 RC
Stack Overflow is terrific. Within an hour of posting a plea for help combining Haack-Driessen CSRF implementation for vanilla MVC controllers into a solution supporting JSON-based AJAX services against Web API, Darin Dimitrov had posted code for a working solution. I’m unsure of the protocol in publishing code but, if you find the following useful, please take the time to up-vote Darin’s solution.
Below is a summary of the JavaScript client code. The __RequestVerificationToken is generated by one of Razor’s HTML helpers:
<span>@Html.AntiForgeryToken()</span>
The JavaScript graps the token from the DOM, and POSTs it to a JSON-based Web API service as part of the headers. Phil Haack’s original Preventing CSRF with AJAX implementation demonstrated how to utilize the token when submitted in the headers rather than as part of a form element which is what is expected by the server’s validate method.
$token = $('input[name=""__RequestVerificationToken""]').val(); $.ajax({ url: ..., type: "POST", dataType: "json", contentType: "application/json: charset=utf-8", headers: { __RequestVerificationToken: $token } }).done(function (json) { ... });
One minor note on the above AJAX call, I’m now using the jQuery deferreds/promises. The ‘done’ function in the above is comparable to the ‘success’ function in a ‘classic’ jQuery AJAX call.
Here’s Darin’s solution:
[AttributeUsage(AttributeTargets.Method | AttributeTargets.Class, AllowMultiple = false, Inherited = true)] public sealed class ValidateJsonAntiForgeryTokenAttribute : FilterAttribute, IAuthorizationFilter { public Task<HttpResponseMessage> ExecuteAuthorizationFilterAsync(HttpActionContext actionContext, CancellationToken cancellationToken, Func<Task<HttpResponseMessage>> continuation) { try { var headers = actionContext.Request.Headers; var cookie = headers.GetCookies().Select((c) => c[AntiForgeryConfig.CookieName]).FirstOrDefault(); var token = headers.GetValues("__RequestVerificationToken").FirstOrDefault(); AntiForgery.Validate(cookie != null ? cookie.Value : null, token); } catch { actionContext.Response = new HttpResponseMessage { StatusCode = HttpStatusCode.Forbidden, RequestMessage = actionContext.ControllerContext.Request }; return FromResult(actionContext.Response); } return continuation(); } private Task<HttpResponseMessage> FromResult(HttpResponseMessage result) { var source = new TaskCompletionSource<HttpResponseMessage>(); source.SetResult(result); return source.Task; } }
The heart of this solution is the AntiForgery.Validate method. In the new/Driessen approach this explicitly receives the value of the token from the cookie and the value of the token from the ‘form’ (header). These values are obtained from the attribute’s actionContext. If any step fails, the method returns a “403” (Forbidden).
Once again, if you find this solution useful, please take the time to up-vote Darin’s solution as it’s all his work.
Anti-Forgery with ASP.NET MVC 4 RC
My thanks to Johan Driessen for his useful Updated Anti-XSRF Validation for ASP.NET MVC 4 RC to Phil Haack’s innovative solution Preventing CSRF with Ajax. I’ve written of feetens’ support for anti-forgery here and mabbled’s support here and here. ASP.NET MVC provides good support for anti-forgery protection.
Unfortunately, I’m challenged in getting the same functionality working with the Web API controllers that I’m increasingly preferring. Darin Dimitrov posted what’s evidently a good example of how to achieve comparable functionality with Web API in response to a question about Web API and ValidateAntiForgeryToken but, I believe, his solution does not support the JSON-based AJAX services that prompted Phil’s solution.
I’ve posted a plea for help and will report back if/when I solve this.
The Black Art 4
The series (The Black Art, The Black Art 2, The Black Art 3) continues. I won’t make the mistake again of calling its conclusion.
Programmatic predicate composition (outlined in The Black Art 3) works well, but a point is reached quickly at which the complexity of the resulting OData query exceeds the Azure Data Market service’s threshold. Unfortunately, even something as simple as the following throws the exception:
https://api.datamarket.azure.com/data.gov/Crimes/CityCrime()?$filter=(false or ((((((((false or (City eq ‘Millbrae’)) or (City eq ‘Bayshore’)) or (City eq ‘San Mateo’)) or (City eq ‘West Bear’)) or (City eq ‘Middlefield’)) or (City eq ‘E. Bayshore’)) or (City eq ‘East Bayshore’)) and (State eq ‘California’))) and (Year eq 2008)
This error is:
It struck me that the superfluous “false or” statements in the generated query were adding to this recursion limit. I edited the OData query to remove all of the optimizations that I could see and then the query was successful. In fact, I could provide seemingly arbitrary complexity this way and the queries would work.
The question was, how to optimize the predicate before it was converted to the OData query string. I posted the question to stackoverflow.com and the Microsoft MSDN forums. Microsoft’s Vitek Karas provided a solution which I tweaked and, for explanation purposes, have simplified here:
protected override Expression VisitBinary(BinaryExpression node) { if (node.NodeType == Or || node.NodeType == OrElse) { if (node.Left.IsConstantBool(false)) { return this.Visit(node.Right); } else if (node.Right.IsConstantBool(false)) { return this.Visit(node.Left); } } else if (node.NodeType == And || node.NodeType == AndAlso) { if (node.Left.IsConstantBool(true)) { return this.Visit(node.Right); } else if (node.Right.IsConstantBool(true)) { return this.Visit(node.Left); } } return base.VisitBinary(node); }
The function takes advantage of two facts: that, in a boolean ‘or’, if either parameter is true, the result is the value of the other parameter (i.e. T || _ == _ || T == _), and, in a boolean ‘and’, if either parameter is false, the result is the value of the other parameter (i.e. T && _ == _ && T == _). Satisfyingly (thankfully) this simple optimization is sufficient to permit arbitrarily complex queries to pass muster by the Azure Data Market.
Thanks Vitek!
jQuery Deferred object
I realized I’d introduced a flaw into feetens. The generic code that iterates over multiple dataset services possibly has to (asynchronously) geoencode some of the results. My naïve solution tracked completion of the (synchronous) process of the services but not completion of the spawned requests.
I googled stackoverflow and there are myriad results involving semaphores and the assumption that the code (will always) be single-threaded. Then, I struck gold with a suggestion to consider jQuery.Deferred() and an illuminating post on the IEBlog titled Asynchronous programming in JavaScript with “Promises”. Ironically, at the same time, I was listening to a session on asynchronous programming in ASP.NET as part of the aspconf.
What is it and why is it cool? In essence, it simplifies the creation, use and pipelining of asynchronous requests in JavaScript. If you’re using async (even if only $.ajax) then you should investigate jQuery.Deferred(). In fact, $.ajax is now implemented as a promise and so it’s possibly the easiest way to grasp the pattern.
This is the previous way of invoking $.ajax wrapped in a function that permits ‘success’ and ‘failure’ handlers. It’s fine. It becomes challenging if additional success or failure handlers are needed and when this $.ajax request needs to be composed with others.
$ajax = function (success, failure) { $.ajax({ url: "/echo/json/", success: success, error: failure }); };
Using jQuery.Deferred(), the definition becomes trivial:
$ajax = function () { return $.ajax({ url: "/echo/json/" }); };
The handlers may now be attached when the promise (for this is what’s returned by the $ajax function) is invoked:
$ajax()
.done(success)
.fail(failure);
$ajax()
.done(success)
.fail(failure)
.done(success);
$ajax()
.done($ajax()
.done(success)
.fail(failure))
.fail(failure);
In the first example, we attach a ‘success’ and a ‘failure’ handler. In the second example, we take advantage of the fluent-like API to attach a second handler. In the third example, once the first $.ajax is done, it is invoked a second time. You can see these examples here.
In feetens, the process is a little more involved and includes one scenario, I’ll outline that, I think, is a useful way to coordinate a variable number of async calls. To simulate the async calls, here’s a simple ‘async’ function that implements a promise:
async = function (letter) { var $def = $.Deferred(); if (Math.random() < 0.7) { setTimeout(function () { $def.resolve(letter); }, 5000 * Math.random()); } else { $def.reject(letter); } return $def.promise(); };
If the random number determines the ‘success’ branch, a random duration timeout starts and, when it completes, the promise’s resolve function is invoked (with the ‘letter’). Otherwise, the promise’s reject function is invoked (with the ‘letter’). In the body of my code, I invoke the async function and provide it with success and failure handlers. Both the handlers pull-through the ‘letter’ parameter:
async(letter) .done(function (letter) { // do something }) .fail(function (letter) { // do something });
Finally, I wish to invoke async over an array of letters *but* I wish to proceed when *all* of the functions have completed. Here’s the code:
$.when.apply($, data.map(function (letter) { return async(letter)... })).always(function () { // do something });
The explanation? jQuery.Deferred has a function ‘when’ that supports multiple deferreds. It is called thus “when(deferred1, deferred2, …)”. The code uses JavaScript’s “apply” function to convert an array into a set of arguments that are then applied to when. The array results from the ‘map’ function which, taking each letter in a source array in turn, creates promises for each by calling my ‘async’ function. The ‘always’ function is bound to the ‘when’ and it is invoked when all of the promises have returned as resolved (done) or rejected (fail). Thus, it is invoked when the async processing of the elements in the source array is complete.
Here’s a jsFiddle that shows this in action. It uses KnockoutJS to display the async results as they arrive.
Bug in partial function implementation
I spent the better part of a day debugging a flaw in Resig’s implementation of partial function described in his post Partial Application in JavaScript and my use of which I outlined in my recent post JavaScript “Currying” Functions. It was a particularly pernicious bug for me to resolve but I found the solution in Afshin’s post Partial Application in JavaScript Revisited.
Here is a jsFiddle that highlights the problem. I would not have been able to resolve this were it not for Afshin’s post. I diagnosed down to Resig’s partial function and determined that regardless of how many times a partial application of a function is called, it always uses the initial set of arguments.
In this example (regardless of whether ‘undefined’ is used for the first or second parameter), the first application will be true add5(5)===10 but the subsequent values of the function will always be 10 (regardless of the parameter) and thus the statements would be false (which is incorrect).
add5 = function (x, y) { return x + y; }.partial(5, undefined); add5(5) === 10; add5(6) === 11; add5(7) === 12;
If you look back through the versions of the jsFiddle, you’ll get a better idea of why I was struggling to narrow the bug down. In my code, this bug arises at the end of a long chain of events that result from iterating over a set of customers, batching some of these up for async processing using a double-level of closures and partial function applications. I was also misled by some caching that I perform in my code that appeared to make the bug less common than it should have been.
The solution, of course, is more expansive unit testing but I’ve been lax when it comes to unit testing samples such as this which I assume work. My fault. Here’s the results from a simple QUnit set of tests that prove the point:
- Resig (4, 2, 6)
- Afshin (0, 6, 6)
JavaScript “Currying” Functions
I’m trying to generalize the code that makes call to Azure Data Market services then geolocates and plots the results with Google Maps. Much of this functionality is async with callbacks and I’m using a mixture of curried and partial functions extensively to help with the callbacks.
I’ve been creating “curried” (I’ll use the term curried to cover both curried and partial from here on) functions each time I need one but then found Alex Staveley’s comprehensive post on JavaScript Closures and Currying! today and then stumbled upon John Resig’s Partial Application in JavaScript, both of which provide a general-purpose way to curry or partially apply functions. As a result of these posts, I’ve swapped my approach for theirs because I feel their approach is more elegant and evident.
Here’s an example of what I’ve been writing. ‘plot’ is a function that, given a ‘type’ ({color, radius}) returns a function that, given ‘entity’ and ‘location’, uses a KnockoutJS binding handler to plot the entity on Google Maps.
plot = function (type) { return function (entity, location) { viewModel.mapper.circles.add({ color: type.color, radius: type.radius, lat: location.lat, lng: location.lng }); }; };
I’m using closures to achieve the currying but, why is it curried? Two reasons. Firstly, because the function is used multiple times by several different services each of which applies the circle’s color and radius as constants. So, for example, the first service may be plot({color:”Red”, radius: 5000}) for all its entity/location pairs. Secondly, and more importantly, the function is curried because it is passed to a service that expects the function to only take an entity and a location. Now, this is where things get a little complicated. Here’s another function:
geocode = function (plot, cache, entity) { lopeway.geocode({ address: entity.getAddress(), cache: cache, success: function (location) { plot(entity, location); } }); };
Notice the asynchronous ‘success’ function embedded in this. It calls plot with an entity/location, nothing more. This general-purpose ‘geocode’ function has the minimum information to achieve its goal and circle color and radius are not part of that minimum information. Interestingly, the services that I mentioned above that refine the ‘plot’ function, also refine the ‘geocode’ function since each service may need to use geocoding. The geocoding service makes use of a throttling function that ensures the Google geocoding services is not overriden with requests. The throttler operates on entities only and so the curried version I’ve been using for it is:
geocode = function (plot, cache) { return function (entity) { lopeway.geocode({ address: entity.getAddress(), cache: cache, success: function (location) { plot(entity, location); } }); }; };
Here’s the rub. This code works perfectly but it’s more convoluted and less clear. This second ‘geocode’ function takes some understanding and, when it’s applied in the form geocode(plot, cache), it’s not immediately evident that the result is a function that takes an entity…
Here’s where Alex’s and John’s solutions are better. I can leave the geocode function written as it was in the first example (which, I think, is more clear) and takes 3 parameters but now I can reference its curried forms as:
fn = geocode.curry(plot).curry(cache);
I’ve simply chained two ‘curry’ applications to the original function. The first, applies ‘plot’ and returns a function to which ‘cache’ is applied which returns a function that takes ‘entity’.
Or, in this case, better as:
fn = geocode.partial(plot, cache, undefined);
‘partial’ permits multiple parameters to be applied at once with the ‘undefined’ here representing the parameter that remains free.
In both cases, these more explicitly represent the fact that the function is being curried and, I think, lead to clearer code.
feetens 