Yahoo Pipes is really smart mashup engine, which only giant Yahoo can afford to offer. I thought it's great service because it had democratized mashup a little more than before. But I became very excited when I noticed they are actually offering browser-direct external connectivity. Yes it's known as JSONP.
This is a simple pipe, provided by http://kentbrewster.com/badger, which accepts RSS URL input and generates output in JSON(P) format.
http://pipes.yahoo.com/pipes/zIQi0Iy72xGJ3NMhJhOy0Q/run?_render=json&s=http%3A%2F%2Fpersonalized20.blogspot.com%2Ffeeds%2Fposts%2Fdefault%3Falt%3Drss&_callback=handleFeeds
Test JSONP from Here.
Showing posts with label json. Show all posts
Showing posts with label json. Show all posts
Sunday, February 25, 2007
Thursday, October 26, 2006
JSONRequest by Douglas Crockford
Douglas Crockford is now considering a new native JavaScript Object. It's called "JSONRequest", like XMLHttpRequest.
http://ajaxian.com/archives/jsonrequest-proposal
I read the proposal a little, and found that it is eliminating cookie information in its request header.
http://www.json.org/JSONRequest.html
By ignoring cookies, this new crossdomain request approach might become safe, but on the other hand it throws aside a chance to enable personalized mashup. For example, if you wish to embed your e-mail inbox list in your favorite portal service, JSONRequest can't do that because they won't carry any cookies.
I think it might be better to have opt-in mechanisms for both remote services and end users. When considering that almost all ajax applications are now regarding JSON as only in the same domain, so opt-outing (like referer-based JSONP access control; this technique is used here!) is rather unsafe in this case.
Anyway, this is a new proposal, it may take some years to be embedded in almost all our browsers. I hope this opinion could reach him (or some communities) in some way or other.
http://ajaxian.com/archives/jsonrequest-proposal
I read the proposal a little, and found that it is eliminating cookie information in its request header.
http://www.json.org/JSONRequest.html
JSONRequest does not send or receive cookies or passwords in HTTP headers. This avoids false authorization situations. Knowing the name of a site does not grant the ability to use its browser credentials.
By ignoring cookies, this new crossdomain request approach might become safe, but on the other hand it throws aside a chance to enable personalized mashup. For example, if you wish to embed your e-mail inbox list in your favorite portal service, JSONRequest can't do that because they won't carry any cookies.
I think it might be better to have opt-in mechanisms for both remote services and end users. When considering that almost all ajax applications are now regarding JSON as only in the same domain, so opt-outing (like referer-based JSONP access control; this technique is used here!) is rather unsafe in this case.
Anyway, this is a new proposal, it may take some years to be embedded in almost all our browsers. I hope this opinion could reach him (or some communities) in some way or other.
Friday, September 01, 2006
JSONP Private Calendar Mashup with Simile Timeline
I've created interesting demo to show how Personalized Web 2.0 services can be used in mashup application.
http://www.geocities.jp/stormriders999/timeline.html
I'm using MIT Simile Timeline for dynamic user interface.
You'll see that your own private schedule data in Google Calendar is mashuped, only if you granted us to acess them.
Yes, it is actually personalized service for you.
http://www.geocities.jp/stormriders999/timeline.html
I'm using MIT Simile Timeline for dynamic user interface.
You'll see that your own private schedule data in Google Calendar is mashuped, only if you granted us to acess them.
Yes, it is actually personalized service for you.
Wednesday, August 30, 2006
Personalized JSONP - Google Calendar JSON Proxy Service
Google Account Authentication API and Google Calendar GData API enable us to integrate private schedule information with our applications, but they still requires us to deal with their own authentication protocol and host the program in some application server infrastructure.
Although it is read-only access, we can lookup remote feeds directly from browsers if it is provied in JSON style. JSONP is a well-known technique for this kind of JSON remoting.
But we currently don't have any JSON feeds in personalized contents, as far as I know. All JSON feeds in the internet are public - not personalized, accessible from everyone in the world.
Maybe it's because there're some security/privacy concerns. But I'm currently thinking that it would be OK to feed private data in JSON when some appropriate opt-in/out mechanizm is provided.
So, I've implemented JSON feed services for private data - Google Calendar schedule. Now 3rd party applications can get visitors' private calendar information so easily, as far as it is allowed to do that by them.
Please check out the site bellow :
Google Calendar JSON Proxy Service
http://gcal2json.ning.com/
Also there's a sample client application program.
http://www.geocities.jp/stormriders999/gcal_json_client_sample_e.html
Do you think this is really a good personalized web 2.0 service, don't you?
Although it is read-only access, we can lookup remote feeds directly from browsers if it is provied in JSON style. JSONP is a well-known technique for this kind of JSON remoting.
But we currently don't have any JSON feeds in personalized contents, as far as I know. All JSON feeds in the internet are public - not personalized, accessible from everyone in the world.
Maybe it's because there're some security/privacy concerns. But I'm currently thinking that it would be OK to feed private data in JSON when some appropriate opt-in/out mechanizm is provided.
So, I've implemented JSON feed services for private data - Google Calendar schedule. Now 3rd party applications can get visitors' private calendar information so easily, as far as it is allowed to do that by them.
Please check out the site bellow :
Google Calendar JSON Proxy Service
http://gcal2json.ning.com/
Also there's a sample client application program.
http://www.geocities.jp/stormriders999/gcal_json_client_sample_e.html
Do you think this is really a good personalized web 2.0 service, don't you?
Thursday, August 10, 2006
del.icio.us network JSON
del.icio.us has released network badge.
And also we can get JSON data.
http://del.icio.us/feeds/json/network/stomita
JSONP is also supported.
http://del.icio.us/feeds/json/network/stomita?callback=handleNetwork
This feature is not officially announced, though.
And also we can get JSON data.
http://del.icio.us/feeds/json/network/stomita
JSONP is also supported.
http://del.icio.us/feeds/json/network/stomita?callback=handleNetwork
This feature is not officially announced, though.
Friday, June 02, 2006
Google AJAX Search and JSON Web Sevice Calling
In this blog I've mentioned about remoting technology using JSON in dynamic script loading (JSONP). It's great because it doesn't require any app server for mashuping services, and scales well.
Among major service providers, first, del.icio.us noticed that and widely introduced for the developers, and then Yahoo implemented same feature but even more sophisticated one. Amazon's xslt feature enables same service. However, the giant google didn't have any service interface for browser applications (except Google Maps) so far.
But finally they introduced 'Google AJAX Search'.
This enables you to embed Ajax-style search box in your site. No proxy server is needed. Static html would be enough to host the service.
I've checked how the Ajax search is working, and found that they are also using JSON with padding technique. Here is a url that is used in background communication (be sure that it is not XMLHttpRequest call!) :
http://www.google.com/uds/GwebSearch?callback=GwebSearch.RawCompletion&lstkp=0&context=0&rsz=small&hl=ja&q=Google&key=internal-documentation&v=0.1
This is a good news for me because I can add this google service to my JSON with padding test page. I'm offering Yahoo, Amazon, del.icio.us, and generic rss2json service test. But while implementing Google's JSONP test, I found that the response interface is a little different from others. So I've slightly modified JSONP stub javascript class with caution, not to affect other services.
This is my JSON with padding test page.
http://www.geocities.jp/stormriders999/jsontest.html
Among major service providers, first, del.icio.us noticed that and widely introduced for the developers, and then Yahoo implemented same feature but even more sophisticated one. Amazon's xslt feature enables same service. However, the giant google didn't have any service interface for browser applications (except Google Maps) so far.
But finally they introduced 'Google AJAX Search'.
This enables you to embed Ajax-style search box in your site. No proxy server is needed. Static html would be enough to host the service.
I've checked how the Ajax search is working, and found that they are also using JSON with padding technique. Here is a url that is used in background communication (be sure that it is not XMLHttpRequest call!) :
http://www.google.com/uds/GwebSearch?callback=GwebSearch.RawCompletion&lstkp=0&context=0&rsz=small&hl=ja&q=Google&key=internal-documentation&v=0.1
This is a good news for me because I can add this google service to my JSON with padding test page. I'm offering Yahoo, Amazon, del.icio.us, and generic rss2json service test. But while implementing Google's JSONP test, I found that the response interface is a little different from others. So I've slightly modified JSONP stub javascript class with caution, not to affect other services.
This is my JSON with padding test page.
http://www.geocities.jp/stormriders999/jsontest.html
Monday, May 22, 2006
dojo 0.3.0 supports JSONP
Dojo 0.3.0 has released a few days ago (? actually I'm not sure exactly when), and it is said that the release supports JSONP callback style in ScriptSrcIO.
http://archive.dojotoolkit.org/nightly/tests/io/test_ScriptSrcIO.html
So, if you are dojo toolkit user, your AJAX applications can easily connect to the several data sources in the internet - like Yahoo, del.icio.us, Amazon, and Google (Reader) - without consuming your server resources. Yes, it is completely cross-domain AJAX.
http://archive.dojotoolkit.org/nightly/tests/io/test_ScriptSrcIO.html
So, if you are dojo toolkit user, your AJAX applications can easily connect to the several data sources in the internet - like Yahoo, del.icio.us, Amazon, and Google (Reader) - without consuming your server resources. Yes, it is completely cross-domain AJAX.
Friday, April 14, 2006
JSON Feeds of Google Reader
You may know "Google Reader" - kind of online RSS reader - are providing publishing feature for your labeled and publicly opened feeds. You can copy the code and paste it to your blog.
For example, this is my feeds about web 2.0.
If you can check the source HTML code of this page, you might notice that this is some kind of JSON with padding (JSONP) call. Actually, you can check what feed data is sent from Google via following URLs :
http://www.google.com/reader/public/javascript/user/03853986730064725171/label/web2.0?n=5
http://www.google.com/reader/public/javascript/user/03853986730064725171/label/web2.0?n=5&callback=hello
The most intuitive way to see the JSONP services, I think, is to use my JSON with Padding Tester. Arbitrary JSONP services (including Yahoo, del.icio.us, or Amazon with xslt) can be visualized using this tester. Of course it is useful for this Google's JSON service.
For example, this is my feeds about web 2.0.
If you can check the source HTML code of this page, you might notice that this is some kind of JSON with padding (JSONP) call. Actually, you can check what feed data is sent from Google via following URLs :
http://www.google.com/reader/public/javascript/user/03853986730064725171/label/web2.0?n=5
http://www.google.com/reader/public/javascript/user/03853986730064725171/label/web2.0?n=5&callback=hello
The most intuitive way to see the JSONP services, I think, is to use my JSON with Padding Tester. Arbitrary JSONP services (including Yahoo, del.icio.us, or Amazon with xslt) can be visualized using this tester. Of course it is useful for this Google's JSON service.
Thursday, February 16, 2006
Del.icio.us is Now Doing JSONP, or Callback Support
I don't know when del.icio.us began the JSON service, but the JSON interface for their bookmark information was only kind of static one. Through static 'Delicious' javascript object we can get posts. So it is not apparently supporting parallel queries (will destroy each other's results), and does not consider name confliction.
But while doing test of JSON with Padding Tester (JSONP Tester), I found that they are implementing callback function parameter like Yahoo.
Check out this.
http://del.icio.us/feeds/json/stomita?callback=JsonUtil.responseCallbacks%5B0%5D
It is not mentioned official web help page and couldn't find any articles about this new feature. I'm not sure when they implemented it (maybe old).
Anyway I included del.icio.us call in JSONP Tester page.
But while doing test of JSON with Padding Tester (JSONP Tester), I found that they are implementing callback function parameter like Yahoo.
Check out this.
http://del.icio.us/feeds/json/stomita?callback=JsonUtil.responseCallbacks%5B0%5D
It is not mentioned official web help page and couldn't find any articles about this new feature. I'm not sure when they implemented it (maybe old).
Anyway I included del.icio.us call in JSONP Tester page.
JSONP Service and Security
Before talking about shared services, I have to clarify what issues (or concerns) are now discussed about JSONP services (maybe not so discussed, because there're less services than usual REST XML or SOAP Web Services). Especially, I'm going to focus security concerns. Because XMLHttpRequest itself doesn't allow the request other than the original html source site (same-origin policy), there might be same or similar concerns in JSONP service.
Let's consider Site Y is a JSONP service site (like Yahoo), and Site M is your JSONP mashup site, and User u is a visitor to Site M. Site O is a simple web service provider nothing related to these services, but might be an atacker's target.
(Note that these are only my guesses)
M cannot steal it without cooperation of Y. If Y have a unrestricted JSONP interface to access u's identity information, M can. If there's no consent of u, Y should be responsible for unintended usage of u's identity information.
Absolutely Y can. The loaded JSONP service does not always have to provide JSON object, it's nothing other than JavaScript and the code format itself is all under the control of Y. Loaded code is automatically executed without any validation (this is a key point of JSONP) and the excecution priviledge become that of Site M. So M have to do trust Y as long as M is using Y's service.
Of course Y is responsible basically. If the information theft is u's identity information in M, M also should be responsible (about unintended usage of u's identity information).
Yes, for example, requesting huge amout of requests to O. And - similar to DDoS - the attacking context become that of User u. But it's not so special case in JSONP service because any malicious site can do that. The main concern here is trust. If User u trusted Site M, and not knowing M is using Y's service (and u might be not trusting Y), M was responsible for prior explanation about using Y's services, because, if notified, u might not have used the M's service. And M should also be responsible for Site O
Basically no. If there were vulnerabilities in O it might be yes. If u accepted the usage of cross domain XMLHttpRequest in some way (browser setting?), it might also be yes, but it's under u's responsibility.
Basically no. If there were vulnerabilities in O it might be yes. CSRF might be one of them. O should be responsible with its own vulnerability.
Let's consider Site Y is a JSONP service site (like Yahoo), and Site M is your JSONP mashup site, and User u is a visitor to Site M. Site O is a simple web service provider nothing related to these services, but might be an atacker's target.
(Note that these are only my guesses)
If M is malicious, can M steal the identity information of u in Y ?
M cannot steal it without cooperation of Y. If Y have a unrestricted JSONP interface to access u's identity information, M can. If there's no consent of u, Y should be responsible for unintended usage of u's identity information.
If Y is malicious, can Y effect bad thing (information theft, session hijack) to M ?
Absolutely Y can. The loaded JSONP service does not always have to provide JSON object, it's nothing other than JavaScript and the code format itself is all under the control of Y. Loaded code is automatically executed without any validation (this is a key point of JSONP) and the excecution priviledge become that of Site M. So M have to do trust Y as long as M is using Y's service.
If Y become suddenly malicious, and the loaded code effected bad to M, who is responsible ?
Of course Y is responsible basically. If the information theft is u's identity information in M, M also should be responsible (about unintended usage of u's identity information).
If Y is malicious, Can Y attack O ?
Yes, for example, requesting huge amout of requests to O. And - similar to DDoS - the attacking context become that of User u. But it's not so special case in JSONP service because any malicious site can do that. The main concern here is trust. If User u trusted Site M, and not knowing M is using Y's service (and u might be not trusting Y), M was responsible for prior explanation about using Y's services, because, if notified, u might not have used the M's service. And M should also be responsible for Site O
Can Y steal the identity information of u in Site O ?
Basically no. If there were vulnerabilities in O it might be yes. If u accepted the usage of cross domain XMLHttpRequest in some way (browser setting?), it might also be yes, but it's under u's responsibility.
Can Y affect the transaction between u and O ?
Basically no. If there were vulnerabilities in O it might be yes. CSRF might be one of them. O should be responsible with its own vulnerability.
Saturday, February 11, 2006
JSON with Padding Tester
Against my previous post, this post doesn't go further about my project detail. Instead I'd like to show something created for my own project so far.
As I posted before, On-Demand Javascript and JSON combination is really nice, and a protocol called JSONP (JSON with Padding) is a good implementation (Yahoo is now doing similar way!). However, while XMLHttpRequest can be tested and monitored by some tools (like FireBug) ), jsonp seems cannot.
So I created a tiny testing tool to cover this. By JSON with Padding Test , you can test your jsonp service by putting and submitting your service url. Default input value is prefixed to the Yahoo Search Web Service url (with search keyword of 'google'), and jsonp url parameter is changed to 'callback' - could be changed by putting other preferred parameter name - so you can check easily what type of tool it is.
As I posted before, On-Demand Javascript and JSON combination is really nice, and a protocol called JSONP (JSON with Padding) is a good implementation (Yahoo is now doing similar way!). However, while XMLHttpRequest can be tested and monitored by some tools (like FireBug) ), jsonp seems cannot.
So I created a tiny testing tool to cover this. By JSON with Padding Test , you can test your jsonp service by putting and submitting your service url. Default input value is prefixed to the Yahoo Search Web Service url (with search keyword of 'google'), and jsonp url parameter is changed to 'callback' - could be changed by putting other preferred parameter name - so you can check easily what type of tool it is.
Subscribe to:
Posts (Atom)