Implementing AJAX-based client-side apps without JSON

Michael

Has anyone had any success with this using the Convio API? Because the host name cannot be your own custom host name (if you have one), has anyone had any success in this area?

Some ideas that, if run as a pure client-side application, perhaps from within the Convio CMS for example, where this is no server-side proxy capability (to my knowledge), or as packaged widgets you want your constituents to post on their personal websites without any server-side application support:

1. A custom donation form that self populates with user's data if, after the user enters their email address (or other information), they exist but are not already authenticated. (really, this would be a script attached to your standard donation form, not something extra special that isn't in Convio now)

2. Same above with Advocacy actions...

3. Any sort of integration with external applications, either on your website or another vendors, where you want the user to stay on Convio. An example might be a comments/blog field on your donation or advocacy form that, when the donation is submitted, actually posts the comment to a blog or blog comment section, or message board thread or whatever, but some peice of data required for the remote site is in Constituent360, but not entered into the donation form (Convio user name, maybe).

4. A flash application sitting on a Convio-hosted page that pulls some set of data dynamically out of Convio -- say a tell-a-friend chain (you told 3 friends, they told 7, they told 30... etc).

If you write your component such that it can accept JSON responses... you're ok, since thankfully JavaScripts can be called cross-domain. But if, say, you're using a store-bought component and you don't know how and/or can't afford to pay someone to modify it and it only does traditional AJAX (that is -- takes XML response data only). The Convio API will not be useful.

I'm just curious if anyone has happened to run into this yet, and if so, how they got around it. My goal is to create completely client-side applications that don't rely on any particular server platform to operate...

-mike

David Hart

I believe that you're referring to JSONP (JSON with padding) which is a convention where the server will return the response as wrapped inside of a javascript method invocation. The client HTML then injects a <script> tag into the document to invoke the remote method. We evaluated supporting JSONP when we first came out with the Open APIs and decided that we shouldn't support it. Some of the issues that you run into are:

• You have to support access via an HTTP GET method, which isn't semantically correct for many of our methods. You should not be applying an update using a GET method.

• You get very exposed if you rely solely on cookie-based authentication. For example, once a user has logged in at your site, a malicious site could make a request to retrieve information and because the user's browser already had a session cookie it would be allowed.

There are cases where JSONP makes perfect sense though. If you look at the Google APIs, they are typically just retrieving non-personalized data so neither of the issues I raise is relevant.

Right now, the Open APIs are well-suited for designing a custom UI on top of the underlying functionality that is hosted on a Convio site and less well-suited for uses on other sites. The two things that we are doing to address that are creating more APIs that fall into the same general family as the Google ones (reading non-personalized data) and working on the javascript API that addresses the crossdomain access issue in a more secure fashion.

Michael

DavidHart :

I believe that you're referring to JSONP (JSON with padding) which is a convention where the server will return the response as wrapped inside of a javascript method invocation. The client HTML then injects a <script> tag into the document to invoke the remote method. We evaluated supporting JSONP when we first came out with the Open APIs and decided that we shouldn't support it. Some of the issues that you run into are:

• You have to support access via an HTTP GET method, which isn't semantically correct for many of our methods. You should not be applying an update using a GET method.

• You get very exposed if you rely solely on cookie-based authentication. For example, once a user has logged in at your site, a malicious site could make a request to retrieve information and because the user's browser already had a session cookie it would be allowed.

There are cases where JSONP makes perfect sense though. If you look at the Google APIs, they are typically just retrieving non-personalized data so neither of the issues I raise is relevant.

Right now, the Open APIs are well-suited for designing a custom UI on top of the underlying functionality that is hosted on a Convio site and less well-suited for uses on other sites. The two things that we are doing to address that are creating more APIs that fall into the same general family as the Google ones (reading non-personalized data) and working on the javascript API that addresses the crossdomain access issue in a more secure fashion.

So, what prevents people from simply writting their own server-side proxy application and making it available for client-side use? Sure, it would hide the admin credentials, but the "server-side-only" apis would suddenly be made available as client-side tools. You would even be able to create mappings in the proxy for JSONP...

Jeff Mills

Michael :

So, what prevents people from simply writting their own server-side proxy application and making it available for client-side use? Sure, it would hide the admin credentials, but the "server-side-only" apis would suddenly be made available as client-side tools. You would even be able to create mappings in the proxy for JSONP...

If by "people" you refer to the staff of Convio clients building customizations, then the answer is that there are no technical barriers to doing this, but there may limitations to what the proxy can do. The limitation is that for methods accessing sensitive information (getting or updating a user's profile, for example), you must authenticate the user. They may have logged in to the Convio system, but the browser is not going to send that session cookie to your site and that is the only thing that confirms who the user is. You can't simply trust an email address or user name that gets sent from the browser, either.

If by "people" you refer to malicious hackers, they cannot do this (create an attack proxy server behind their attack web page) because the server's IP address must be registered in the configuration settings of the Convio powered site.

If you are considering providing a JSONP front-end to a server, I caution you to first fully understand the security vulnerabilities that can be created when combining JSONP with cookie-based authentication to access sensitive information. Of particular interest is cross-site request forgery (CSRF). A search of "JSONP CSRF cookie" should provide some relevant reading.