Posted by sh1mmer on Jan 6, 2008 in
JavaScript The bookmarklet I made to list out the YUI events on a page is now available as a Firebug extension. You can install the extension from the event lister page.
Please be aware however that auto-updating is not yet implemented, so if you want to keep up with changes to the extension you’ll have to subscribe to the blog, or keep an eye on that page until it is. Once I have auto-updating sorted I’ll put the extension on http://addons.mozilla.org.
I want to thank Steve Souders for his work on YSlow. His documentation in the YSlow code was one of the major things that helped me get this project as far as it is. I hope to help continue improving the rather abysmal state of Firebug documentation so other people can create more extensions to what is one of my favourite web development tools.
Technorati Tags:
yui, yui event lister, firebug, yahoo, web development, debug, yslow, steve souders, firefox, mozilla, javascript, events, bookmarklet
Posted by sh1mmer on Aug 28, 2007 in
JavaScript The Accessibility toolbar for Firefox has a feature for developers that presents a list of the event handler attributes for each element on the page. The problem is that using attributes to set events is nasty and the YUI Event library instead attaches a singleton listener to the window which isn’t shown. This main YUI listener then delegates to YUI Event listeners which are created.
In order to get something like the functionality in the accessibility toolbar for YUI Event library listeners I’ve made a bookmarklet that uses some of the functionality of the YUI Event library. The YUI Event List Bookmarklet will show you a list of all the elements on the page that have listeners attached and what those listeners are. You can also view the functions that will be called when the event fires. It’s perfect for tracking down that elusive listener that’s using event propagation to hook onto stuff.
Technorati Tags:
yui, javascript, yahoo, web development, event listener
Posted by sh1mmer on Jan 26, 2007 in
JavaScript AJAX and AHAH are two of the corner stones of the technology for “Web 2.0″. While most implementations of AHAH are done using AJAX to make them more robust I see them as two differing models. In essence AHAH requires the minimum of client side processing whereas AJAX uses the client for processing as well as rendering.
The reason I find this interesting is because of a conversation we had a my work about how to optimise some AJAX by using either an XML data source or a JSON one. The discussion about the best way to deal with parse trees in the browser made me wonder if most of the “Web 2.0″ site really need it at all.
The implementation of AHAH I like is one which wraps some HTML in a JSON object along with a status code. The application then requests data to render, using the status code to define how it renders it, either as a valid return or as an error. This minimal logic approach avoids the parsing and speed issues on the client, and instead makes the optimisation barrier the HTTP request and the server response time.
I would say that in all but the most hyper-functional of applications the amount of interaction a user does, with the amount of data the server can return in a given request means that this option is most preferable. Really only the spreadsheet, datagrid, etc type application can anticipate the data the user will need next and in volumes to justify using AJAX in it’s purest form.
Technorati Tags:
AJAX, JSON, Javascript, AHAH
Posted by sh1mmer on Jan 14, 2007 in
JavaScript,
Security Simon Willison linking to a post about Google’s Latest Security Hole got me thinking.
According to the article Google allowed someone to gain control of pages on a sub-domain of google.com. Aside from the obvious dumbness of allowing that to happen (surprising given the usual calibre of their people) it raises an interesting point about cookies. Tony Ruscoe was able to gain control of another Google user’s account by having the victim visit the compromised ghs.l.google.com page and reading all his Google cookies with Javascript. He then used the victim’s cookies as the authentication tokens he needed to access the victim’s account himself.
This implies to me that we, as web developers, make some assumptions about trust with the user agent. We assume any user agent with the correct authentication tokens is trustworthy. However, this is obviously not the case. My thought is that when we issue tokens we should look at other factors which isolate one computer from another. The obvious one would be location.
For example, when an HTTP request comes in, we need to know where it came from in order to send a reply. Since we know the IP address of the originating computer (or at least it’s primary upstream NAT address) then why not look all session based authentication to that? In the example above this would have caused the authentication tokens to have failed from the compromised browser because the token was being used from an invalid location. This assumes that your authentication tokens are encrypted to stop tampering, but I would really hope they are anyway.
It wouldn’t be 100% fool proof (what is?), but it would reduce the attack vectors considerably. To compromise a user, the attacker would have be attempting to use the cookies from the same computer (if they can do that, they could probably steal the cookies straight off the hard drive), from the same NAT (not much to do about this case), or have a compromised router some place. If they did have a router upstream from either Google or the victim they could capture the cookies on-route anyway in a regular request. One simple thing would reduce a lot of issues.
Would this cause any problems with users? I don’t think so. The changes associated with an IP address tend to be physical anyway, a different computer, a changed wireless lan connection, etc. In this context it actually makes sense to a user to re-authenticate when they move. The physical aspect is important to help users understand the reason why they are having to authenticate a new access token.
Technorati Tags:
Security, Javascript, cookies, google
Posted by sh1mmer on Dec 23, 2006 in
JavaScript Well, for a while I've been trying to prove that either it is, or isn't, possible to XSS a JSON return which is wrapped in { }.
While it is well known that it is possible to exploit the return of a JavaScript array, I've been trying to establish if it is also possible with generic objects conforming to the JSON standard.
JAVASCRIPT:
-
{
-
"glossary": {
-
"title": "example glossary",
-
"GlossDiv": {
-
"title": "S",
-
"GlossList": {
-
"GlossEntry": {
-
"ID": "SGML",
-
"SortAs": "SGML",
-
"GlossTerm": "Standard Generalized Markup Language",
-
"Acronym": "SGML",
-
"Abbrev": "ISO 8879:1986",
-
"GlossDef": {
-
"para": "A meta-markup language, used to create markup languages such as DocBook.",
-
"GlossSeeAlso": ["GML", "XML"]
-
},
-
"GlossSee": "markup"
-
}
-
}
-
}
-
}
-
}
This is the example JSON provided by json.org. If you encapsulate this directly in <script> tags then browsers will throw an error.
I have tried to overwrite the object constructor in all the major browsers. None of Yahoo's A-grade browsers will call the constructor for these object returns, because of the object exception.
I have come to the conclusion that browsers parse { } because as a script block not an object, but will not parse an actual object without a label. Tim and I were talking about this and agreed that the parser allows [] without a label for the construction of anonymous arrays to make multi-dimensional arrays. Good thinking Batman Tim!
What does all this mean? In effect that means that using a JSON return in as per the example wrapped in { } means it can't be used for XSS. Using a simple array return is still as vulnerable as ever.
Technorati Tags:
AJAX, JSON, Security, Javascript
Posted by sh1mmer on Dec 19, 2006 in
JavaScript While I totally advocate using Firebug sometimes you need a starting point. I've been doing a few things that use prevent default to repress page loads. However, if something fails before the prevent default then it's difficult to debug because the console is cleared when the page reloads. In order to stop this and to give me a starting point for places to put break points I've been using Tamper Data to abort page requests.
Whoops! I don't do Firebug enough credit. Just click on the 'script' tab and select 'Break on all errors' in the options menu. Now it breaks on any and all errors. Sweet.
Posted by sh1mmer on Dec 14, 2006 in
JavaScript Ed at work has written a really awesome post on using PHP to version JavaScript and CSS files into a single versioned include. His post Automatic merging and versioning of CSS/JS files with PHP make this all really trivial. Nice one Ed!
Posted by sh1mmer on Dec 11, 2006 in
JavaScript One day I was bitching about the lack of a way to insert something at an arbitrary point into a list of DOM nodes. "I don't want to walk the DOM, or walk with Dinosaurs, for that matter!" said I, or something equally witty. Steve Webster sick of my whining, no doubt, suggested I write one.
So I did (with a little help from Heilmann).
Here it is in all it's glory
JavaScript:
-
insertAtPosition = function(root, el, pos) {
-
//remove any whitespace nodes
-
for(var i=0,j=root.childNodes.length;i<j ;i++){
-
if(x.childNodes[i]===undefined){break;}
-
if(x.childNodes[i].nodeType===3){
-
x.removeChild(x.childNodes[i]);
-
i--;
-
}
-
}
-
//if the position is out of the current scope of the element
-
if(pos>root.childNodes.length || pos<0) {
-
return false;
-
}
-
// if pos is the same as length then add to the end of the children array
-
if (pos===root.childNodes.length) {
-
root.appendChild(el);
-
}
-
// insert before works for all other cases
-
else {
-
root.insertBefore(el, root.childNodes[pos]);
-
}
-
return true;
-
};