Direct Web Remoting

Yeah, so Bespin a cool editor, and it makes use of lots of bleeding edge tech, (and it's got several annoying bugs - sorry about those). But I think Bespin has potential way beyond just looking nice ... Open source development: You hear about ... [More] project X, use it, and it’s nice, but to use a worn out phrase - there’s an itch to scratch ... So what do you do? Open Source Development Before Bespin You search the project website for the directions to the source control system, you check that you’re up to date with cvs/svn/git/hg/whatever and checkout the source. Next you need to figure out how to build the project with ant/make/maven/paver/rake/whatever, and maybe download new libraries to make the compile clean and you then configure your IDE or editor to the new project. You can then go about editing the code. When you’re done with that you might need to figure out xunit/yunix/zunit to run the unit tests. Then you have to join a mailing list to work out how to send your changes in, which might be a patch or a bundle or a zip or direct commit access. You might discover that you need to sign a CLA so the project knows who you are, so you mess about with printing/signing/scanning/emailing/whatever. And then you’re done. With complex projects there could be lost more to it. While you’re doing this you have no idea what the other developers are doing. Maybe they’re working on a totally different branch. Maybe they’ve done something similar already. Maybe they’re making changes that mean you should try a different approach. It would be good to know because you might be wasting your time. Open Source Development After Bespin You visit Bespin, and elect to edit project X. When you’re done, you click submit, and the project owners get your change. Plus you can see what the project owners are doing with the source, and how your changes fit in. The Power of Bespin For me, what I find interesting about Bespin isn't the tech, it's the lowering of the barriers to entry and the socializing of open development. Virtually no software is perfect, and there are billions of people that are affected by the imperfections. There are hundreds of ways to contribute to any development project, and millions of people who could use their skills to help if only we could find ways to get the sources of help to the problems needing work This application of huge resource to complex problems is what the Internet has always been good at, but so far we've not really done much to help software development. I hope that Bespin can become part of the solution. This isn’t going to become a Bespin blog (that’s here or we're on twitter). Irregular DWR/Ajax/Security programming will return to my blog and twitter feed shortly. [Less]

I’m very excited to be going to work for Mozilla Labs. I have very much enjoyed my time working at SitePen - they are doing awesome work with Dojo and DWR, but with the main development on DWR 3 being done, it's time to move on. SitePen has some ... [More] amazing talent, and it's been a huge privilege for me to have been able to share the ride, so I'm very grateful to Dylan and everyone at SitePen for allowing me to be part of it. I'm not going to be ignoring DWR either, so between me and the excellent team of Mike, Jose, David, Lance and many others I'm sure it has a long future. My new role will be working with Ben, Dion and Kevin on Bespin. You might be able to get hints about Bespin from postings that are around already. Oh, and the name - that might be a clue too. Needless to say I’m excited about the project. More soon. [Less]

Recently: Aaron Boodman - "I'm a big believer in silent autoupdates" PPK/Quirksmode - "I hate automatic updating" Something Aaron didn’t mention - What happens when a silent auto-update breaks something? Anyone that's had to do battle with the ... [More] demo-pixies silently changing something just before an important demo hates the idea that something might be silently altering their rendering engine as they are opening their laptop on-stage. PPK's issue basically comes down to testing older versions - how can I test version X-1, when it's just been replaced by version X. On the one hand with silent auto-update virtually everyone will be on version X, so X-1 isn’t important, however I don't think that removes all need for testing on X-1. Solution? We should have silent auto-update. It makes the Internet safer, and we badly need that. But we should also have a system that keeps old versions around for some period of time with a way for users to revert. Maybe there is then an entry in the help menu that allows users to say 'it broke take me back', and maybe a preference that configures the number of old versions left lying around. I have a suspicion that many corporates turn auto-update off in order to test the updates batches before internal release (or to put it another way - it's a cost saving) Maybe with undoable silent autoupdate they would allow the system to work without getting in the way? I'm a big believer in undoable silent autoupdates. [Less]

DWR version 3.0 The much awaited DWR version 3.0 has reached release candidate 1. What's new? RPC Enhancements Varargs support Method overloading (DWR tries to copy Java's method matching rules) Typed parameters (so you can say new Apple() in ... [More] JavaScript and pass it to the addFruit() method and DWR will instantiate the correct type on the server) Lightweight typed parameters (as above, but by adding $dwrClassName:"Apple", for when you are getting the objects from something else) More natural synchronous XHR (so you can call var reply = Remote.getData() when doing 'Sjax') Improved Marshalling Binary file upload/download (byte[], java.awt.BufferedImage, InputStream etc and FileTransfer can be uploaded from an input type=file, offered for download, or sent to an img) Functions (Store a reference to a JavaScript function on the server for later execution) Objects by Reference (Store a reference to a JavaScript object, and then call methods on that) Locale, Currency (DWR will marshal to and from java.util.Locale and java.util.Currency objects) Reverse Ajax JavaScript can now implement a Java interface (For simple integration with Java Events/Listeners) More scalable Reverse Ajax APIs (See org.directwebremoting.Browser) DOM Manipulation Library (Window and Document can now be manipulated from the server) The server now runs in 3 modes: stateless (New - save memory with no page tracking), passiveReverseAjax (the default) and activeReverseAjax (comet enabled) TIBCO GI Integration Complete set of Reverse Ajax Proxy APIs (So you can manipulate your GI user interface from Java on the server) Dojo Integration Data Store (Keep a server side data store in sync with data in a client browser with both sides able to send updates. The data store also supports paging, sorting and filtering) Packaging Integration (dojo.require all your DWR scripts) Server Support Asynchronous servlet support for Tomcat and Glassfish Improved Spring and Guice support Over the wire JSONP support JSON-RPC support Tech Previews JMS Integration (Publish to the browser directly from JMS) Aptana Jaxer Integration (Zero configuration for trusted environments) Infrastructure SVN (We've moved from CVS to SVN) Related Projects (Our repository contains a set of related projects including a number of demos) CLA (We've been through a legal review and have signed CLAs for dwr.jar) Dojo Foundation (We joined the Dojo Foundation and are now hosted by their servers) Better Documentation (DWR version 1.x had great docs. Version 2.x let things slide a bit, but we've dropped Drupal, and have our own system now) There are also a bunch of things like better logging, error reporting and so on, but the full list would get quite dull. 2 things dropped out that we'd previously talked about: Bayeux Support and Gears Offline integration. We'll get to those, particularly Gears, soon. I'm sure there will be lots of questions about how to use these features. Please don't ask in the comments; join the mailing list and ask there. As we roll out the new documentation system in the next week or so, all the details will be in there, and I'll then come back and link up this blog post. You can download it now. [Less]

If you want to protect yourself from a XSS attack, what characters should you escape? I've seen 2 recommendations: ', ", <, > and & should be converted to &apos;, &quot;, &lt;, &gt;, &amp; Convert anything that isn't ... [More] ASCII alphanumeric to &#xx; I've seen the second recommended more and more recently. Which is best? The argument for escaping all non-ASCII alphanumeric It's a known security tenet that whitelisting is safer than blacklisting. If you're just escaping ', ", <, > and & then you're blacklisting, which isn't as safe as whitelisting. There are some practical examples of how this can play out - <a href="$"> (I'm using $ to represent the injection point. This would probably crop up in a template something like this: <a href="<%= escape(userInput) %>">) If all the escape() function does is to escape ', ", <, > and &, then what if the user entered a data: URL? You could end up with the following output: <a href="data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K">test</a> Which in case you can't do base64 in your head is equivalent to this: <a href="data:text/html;<script>alert('XSS')</script>">test</a> Clearly this is bad - we've let a user XSS us even though we are filtering for XSS. There are many more examples that are similar. The argument for escaping only ', ", <, > and & The bad news is that more filtering does not help. If we enhance our escape function to encode every non-alpha, then we would get the following output: <a href=data&#58;text&#47;html&#59;base64&#44;PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K>test</a> Here's the bad news - the above works. (Look: test (if this script gets into your RSS aggregator, then you need a new RSS aggregator.)) Adding the extra filtering has had the following effect: It's hidden the hole, so now we're less likely to notice it, and fall in. It's wasted bandwidth So how do we keep ourselves clear of XSS attacks? The solution is to understand about insertion points. The following insertion points, are ones that I believe are safe if ', ", <, > and & are escaped: <div>$</div> (Where div could be p, h*, li, etc - things expecting textual content) <input value="$" ...> (i.e. somewhere else that expects textual content) <script>str = "$";</script> (needs different escaping rules) I think it's likely that virtually any other insertion point is likely to be dangerous. Some examples: <script>$</script> (no amount of escaping will protect you, prepare to die) <div $> (there are countless events we could latch into, including several non-standard, hard to find ones) <div style="$">... (JavaScript pops up in CSS in many places like width:expression(script_here)) <a href="$">... (The example we used above) <img src="$"> (For similar reasons) etc. The key it to understand the environment into which we are allowing injection. The trend for separating content, style and action into separate files is good because it more clearly defines the environment, but that doesn't stop HTML from being able to embed CSS. I once saw some code that was JSP containing Java containing HTML containing CSS and JavaScript containing SQL all on one line. An environment so confused that it contained it's very own security hole built right in. Filtering in DWR DWR version 3 is nearly cooked, and our escaping functions use the simpler escaping system of just escaping ', ", <, > and &. If anyone knows of any attack that a broader filtering system would protect people from, then please comment. [Less]