While reading about ASP.NET Ajax toolkit I stumbled upon the term AJAH. What is it and how is it different from Ajax?
AJAH is someone's attempt to come up with a new buzzword to mean "Having JavaScript make an HTTP request and get back a blob of HTML instead of a blob of XML".
Since Ajax has been taken to mean "Having JavaScript make an HTTP request and get back anything at all" (most often JSON these days, but a blob of HTML is also very common), it is a pretty pointless attempt.
Quote taken from here.
With true AJAX, a call is made to the
server, the nicely formatted data is
returned and the client application
extracts the data from the xml, and
replaces whatever elements need to be
replaced on a page. With AJAH, a glob
of html is returned and slapped into
the page.
So basically, AJAH returns pure HTML, AJAX returns formatted data, such as JSON that is dealt with with by the client scripts.
Personally, I think this just looks like a term only a few developers have used. It's definitely not mainstream.
Related
I have solved a problem with a solution I found here on SO, but I am curious about if another idea I had is as bad as I think it might be.
I am debugging a custom security Attribute we have on/in several of our controllers. The Attribute currently redirects unauthorized users using a RedirectResult. This works fine except when calling the methods with Ajax. In those cases, the error returned to our JS consists of a text string of all the HTML of our error page (the one we redirect to) as well as the HTTP code and text 200/OK. I have solved this issue using the "IsAjaxRequest" method described in the answer to this question. Now I am perfectly able to respond differently to Ajax calls.
Out of curiosity, however, I would like to know what pitfalls might exist if I were to instead have solved the issue by doing the following. To me it seems like a bad idea, but I can't quite figure out why...
The ActionExecutingContext ("filterContext") has an HttpContext, which has a Request, which in turn has an AcceptTypes string collection. I notice that on my Ajax calls, which expect JSON, the value of filterContext.HttpContext.Request.AcceptTypes[0] is "application/json." I am wondering what might go wrong if I were to check this string against one or more expected content types and respond to them accordingly. Would this work, or is it asking for disaster?
I would say it works perfect, and I have been using that for years.
The whole point use request headers is to be able to tell the server what the client accept and expect.
I suggest you read more here about Web API and how it uses exactly that technique.
I'm developing a web-site with ASP.NET 4.0. Some pages need to get data from the server via AJAX requests (for instance, a list of items, sorted or/and filtered by a parameter). And there I can see two options for templating:
1) AJAX handler get data from database and templates it with Mustache. Returns html code ready to display to the end user.
2) AJAX handler get data from database and sends it as JSON. Javascript code formats data with Mustache on the client-side.
My question is what will perform faster?
I don't think your question can be answered without testing, but I'm not sure the difference would be really significant. However, raw speed notwithstanding, I would go probably for option 2:
HTTP traffic will certainly be lighter with your JSON-formatted data rather than a complete HTML output (this is generally better),
The data can still be handled dynamically on the client side
If your website is designed as a "web application", with an emphasis on client-side processing, this is the way to go. But on the other hand, if you think of your output as something mainly static, it is probably simpler to keep all the work on the server side.
I have many situations where I make AJAX call to server side to get some data. My question is:
Is it better to get the data back simply as JSON or XML, but then I need to use javascript to do all the input and it is impossible to use my server side variables of the user in this javascript (am I wrong here) or is it better to get back not only the database data but the whole HTML.
The first way would be to get back from AJAX call only the content of the table cells and do the whole table generating HTML in javascript. The second would be to call AJAX and get the whole HTML with the data in back from server side.
I am using the second approach now because it is easier for me to program in server side language, but I see two problems using this approach:
Instead of getting only the data I get whole HTML back, which means for example that I am loading too much data every time instead of generating it on client.
The data that I get back is only good for this particular "project", because it is already "formatted" with HTML code. If I would get the JSON raw data, I could reuse the serverside AJAX code to do something else with this data on some other page.
What is the best practice here?
Do not attempt to get HTML or any markup from server to display on the screen. This is a bad practice.
Also, I would prefer JSON to XML.
EDIT:
http://api.jquery.com/load/
I am looking into utilizing Google Maps API to do some geocoding. I want to implement client side geocoding, to remove the possibility of request limitation.
I need to do some fairly complex logic on the result set, and I would prefer to do that in C# as it is a ASP.NET MVC application. However part of that logic is possibly makeing subsequent follow up requests and that again would require JavaScript.
So, my first thought is to make a service in my application to pass JSON results to and certain return types to trigger the subsequent request. That seems a little convoluted and want to know from the community if this seems like the best approach and if there are any libraries/third party tools that can help handle this situation.
I've an app that does something similar, with the complexity somewhat decoupled by using standardized events (within this app, not a W3 standard or anything)
Client uses native geolocation, SimpleGeo and Google Loader to guess where the user is and AJAX's that to the server.
Server uses client data, MaxMind, and user preferences to decide where to treat the user as being.
Server response is generic event data (as JSON response) that is converted by a generic AJAX response handler into one or more events triggered against the body element.
Depending on the page, various listeners are bound to the events and or namespaces (see jQuery namespaced events) and they handle the updated location events, e.g., getting different weather data, changing local search results
Some of those listeners in turn trigger other AJAX requests, the responses to those may also carry generic events to triggered...
This way there's no sequential code I have to write, i.e., I can add or remove behaviors (simple or complex) without changing anything else. jQuery Events are all I use, really nothing much to it after you decide how you'll pattern things.
Let me know if that's interesting to you and you want me to expand or clarify a part of it.
You may want to try this API:
http://code.google.com/apis/maps/documentation/geocoding/
It's far more REST like - no Javascript required. May work better with C#
In the end I found the best solution was to do as I stated in my question. Pass the JSON object to controller, do work, then return. Worked pretty well.
I have looked through lots of Posts and have not been successful in determining how to get rid of the pesky d in the response coming from my asmx web service, as in {"d":{"Response":"OK","Auth-Key":"JKPYZFZU"}}.
This is being created by my class 'public Dictionary UserDevice' by returning the Dictionary object.
I would be perfectly happy if the damn thing just wouldn't put it all into the d object!
Basically JSON array notation ['hello'] is valid JavaScript by itself whereas JSON object notation {'d': ['hello'] } is not by itself valid JavaScript. This has the consequence of the array notation being executable which opens up the possibility of XSS attacks. Wrapping your data in an object by default helps prevent this.
You can read more about why it's there in a post by Dave Ward. (edit: as pointed out by #user1334007, Chrome tags this site as unsafe now)
A comment by Dave Reed on that article is particularly informing:
It’s one of those security features that has a very easy to
misunderstand purpose. The protection isn’t really against
accidentally executing the alert in your example. Although that is one
benefit of ‘d’, you’d still have to worry about that while evaluating
the JSON to convert it to an object.
What it does do is prevent the JSON response from being wholesale
executed as the result of a XSS attack. In such an attack, the
attacker could insert a script element that calls a JSON webservice,
even one on a different domain, since script tags support that. And,
since it is a script tag afterall, if the response looks like
javascript it will execute as javascript. The same XSS attack can
overload the object or array constructors (among other possibilities)
and thereby get access to that JSON data from the other domain.
To successfully pull that off, you need (1) a xss vulnerable site
(good.com) — any site will do, (2) a JSON webservice that returns a
desired payload on a GET request (e.g. bank.com/getaccounts), (3) an
evil location (evil.com) to which to send the data you captured from
bank.com while people visit good.com, (4) an unlucky visitor to
good.com that just happened to be logged into bank.com using the same
browser session.
Protecting your JSON service from returning valid javascript is just
one thing you can do to prevent this. Disallowing GET is another
(script tags always do GET). Requiring a certain HTTP header is
another (script tags can’t set custom headers or values). The
webservice stack in ASP.NET AJAX does all of these. Anyone creating
their own stack should be careful to do the same.
You are probably using some kind of framework that automatically wraps your web service json responses with the d element.
I know that microsoft's JSON serializer adds the d on the server side, and the client-side AJAX code that deserializes the JSON string expects it to be there.
I think jQuery works this way too.
You can read a little more about this at Rick Strahl's blog
And there is a way for you to return pure json (without the 'd' element) using the WCF "Raw" programming model.