I'm looking for a simple example of a Node/Express/Jade page being updated using an Ajax call with both the client and server side code.
I'm having a bit of trouble putting it all together in my head.
There are great many ways this could be done and it's not immediately apparent which approach you want to take.
I suppose the simplest scenario would be to add some client-side logic to fetch pieces of html from the server and update the client. This is easily achieved using jQuery (put it inside a document ready block to wire up the event):
$('#button').click(function() {
$.get('/some/url', {foo: 42}, function(result) {
$('#target').html(result);
}
}
This way all your html is generated on the server and you simply fetch and insert it into the page as needed.
You could also fetch json from the server and render the html on the client, but that is one of the alternative approaches. I highly recommend giving TodoMVC a look - it's a todo-list application with many different implementations (each using a different framework) and therefore a great learning resource for the various approaches and helper libraries.
I'd also recommend the Hands-on Node.js book. It will help you understand routing and how to get started with Node.
Related
Let's say I want to build a web app which would use templates in the form similar to the following:
<h1>
{ status_text[step] }
</h1>
<progress max="10" value="{ value[step] }">
</progress>
In other words, let's say that I have lists value[] and status_text[], change only the variable step over time and want the form to reflect these changes in the real-time (ideally, even without sending a notification from the code that changes step, so that I can use current_time instead of some artificial step). What technology should I use to implement such behaviour in the most elegant way? (for the main language, I'd prefer using Python but JS/PHP would also work if there's no Python-related solution)
Thanks in advance for any advice.
These kinds of task are always accomplished in the client side, In other words in JavaScript.
No matter you use PHP or Python for your backend logic, you need JavaScript to do that.
That said, if you want to use pure JavaScript or a library like jQuery, you will have to trigger an event on every change of the progress and update the value of the h1 Element. I don't think this is the best solution for you.
So I suggest you using AngularJs. it's one of the leading web development technologies. AngularJs data binding allows you to accomplish this very easily. No need to trigger events or any extra work. if you're interested in AngularJs, here is a link to get started.
I am using dajax for ajax in my django app.
After getting some data from database I create list of <li> elements in my python ajax.py and assign it with dajax to inner html of some container. Like this:
#dajaxice_register
def get_transactions(request):
dajax = Dajax()
transactions = get_transactions()
dajax.assign('#transactions', 'innerHTML', ''.join(transactions))
return dajax.json()
What is considered best practice? Returning html from server or returning json and then creating html in script?
I would return JSON from the server and bind that to the DOM using JavaScript. That way you're keeping concerns separate, and also returning the minimum amount of data from the server.
Always returning JSON helps to create a services oriented architecture with a good separation between your view and your controller (and model).
With this approach, you can have a pure-HTML UI and a REST API to retrieve datas from server.
I think it's a good practice, but it's probably better for Web Application and not for generic websites.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why do people put code like “throw 1; <dont be evil>” and “for(;;);” in front of json responses?
I found this kind of syntax being used on Facebook for Ajax calls. I'm confused on the for (;;); part in the beginning of response. What is it used for?
This is the call and response:
GET http://0.131.channel.facebook.com/x/1476579705/51033089/false/p_1524926084=0
Response:
for (;;);{"t":"continue"}
I suspect the primary reason it's there is control. It forces you to retrieve the data via Ajax, not via JSON-P or similar (which uses script tags, and so would fail because that for loop is infinite), and thus ensures that the Same Origin Policy kicks in. This lets them control what documents can issue calls to the API — specifically, only documents that have the same origin as that API call, or ones that Facebook specifically grants access to via CORS (on browsers that support CORS). So you have to request the data via a mechanism where the browser will enforce the SOP, and you have to know about that preface and remove it before deserializing the data.
So yeah, it's about controlling (useful) access to that data.
Facebook has a ton of developers working internally on a lot of projects, and it is very common for someone to make a minor mistake; whether it be something as simple and serious as failing to escape data inserted into an HTML or SQL template or something as intricate and subtle as using eval (sometimes inefficient and arguably insecure) or JSON.parse (a compliant but not universally implemented extension) instead of a "known good" JSON decoder, it is important to figure out ways to easily enforce best practices on this developer population.
To face this challenge, Facebook has recently been going "all out" with internal projects designed to gracefully enforce these best practices, and to be honest the only explanation that truly makes sense for this specific case is just that: someone internally decided that all JSON parsing should go through a single implementation in their core library, and the best way to enforce that is for every single API response to get for(;;); automatically tacked on the front.
In so doing, a developer can't be "lazy": they will notice immediately if they use eval(), wonder what is up, and then realize their mistake and use the approved JSON API.
The other answers being provided seem to all fall into one of two categories:
misunderstanding JSONP, or
misunderstanding "JSON hijacking".
Those in the first category rely on the idea that an attacker can somehow make a request "using JSONP" to an API that doesn't support it. JSONP is a protocol that must be supported on both the server and the client: it requires the server to return something akin to myFunction({"t":"continue"}) such that the result is passed to a local function. You can't just "use JSONP" by accident.
Those in the second category are citing a very real vulnerability that has been described allowing a cross-site request forgery via tags to APIs that do not use JSONP (such as this one), allowing a form of "JSON hijacking". This is done by changing the Array/Object constructor, which allows one to access the information being returned from the server without a wrapping function.
However, that is simply not possible in this case: the reason it works at all is that a bare array (one possible result of many JSON APIs, such as the famous Gmail example) is a valid expression statement, which is not true of a bare object.
In fact, the syntax for objects defined by JSON (which includes quotation marks around the field names, as seen in this example) conflicts with the syntax for blocks, and therefore cannot be used at the top-level of a script.
js> {"t":"continue"}
typein:2: SyntaxError: invalid label:
typein:2: {"t":"continue"}
typein:2: ....^
For this example to be exploitable by way of Object() constructor remapping, it would require the API to have instead returned the object inside of a set of parentheses, making it valid JavaScript (but then not valid JSON).
js> ({"t":"continue"})
[object Object]
Now, it could be that this for(;;); prefix trick is only "accidentally" showing up in this example, and is in fact being returned by other internal Facebook APIs that are returning arrays; but in this case that should really be noted, as that would then be the "real" cause for why for(;;); is appearing in this specific snippet.
Well the for(;;); is an infinite loop (you can use Chrome's JavaScript console to run that code in a tab if you want, and then watch the CPU-usage in the task manager go through the roof until the browser kills the tab).
So I suspect that maybe it is being put there to frustrate anyone attempting to parse the response using eval or any other technique that executes the returned data.
To explain further, it used to be fairly commonplace to parse a bit of JSON-formatted data using JavaScript's eval() function, by doing something like:
var parsedJson = eval('(' + jsonString + ')');
...this is considered unsafe, however, as if for some reason your JSON-formatted data contains executable JavaScript code instead of (or in addition to) JSON-formatted data then that code will be executed by the eval(). This means that if you are talking with an untrusted server, or if someone compromises a trusted server, then they can run arbitrary code on your page.
Because of this, using things like eval() to parse JSON-formatted data is generally frowned upon, and the for(;;); statement in the Facebook JSON will prevent people from parsing the data that way. Anyone that tries will get an infinite loop. So essentially, it's like Facebook is trying to enforce that people work with its API in a way that doesn't leave them vulnerable to future exploits that try to hijack the Facebook API to use as a vector.
I'm a bit late and T.J. has basically solved the mystery, but I thought I'd share a great paper on this particular topic that has good examples and provides deeper insight into this mechanism.
These infinite loops are a countermeasure against "Javascript hijacking", a type of attack that gained public attention with an attack on Gmail that was published by Jeremiah Grossman.
The idea is as simple as beautiful: A lot of users tend to be logged in permanently in Gmail or Facebook. So what you do is you set up a site and in your malicious site's Javascript you override the object or array constructor:
function Object() {
//Make an Ajax request to your malicious site exposing the object data
}
then you include a <script> tag in that site such as
<script src="http://www.example.com/object.json"></script>
And finally you can read all about the JSON objects in your malicious server's logs.
As promised, the link to the paper.
This looks like a hack to prevent a CSRF attack. There are browser-specific ways to hook into object creation, so a malicious website could use do that first, and then have the following:
<script src="http://0.131.channel.facebook.com/x/1476579705/51033089/false/p_1524926084=0" />
If there weren't an infinite loop before the JSON, an object would be created, since JSON can be eval()ed as javascript, and the hooks would detect it and sniff the object members.
Now if you visit that site from a browser, while logged into Facebook, it can get at your data as if it were you, and then send it back to its own server via e.g., an AJAX or javascript post.
I'm making a pretty standard AJAXy (well, no XML actually) web page. The browser makes a bunch of API queries that return JSON to run the site. The problem is, I need to add to the API interface each time the page needs to do something new. The new API interface is usually little more than a database query followed by mapping the returned objects to JSON.
What I'd like to do is to get rid of all that server-side duplication and just have the page make database requests itself (using the model interface), but in a way that is safe (i.e. just read only ones). I think this would amount to an interface for constructing Q objects using JSON or something like that, and then send that up to the server, run the query, and return the results. Before I go making my own half-broken architecture for this, I'm wondering if this has already been done well. Also, is this even the best way to go about eliminating this duplication?
Thanks
Search multiple fields of django model without 3rd party app
Django SQL OR via filter() & Q(): Dynamic?
Generate a django queryset based on dict keys
Just replace with operator.and_ where appropriate.
I want to use Wicket to build an application, but I have some designers that would like to write/maintain the javascript, and they basically expect 1 JS-segment per page, and a global JS-file.
I think the most natural way to add javascript in wicket is to add it per component (not per page), which would create problems for those designers (fractioned javascript, and having to write it in java-files). Is there a better way to solve this?
(of course, I expect things to work after a partial refresh.)
And a second (related) thing they'd like (and I'd like actually) is the possibility to request information in JSON-format through a static link , is this possible in Wicket?
I started with JSON by making my wicket pages return the JSON, but quickly realized there are better tools for the job, especially if you will have a full web services layer. If you just need a little JSON here and there, always via a GET, then sure, just make a Wicket page.
I ended up using Jersey with Jackson alongside of Wicket. Jersey simplifies the configuration of URLs that can do different things with different http methods (GET/POST/PUT/DELETE), as well as easily parsing query strings, etc. I'd consider going this route for heavier JSON needs.
You can easily run both Wicket and Jersey in the same web application with a little web.xml configuration.
Wicket's built in AJAX support is always stateful and thus accessed with changing URLs. If your designers aren't planning to use Wicket's JS library, it's pretty straightforward to mount a JSON page:
public class JsonReturningPage extends WebPage {
public JsonReturningPage(PageParameters params) {
String json = "{foo: 4711}";
IRequestTarget t = new StringRequestTarget("application/json", "UTF-8", json);
getRequestCycle().setRequestTarget(t);
}
}
Alternatively, you could also implement your own AbstractRequestTargetUrlCodingStrategy to directly return an IRequestTarget from IRequestTarget decode(RequestParameters params) and mount it in your application.
Regarding JS files, I'd try to educate them to use one file per component. This certainly has the advantage of less copy-paste code and simpler maitenance. Additionally, I'd certainly discourage JS in Java code. It's normally only needed to pass data or config to JS , either as variable definitions or method calls. As this data is typically in Java and JS is written by designers, it's time for designers and programmers to team up.
Quick answer to your second question is yes it is possible. Use bookmarkable links to access a resource that returns JSON data.
You can easily use the following code to dynamically communicate with Wicket:
AbstractDefaultAjaxBehavior callme = new AbstractDefaultAjaxBehavior(){
#Override
protected void respond(AjaxRequestTarget target) {
}
};
page.add(callme);
//From any ajaxrequesttarget you can simply append the following code:
target.appendJavascript("wicketAjaxGet('"+callme.getCallbackUrl()+");");
This way you can have an ajaxlink etc... that will transfer the ajaxrequest to the Wicket side. If you want to pass data (though a static link doesn't sound like that) do the following:
"wicketAjaxGet('"+callme.getCallbackUrl()+"&x='+value_to_pass_back''";
//to Read the value in the respond:
String x = RequestCycle.get().getRequest().getParameter("x");
So the url to the callback is dynamically generated (as the callback url is specific to the session) but it is formed like any other url....
To me this is 10 times simpler than building a JSON system on top of wicket instead of using the one built into it.... I use this all the time and it works great for me at least. If your solution is different/better I would like to know why perhaps.