Be sure that you get consumer key/secret pair by registering remote application in Salesforce, with callback URL to "https://spreadsheets.google.com/macros". Then set them as proper script properties of Google Spreadsheet.
Run "queryDataFromSalesforce" function from script editor.
Wednesday, May 25, 2011
Thursday, April 22, 2010
Twitter @Anywhere and eavesdropping threat in IE6/7
Twitter @Anywhere is a kind of "Facebook Connect for Twitter", which allows 3rd party web site to access twitter API using OAuth (maybe early implementation of OAuth WRAP/2.0 ?), but without server-side code, only using JavaScript.
The @Anywhere service seems using iframe-based cross-domain technique to communicate to API server from the web site with different domain. Recent browsers like Firefox 3+/Chrome 4/Safari 4/Internet Explorer 8 has the feature of HTML5 cross document messaging, so it is not so much difficult. For older browser, I mean Internet Explorer 6/7, they are using window.name transport. The detail of window.name cross-domain frame communication technique is in this article.
I found the eavesdropping concern in @Anywhere's cross-domain communication when used with Internet Explorer 6/7. As I mentioned above, they use window.name technique when users are using those browsers, not HTML5 standard. The window.name hack is useful but insecure because which can be read from any domain contents which are included in the page by iframe. Of course window.name property is protected against reading from the script in different domain (interestingly setting value from different domain is allowed in Internet Explorer), but changing its frame location is always allowed so attacker in the other frame can change its frame location to the attacker's domain and then read the name property to eavesdrop the conversation. Especially Twitter @Anywhere's case OAuth token is included inside the conversation message, so attackers can access any twitter API by using the token.
This is especially affected if the service can contain arbitrary URL content inside iframe. I can imagine a URL intermediation service with iframed content (like ow.ly) might think to adopt @Anywhere to share the URL directly to twitter, but this should be avoided currently.
The @Anywhere service seems using iframe-based cross-domain technique to communicate to API server from the web site with different domain. Recent browsers like Firefox 3+/Chrome 4/Safari 4/Internet Explorer 8 has the feature of HTML5 cross document messaging, so it is not so much difficult. For older browser, I mean Internet Explorer 6/7, they are using window.name transport. The detail of window.name cross-domain frame communication technique is in this article.
I found the eavesdropping concern in @Anywhere's cross-domain communication when used with Internet Explorer 6/7. As I mentioned above, they use window.name technique when users are using those browsers, not HTML5 standard. The window.name hack is useful but insecure because which can be read from any domain contents which are included in the page by iframe. Of course window.name property is protected against reading from the script in different domain (interestingly setting value from different domain is allowed in Internet Explorer), but changing its frame location is always allowed so attacker in the other frame can change its frame location to the attacker's domain and then read the name property to eavesdrop the conversation. Especially Twitter @Anywhere's case OAuth token is included inside the conversation message, so attackers can access any twitter API by using the token.
This is especially affected if the service can contain arbitrary URL content inside iframe. I can imagine a URL intermediation service with iframed content (like ow.ly) might think to adopt @Anywhere to share the URL directly to twitter, but this should be avoided currently.
Wednesday, April 01, 2009
Created "OAuth CrossDomain JavaScript Proxy Service"
Service:
OAuth CrossDomain JavaScript Proxy Service
Source Code:
http://xdoauthproxy.googlecode.com/
What can be done by this service ?
It enables you to easily call out OAuth-protected APIs (3-legged) from any JavaScript client - only JavaScript. No serverside programs are required to write a client.
Writing a client is very easy - one simple asynchronous JavaScript method invokation make it enable to access OAuth protected resource. No cumbersome process implementation like passing security tokens, signing, and showing dialogs to ask user's agreement. This proxy service does these works.
This service is running on Google's App Engine platforrm.
Code Example:
Example Client : OAuth CrossDomain JavaScript Proxy
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Example Client : OAuth CrossDomain JavaScript Proxy</title>
<script type="text/javascript" src="http://xdoauthproxy.appspot.com/js/json2.js"></script>
<script type="text/javascript" src="http://xdoauthproxy.appspot.com/js/xd-oauth-client.js"></script>
<script type="text/javascript">
function startXdRequest() {
XdOAuth.init('http://xdoauthproxy.appspot.com/xd-server.html'); // Initialization
XdOAuth.request({
url : 'http://www.google.com/calendar/feeds/default/private/full?alt=json', // OAuth-protected API Endpoint
success : function(data) {
var result = eval('(' + data + ')');
var html = [];
for (var i=0; i<result.feed.entry.length; i++) {
var entry = result.feed.entry[i];
html.push('<li>'+entry.title.$t+'</li>');
}
document.getElementById('result').innerHTML = html.join('');
},
error : function(res) {
alert(res.status + ':' + res.body);
}
});
}
</script>
</head>
<body>
<img src="./img/s.gif" />
<input type="button" onclick="startXdRequest()" value="Start OAuth Request to get private Google Calendar">
<ul id="result"></ul>
</body>
</html>
What's different from OpenSocial's OAuth Proxy?
It's similar on the point that it enables you to access OAuth APIs from JavaScript client, but this service doesn't require any OpenSocial container. It runs outside of gadget.
How many APIs now supporting ?
Almost all Google's OAuth-enabled GData APIs, Myspace, Twitter, and Smart.fm.
Notice
It pop-ups the window during the request for prompting users to agree to access the data, so you should disble browser's popup blocker for "xdoauthproxy.appspot.com"
Known Limitation
Initialy only GET request is supported. In near future we'll add support of POST or other HTTP method.
Others
You'll be prompted twice to allow intersite data exchange (OAuth Provider -> xdoauthproxy.appspot.com, xdoauthproxy.appspot.com -> The site which embedded JS client code). So it seems a little verbose for end users, but it is mondatory in order to avoid CSRF vulnerability.
Sunday, September 30, 2007
Afrous public beta is now opened !
My personal project for creating JavaScript based mashup engine - called "Afrous" - is now opened to public. In this public beta, several new features are introduced; for example, new user interface totally rewritten using ExtJS, increased numbers of operations and web services, configuration open/save functions, html renderers, and so on.
http://www.afrous.com/
Opinions are welcome in anytime. Please contact me freely.
http://www.afrous.com/
Opinions are welcome in anytime. Please contact me freely.
Wednesday, April 18, 2007
Afrous - Ajax for the rest of us
Afrous is a pure JavaScript mashup engine. All of the data is mash-upped on client-side, that is, on web browser. It also includes graphical user interface which enables drag-and-drop process editing. Arbitrary web services with JSONP interface can be invoked.
http://www.nekodrive.com/afrous/
Notice : This is VERY Alpha version service. No saving function, no loading function, and no documentation, right now...
http://www.nekodrive.com/afrous/
Notice : This is VERY Alpha version service. No saving function, no loading function, and no documentation, right now...
Sunday, February 25, 2007
Pipes everywhere
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.
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.
Saturday, February 03, 2007
Salesforce.com AJAX Toolkit and Firebug
Now I'm a salesforce.com's employee, recently using AJAX Toolkit so much often. Manoj Cheenath's AJAX Tools is really cool, but sometime I need some instant way to access Apex API from browser.
This is a bookmarklet to load salesforce's AJAX Toolkit on demand. Register this link to your browser's bookmarks.
load AJAX Toolkit
While you are in Salesforce.com's instance (I mean in *.salesforce.com), click the registered bookmarklet. Then open your firebug (or any other javascript shell) and put this into console.
You can connect Apex DB and inspect data anytime.
This is a bookmarklet to load salesforce's AJAX Toolkit on demand. Register this link to your browser's bookmarks.
load AJAX Toolkit
While you are in Salesforce.com's instance (I mean in *.salesforce.com), click the registered bookmarklet. Then open your firebug (or any other javascript shell) and put this into console.
sforce.connection.query('SELECT Id, Name FROM Account')
You can connect Apex DB and inspect data anytime.
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.
Monday, October 02, 2006
Yahoo BB Auth
Recently Yahoo! U.S. introduced an api which enables other developers to access their users' identity.
They call it "Browser-Based Authentication", and abbreviation is "Yahoo BB Auth".
http://developer.yahoo.com/auth/
I found that the naming was confusing, especially to Japanese Yahoo! users. Japanese telecom company Softbank and Yahoo Japan already branded their ADSL service as "Yahoo! BB". If you search "Yahoo BB", almost all entries are saying about this broadband internet service (currently). This implies that branding officer in Yahoo is not aware of their local services fully.
Anyway, This kind of service is interisting, and sounds nice to me. Google has already released its account authentication api. Maybe Flickr is the first (AFAIK) to open this kind of external access. This feature would be another must for future web 2.0 services.
But for the people who are moving ahead Liberty Alliance, or User-Centric Identity, this kind of movement might be unwelcome. Dick Hardt, CEO of Sxip, is saying "Yahoo/Google is deepening its identity silo". He says they aren't learning from the failure of MS .NET Passport.
User-centric, or distributed identity system is nice. I love it. But I'm afraid that the lack of this might not have been a main reason of the .NET Passport's failure. Currently it seems that users are not so unconfortable with their service, and developers are delighted with it. Who stops this opening movement of identity access, even if the api is a proprietary one? Because their service itself is absolutly proprietary, developers will not so be angry if the api is proprietary.
They call it "Browser-Based Authentication", and abbreviation is "Yahoo BB Auth".
http://developer.yahoo.com/auth/
I found that the naming was confusing, especially to Japanese Yahoo! users. Japanese telecom company Softbank and Yahoo Japan already branded their ADSL service as "Yahoo! BB". If you search "Yahoo BB", almost all entries are saying about this broadband internet service (currently). This implies that branding officer in Yahoo is not aware of their local services fully.
Anyway, This kind of service is interisting, and sounds nice to me. Google has already released its account authentication api. Maybe Flickr is the first (AFAIK) to open this kind of external access. This feature would be another must for future web 2.0 services.
But for the people who are moving ahead Liberty Alliance, or User-Centric Identity, this kind of movement might be unwelcome. Dick Hardt, CEO of Sxip, is saying "Yahoo/Google is deepening its identity silo". He says they aren't learning from the failure of MS .NET Passport.
User-centric, or distributed identity system is nice. I love it. But I'm afraid that the lack of this might not have been a main reason of the .NET Passport's failure. Currently it seems that users are not so unconfortable with their service, and developers are delighted with it. Who stops this opening movement of identity access, even if the api is a proprietary one? Because their service itself is absolutly proprietary, developers will not so be angry if the api is proprietary.
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.
Thursday, August 03, 2006
Custom Calendar App using Google Authentication API for WebApp
About 1 month ago, Google announced that they opened for 3rd party web apps to access their private data (of cource under the end user's allowance). But somehow I couldn't create any valid apps to access their actual service data. Maybe because Google had a service bug, or I misunderstood their protocol. However, today, I finally found the way to grab the private schedule feed entries from Google Calendar.
http://googleaccount.ning.com/
Click "Your private schedules in Google Calendar", and please say "Accept" when prompted by Google. I'm simply showing your calendar feeds. Not inserting, updating, deleting, and not evilly storing the retrieved information.
You can see the source code if you are a member of ning.
http://googleaccount.ning.com/
Click "Your private schedules in Google Calendar", and please say "Accept" when prompted by Google. I'm simply showing your calendar feeds. Not inserting, updating, deleting, and not evilly storing the retrieved information.
You can see the source code if you are a member of ning.
Monday, July 03, 2006
Google Account Authentication and Identity Web Services
Recently Google announced the release of their account authentication API for web applications. In a nutshell, they allowed other web apps to use their account information to login, which is very similar to Single Sign-On.
But the different part of this service from just SSO is Google is providing not only their authentication system, but also their application service endpoints to 3rd parties.
Here I describe simplified sequence of Google's authentication system. First, a web app receives a one-time-valid token from Google through an accessing user. Using this token, the web app queries Google to get further token to access application services. Finally, the token enables the web app to access the user's private information (inbox, schedules), which are kept by the Google's web application services (Gmail, Google Calendar).
Of course it is important to make sure there's a process to obtain user's consent before sending tokens to the web app. In this process, user can check the web app is trustworthy or not, and if he find it is trustworthy, he can allow the accesss to his private information with limited priviledge (e.g. READ ONLY, WRITE is NOT allowed)
In fact, as the words of "service endpoints to 3rd parties" implies, this story is far more related to "mashup" story, rather than "identity" story.
Nowadays almost all mashup services are public. For example, Amazon's search service returns same results if the given conditions are the same. Google Maps doesn't change its map information according to login user. They are only providing non-restricted public web services, whose service interface is not HTML but XML or JavaScript.
Of course some mashuppers which have their own users might mashup their information to the public web services, but the user private information itself is rarely opened to the others so far.
I think this situation is partly caused by the decision of the top exective which regards their user space as their own property, and partly caused by the difficulties to implement privacy system in these services.
Liberty Alliance and other identity federation standards offered to leverage this technical issues. Putting standard protocols, supporting vendors to implement their products, finally they are approaching executives to convince them to adopt their standards.
Although this approach is suceeded in some part of the market - like European mobile careers or American B2B services - their first big picture was "to be an identity infrastructure in all of the web world", and current situation is far from it. They may insist that they're still in the middle of the way, but they are doing same activity already for 5 years. Liberty itself seems no more vivid and not having any passion to change the world.
Let's go back to slight older days. I remember the first company who did want to dominate the web identity world - Microsoft. Their passport is now branded as a failure, but their primary purpose was just same as that of current Google - to offer identity web services to the 3rd parties, over the Microsoft (Google) platform. Passport failed without any strong supports by users. It is maybe because they couldn't offer solutions to the existing privacy concerns (maybe explanations are not sufficient), or because their excessive constration - this fault was later overcomed by Liberty - was not suitable to any existing services.
If Google is doing totally same as Microsoft, why they should repeat this failure history ? Some blogger says "it's like deja vu". But by following reasons I think this service will be supported in certain people.
It might be an irony for the people who has been saying that the unicentrism is evil, like Liberty Alliance or recent user-centric identity supporters (they are saying that even Liberty is not giving "liberty" for end users). But the user-centric identity is some kind of emerging one, so they might merge (or absorb) it in the future.
But the different part of this service from just SSO is Google is providing not only their authentication system, but also their application service endpoints to 3rd parties.
Here I describe simplified sequence of Google's authentication system. First, a web app receives a one-time-valid token from Google through an accessing user. Using this token, the web app queries Google to get further token to access application services. Finally, the token enables the web app to access the user's private information (inbox, schedules), which are kept by the Google's web application services (Gmail, Google Calendar).
Of course it is important to make sure there's a process to obtain user's consent before sending tokens to the web app. In this process, user can check the web app is trustworthy or not, and if he find it is trustworthy, he can allow the accesss to his private information with limited priviledge (e.g. READ ONLY, WRITE is NOT allowed)
In fact, as the words of "service endpoints to 3rd parties" implies, this story is far more related to "mashup" story, rather than "identity" story.
Nowadays almost all mashup services are public. For example, Amazon's search service returns same results if the given conditions are the same. Google Maps doesn't change its map information according to login user. They are only providing non-restricted public web services, whose service interface is not HTML but XML or JavaScript.
Of course some mashuppers which have their own users might mashup their information to the public web services, but the user private information itself is rarely opened to the others so far.
I think this situation is partly caused by the decision of the top exective which regards their user space as their own property, and partly caused by the difficulties to implement privacy system in these services.
Liberty Alliance and other identity federation standards offered to leverage this technical issues. Putting standard protocols, supporting vendors to implement their products, finally they are approaching executives to convince them to adopt their standards.
Although this approach is suceeded in some part of the market - like European mobile careers or American B2B services - their first big picture was "to be an identity infrastructure in all of the web world", and current situation is far from it. They may insist that they're still in the middle of the way, but they are doing same activity already for 5 years. Liberty itself seems no more vivid and not having any passion to change the world.
Let's go back to slight older days. I remember the first company who did want to dominate the web identity world - Microsoft. Their passport is now branded as a failure, but their primary purpose was just same as that of current Google - to offer identity web services to the 3rd parties, over the Microsoft (Google) platform. Passport failed without any strong supports by users. It is maybe because they couldn't offer solutions to the existing privacy concerns (maybe explanations are not sufficient), or because their excessive constration - this fault was later overcomed by Liberty - was not suitable to any existing services.
If Google is doing totally same as Microsoft, why they should repeat this failure history ? Some blogger says "it's like deja vu". But by following reasons I think this service will be supported in certain people.
- It is a platform provided by service provider
- Google already has many attractive services. Developers are definitely going to have an interest in mashuping them. Owing to Google's massive user space, 3rd partiy contributers will receive many incentives.
- Microsoft, I think, was originally much like platform-oriented, rather than service-oriented. Their services were going to be supplied afterward, benefits obtained by adopting their platform were not so clear for both end users and 3rd parties.
- It is a developer-oriented service
- Different from existing enterprise-oriented authentication services, developers can use the service freely even if they are individuals. By disclaiming service fees essentially and delegating trust resolution to the users, it solves the complex problem around contracts. These openness will attract so many developers, it may cause big explosion in Internet level.
- Liberty was a little messy for developers. The specification establishment process was open, but actually it was dominated by the famous software vendors. And Liberty promoters took so much focus on topdown approach. While they were eager to conceive conservative exectives, other identity standards or proprietary identity web services had spread in the web world.
- Other service providers will follow it
- Google is now becoming a rare brand which can effect c-level only by its name, at least, in some enterprises which is based on the same profit model as Google (= Ad.). For these companies, Google is not only a threat but also an important reference model. Actually, Yahoo! U.S. has already announced the plan to introduce authentication service.
- As a result of newcomers in open identity platform field, the business model of that platform will be recognized by other service providers, possibly establishing certain market.
It might be an irony for the people who has been saying that the unicentrism is evil, like Liberty Alliance or recent user-centric identity supporters (they are saying that even Liberty is not giving "liberty" for end users). But the user-centric identity is some kind of emerging one, so they might merge (or absorb) it in the future.
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.
Monday, May 01, 2006
Del.icio.us brows.er
I've created another tool : del.icio.us brows.er .
Interface looks like del.icio.us direc.tor, but brows.er has so much difference from direc.tor.
Interface looks like del.icio.us direc.tor, but brows.er has so much difference from direc.tor.
- No bookmarklet. Just access to the page linked above.
- No server hosting environement. You can run even in your local PC. Please check it by saving the site as a html doc.
- No api authentication. All data is gotten via JSON public feeds.
- Not restricted to your posts. All del.icio.us users' posts are browsable.
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.
Wednesday, March 01, 2006
Name Changed : My Del.icio.us Recommendation Snippet
Recently I noticed that original del.icio.us is providing "Del.icio.us Recommendation Engine", so I changed the name of this module to "My Del.icio.us Recommendation Snippet".
This confliction is because I named it so easy way, but anyway these two are totally different. The former (original) is an internal functionality in del.icio.us service itself, and the latter (I created) is a script snippet using del.icio.us JSON call interface, which can be embedded in arbitrary web site.
This confliction is because I named it so easy way, but anyway these two are totally different. The former (original) is an internal functionality in del.icio.us service itself, and the latter (I created) is a script snippet using del.icio.us JSON call interface, which can be embedded in arbitrary web site.
Wednesday, February 22, 2006
Why del.icio.us recommendation engine is not personalized 2.0 ?
First, you have to tell your del.icio.us ID to your visiting site. In principle, it's not necessary. Because what we need is your recent tagging information, not your id. Unfortunately, to get your bookmark information, the site owner have to know your del.icio.us id. This is derived from del.icio.us's feed interface. But, in general, forcing to tell someone's unique id is not preferable from the aspect of privacy.
Second, this module doesn't consider the case where identity information is originally access controlled. Del.icio.us bookmarks are apparently identity information, but it's not restricted, always published for general public. In order to deal with every identity-aware web services, we have to consider the case where services are access controlled.
These are not only the issues in personalized 2.0 services. If I have a time I can pick up many other issues to be solved.
Second, this module doesn't consider the case where identity information is originally access controlled. Del.icio.us bookmarks are apparently identity information, but it's not restricted, always published for general public. In order to deal with every identity-aware web services, we have to consider the case where services are access controlled.
These are not only the issues in personalized 2.0 services. If I have a time I can pick up many other issues to be solved.
Subscribe to:
Posts (Atom)