tag:blogger.com,1999:blog-59920492024-03-14T15:24:45.341+09:00Personalized Web 2.0 BlogProject report relating to personalized web 2.0 services & development.Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.comBlogger26125tag:blogger.com,1999:blog-5992049.post-26548619514428576752011-05-25T17:45:00.005+09:002011-05-25T18:14:56.444+09:00Connecting to Salesforce from Google Apps Script via OAuth & RESTful APIBe 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.<br /><br /><script src="https://gist.github.com/990589.js?file=SimpleSalesforceConnection.js"></script><br /><br />Run "queryDataFromSalesforce" function from script editor.Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com8tag:blogger.com,1999:blog-5992049.post-62389071885997088062010-04-22T11:04:00.012+09:002010-04-22T18:18:17.575+09:00Twitter @Anywhere and eavesdropping threat in IE6/7<a href="http://dev.twitter.com/anywhere">Twitter @Anywhere</a> 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.<br /><br />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 <a href="http://www.sitepen.com/blog/2008/07/22/windowname-transport/">this article</a>.<br /><br /><br />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.<br /><br /><br />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.Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com0tag:blogger.com,1999:blog-5992049.post-87829680142883734272009-04-01T19:59:00.006+09:002009-04-01T20:35:28.457+09:00Created "OAuth CrossDomain JavaScript Proxy Service"<h4>Service:</h4><br /><a href="http://xdoauthproxy.appspot.com/">OAuth CrossDomain JavaScript Proxy Service</a><br /><br /><h4>Source Code:</h4><br /><a href="http://xdoauthproxy.googlecode.com/">http://xdoauthproxy.googlecode.com/</a><br /><br /><h4>What can be done by this service ?</h4><br />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.<br /><br />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.<br /><br />This service is running on Google's App Engine platforrm.<br /><br /><h4>Code Example:</h4><br /><a href="http://xdoauthproxy.googlecode.com/svn/trunk/assets/example.html">Example Client : OAuth CrossDomain JavaScript Proxy</a><br /><br /><pre style="overflow:auto"><br /><span class="synComment"><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"></span><br /><span class="synIdentifier"><</span><span class="synStatement">html</span><span class="synIdentifier">></span><br /> <span class="synIdentifier"><</span><span class="synStatement">head</span><span class="synIdentifier">></span><br /><span class="synPreProc"> </span><span class="synIdentifier"><</span><span class="synStatement">title</span><span class="synIdentifier">></span>Example Client : OAuth CrossDomain JavaScript Proxy<span class="synIdentifier"></</span><span class="synStatement">title</span><span class="synIdentifier">></span><br /><span class="synPreProc"> </span><span class="synIdentifier"><</span><span class="synStatement">script</span><span class="synIdentifier"> </span><span class="synType">type</span><span class="synIdentifier">=</span><span class="synConstant">"text/javascript"</span><span class="synIdentifier"> </span><span class="synType">src</span><span class="synIdentifier">=</span><span class="synConstant">"http://xdoauthproxy.appspot.com/js/json2.js"</span><span class="synIdentifier">></</span><span class="synStatement">script</span><span class="synIdentifier">></span><br /><span class="synPreProc"> </span><span class="synIdentifier"><</span><span class="synStatement">script</span><span class="synIdentifier"> </span><span class="synType">type</span><span class="synIdentifier">=</span><span class="synConstant">"text/javascript"</span><span class="synIdentifier"> </span><span class="synType">src</span><span class="synIdentifier">=</span><span class="synConstant">"http://xdoauthproxy.appspot.com/js/xd-oauth-client.js"</span><span class="synIdentifier">></</span><span class="synStatement">script</span><span class="synIdentifier">></span><br /><span class="synPreProc"> </span><span class="synIdentifier"><</span><span class="synStatement">script</span><span class="synIdentifier"> </span><span class="synType">type</span><span class="synIdentifier">=</span><span class="synConstant">"text/javascript"</span><span class="synIdentifier">></span><br /><span class="synIdentifier">function</span><span class="synSpecial"> startXdRequest</span>()<span class="synSpecial"> </span><span class="synIdentifier">{</span><br /><span class="synSpecial"> XdOAuth.init</span>(<span class="synConstant">'http://xdoauthproxy.appspot.com/xd-server.html'</span>)<span class="synSpecial">; </span><span class="synComment">// Initialization</span><br /><span class="synSpecial"> XdOAuth.request</span>(<span class="synIdentifier">{</span><br /><span class="synSpecial"> url : </span><span class="synConstant">'http://www.google.com/calendar/feeds/default/private/full?alt=json'</span><span class="synSpecial">, </span><span class="synComment">// OAuth-protected API Endpoint</span><br /><span class="synSpecial"> success : </span><span class="synIdentifier">function</span>(<span class="synSpecial">data</span>)<span class="synSpecial"> </span><span class="synIdentifier">{</span><br /><span class="synSpecial"> </span><span class="synIdentifier">var</span><span class="synSpecial"> result = eval</span>(<span class="synConstant">'('</span><span class="synSpecial"> + data + </span><span class="synConstant">')'</span>)<span class="synSpecial">;</span><br /><span class="synSpecial"> </span><span class="synIdentifier">var</span><span class="synSpecial"> html = </span><span class="synIdentifier">[]</span><span class="synSpecial">;</span><br /><span class="synSpecial"> </span><span class="synStatement">for</span><span class="synSpecial"> </span>(<span class="synIdentifier">var</span><span class="synSpecial"> i=</span>0<span class="synSpecial">; i<result.feed.entry.length; i++</span>)<span class="synSpecial"> </span><span class="synIdentifier">{</span><br /><span class="synSpecial"> </span><span class="synIdentifier">var</span><span class="synSpecial"> entry = result.feed.entry</span><span class="synIdentifier">[</span><span class="synSpecial">i</span><span class="synIdentifier">]</span><span class="synSpecial">;</span><br /><span class="synSpecial"> html.push</span>(<span class="synConstant">'<li>'</span><span class="synSpecial">+entry.title.$t+</span><span class="synConstant">'</li>'</span>)<span class="synSpecial">;</span><br /><span class="synSpecial"> </span><span class="synIdentifier">}</span><br /><span class="synSpecial"> </span><span class="synStatement">document</span><span class="synSpecial">.getElementById</span>(<span class="synConstant">'result'</span>)<span class="synSpecial">.innerHTML = html.join</span>(<span class="synConstant">''</span>)<span class="synSpecial">;</span><br /><span class="synSpecial"> </span><span class="synIdentifier">}</span><span class="synSpecial">,</span><br /><span class="synSpecial"> error : </span><span class="synIdentifier">function</span>(<span class="synSpecial">res</span>)<span class="synSpecial"> </span><span class="synIdentifier">{</span><br /><span class="synSpecial"> </span><span class="synStatement">alert</span>(<span class="synSpecial">res.</span><span class="synStatement">status</span><span class="synSpecial"> + </span><span class="synConstant">':'</span><span class="synSpecial"> + res.body</span>)<span class="synSpecial">;</span><br /><span class="synSpecial"> </span><span class="synIdentifier">}</span><br /><span class="synSpecial"> </span><span class="synIdentifier">}</span>)<span class="synSpecial">;</span><br /><span class="synIdentifier">}</span><br /><span class="synSpecial"> </span><span class="synIdentifier"></</span><span class="synStatement">script</span><span class="synIdentifier">></span><br /><span class="synPreProc"> </span><span class="synIdentifier"></</span><span class="synStatement">head</span><span class="synIdentifier">></span><br /> <span class="synIdentifier"><</span><span class="synStatement">body</span><span class="synIdentifier">></span><br /> <span class="synIdentifier"><</span><span class="synStatement">img</span><span class="synIdentifier"> </span><span class="synType">src</span><span class="synIdentifier">=</span><span class="synConstant">"./img/s.gif"</span><span class="synIdentifier"> /></span><br /> <span class="synIdentifier"><</span><span class="synStatement">input</span><span class="synIdentifier"> </span><span class="synType">type</span><span class="synIdentifier">=</span><span class="synConstant">"button"</span><span class="synIdentifier"> </span><span class="synSpecial">onclick="startXdRequest</span>()<span class="synSpecial">"</span><span class="synIdentifier"> </span><span class="synType">value</span><span class="synIdentifier">=</span><span class="synConstant">"Start OAuth Request to get private Google Calendar"</span><span class="synIdentifier">></span><br /> <span class="synIdentifier"><</span><span class="synStatement">ul</span><span class="synIdentifier"> </span><span class="synType">id</span><span class="synIdentifier">=</span><span class="synConstant">"result"</span><span class="synIdentifier">></</span><span class="synStatement">ul</span><span class="synIdentifier">></span><br /> <span class="synIdentifier"></</span><span class="synStatement">body</span><span class="synIdentifier">></span><br /><span class="synIdentifier"></</span><span class="synStatement">html</span><span class="synIdentifier">></span><br /></pre><br /><br /><h4>What's different from OpenSocial's OAuth Proxy? </h4><br />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.<br /><br /><h4>How many APIs now supporting ?</h4><br />Almost all Google's OAuth-enabled GData APIs, Myspace, Twitter, and Smart.fm.<br /><br /><h4>Notice</h4><br />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"<br /><br /><h4>Known Limitation</h4><br />Initialy only GET request is supported. In near future we'll add support of POST or other HTTP method.<br /><br /><h4>Others</h4><br />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.Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com1tag:blogger.com,1999:blog-5992049.post-58841273879039155112007-09-30T01:38:00.000+09:002007-09-30T01:58:07.621+09:00Afrous 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.<br /><br /><a href="http://www.afrous.com/">http://www.afrous.com/<br /></a><br /><br />Opinions are welcome in anytime. Please contact me freely.Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com0tag:blogger.com,1999:blog-5992049.post-69994041107149112542007-04-18T02:32:00.000+09:002007-04-18T02:43:34.171+09:00Afrous - Ajax for the rest of usAfrous 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.<br /><br /><a href="http://www.nekodrive.com/afrous/">http://www.nekodrive.com/afrous/</a><br /><br />Notice : This is VERY Alpha version service. No saving function, no loading function, and no documentation, right now...Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com0tag:blogger.com,1999:blog-5992049.post-59013788011823702222007-02-25T13:00:00.000+09:002007-02-25T13:21:47.589+09:00Pipes everywhereYahoo 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. <br /><br />This is a simple pipe, provided by <a href="http://kentbrewster.com/badger">http://kentbrewster.com/badger</a>, which accepts RSS URL input and generates output in JSON(P) format.<br /><br />http://pipes.yahoo.com/pipes/zIQi0Iy72xGJ3NMhJhOy0Q/run?_render=json&s=http%3A%2F%2Fpersonalized20.blogspot.com%2Ffeeds%2Fposts%2Fdefault%3Falt%3Drss&_callback=handleFeeds<br /><br /><a href="http://www.geocities.jp/stormriders999/jsontest.html#_callback:http%3A%2F%2Fpipes.yahoo.com%2Fpipes%2FzIQi0Iy72xGJ3NMhJhOy0Q%2Frun%3F_render%3Djson%26s%3Dhttp%253A%252F%252Fpersonalized20.blogspot.com%252Ffeeds%252Fposts%252Fdefault%253Falt%253Drss">Test JSONP from Here.</a>Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com0tag:blogger.com,1999:blog-5992049.post-72735196499318429352007-02-03T10:07:00.000+09:002007-02-03T10:37:29.706+09:00Salesforce.com AJAX Toolkit and FirebugNow I'm a salesforce.com's employee, recently using AJAX Toolkit so much often. <a href="http://www.salesforce.com/appexchange/detail_overview.jsp?id=a0330000002foeKAAQ">Manoj Cheenath's AJAX Tools</a> is really cool, but sometime I need some instant way to access Apex API from browser.<br /><br />This is a bookmarklet to load salesforce's AJAX Toolkit on demand. Register this link to your browser's bookmarks.<br /><br /><a href="javascript:(function(){window.__sfdcSessionId=document.cookie.match(/sid=([^;]+);/)[1];var s=document.createElement('script');s.type='text/javascript';s.src='/soap/ajax/8.0/connection.js';document.body.appendChild(s)})()">load AJAX Toolkit</a><br /><br />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.<br /><br /><pre><br />sforce.connection.query('SELECT Id, Name FROM Account')<br /></pre><br /><br />You can connect Apex DB and inspect data anytime.Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com2tag:blogger.com,1999:blog-5992049.post-1161841699222564992006-10-26T14:12:00.000+09:002006-10-26T14:55:01.323+09:00JSONRequest by Douglas Crockford<a href="http://www.crockford.com/">Douglas Crockford</a> is now considering a new native JavaScript Object. It's called "JSONRequest", like XMLHttpRequest.<br /><br /><a href="http://ajaxian.com/archives/jsonrequest-proposal">http://ajaxian.com/archives/jsonrequest-proposal</a><br /><br />I read the proposal a little, and found that it is eliminating cookie information in its request header.<br /><br /><a href="http://www.json.org/JSONRequest.html">http://www.json.org/JSONRequest.html</a><br /><blockquote><br />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.<br /></blockquote><br /><br />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.<br /><br />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 <a href="http://personalized20.blogspot.com/2006/08/personalized-jsonp-google-calendar.html">here</a>!) is rather unsafe in this case.<br /><br />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.<br /><br /><div class="Tags">Technorati tags: <a href="http://technorati.com/tag/json" rel="tag">json</a>,<a href="http://technorati.com/tag/jsonrequest" rel="tag">jsonrequest</a>,<a href="http://technorati.com/tag/security" rel="tag">security</a></div>Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com0tag:blogger.com,1999:blog-5992049.post-1159776095133152062006-10-02T16:46:00.000+09:002006-10-26T14:50:19.698+09:00Yahoo BB AuthRecently Yahoo! U.S. introduced an api which enables other developers to access their users' identity. <br />They call it "Browser-Based Authentication", and abbreviation is "Yahoo BB Auth".<br /><a href="http://developer.yahoo.com/auth/">http://developer.yahoo.com/auth/</a><br /><br />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.<br /><br />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.<br /><br />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 <a href="http://identity20.com/?p=79">"Yahoo/Google is deepening its identity silo"</a>. He says they aren't learning from the failure of MS .NET Passport. <br /><br />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.<br /><br /><div class="Tags">Technorati tags: <a href="http://technorati.com/tag/yahoo" rel="tag">yahoo</a>, <a href="http://technorati.com/tag/identity" rel="tag">identity</a>, <a href="http://technorati.com/tag/usercentric" rel="tag">usercentric</a></div>Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com0tag:blogger.com,1999:blog-5992049.post-1157048637169314722006-09-01T03:12:00.000+09:002006-10-26T14:50:19.641+09:00JSONP Private Calendar Mashup with Simile TimelineI've created interesting demo to show how Personalized Web 2.0 services can be used in mashup application.<br /><br /><a href="http://www.geocities.jp/stormriders999/timeline.html">http://www.geocities.jp/stormriders999/timeline.html</a><br /><br />I'm using <a href="http://simile.mit.edu/timeline/">MIT Simile Timeline</a> for dynamic user interface.<br /><br />You'll see that your own private schedule data in Google Calendar is mashuped, only if you granted us to acess them.<br /><br />Yes, it is actually personalized service for you.<br /><br /><br /><div class="Tags">Technorati tags: <a href="http://technorati.com/tag/google" rel="tag">google</a>, <a href="http://technorati.com/tag/calendar" rel="tag">calendar</a>, <a href="http://technorati.com/tag/mashup" rel="tag">mashup</a>, <a href="http://technorati.com/tag/json" rel="tag">json</a>, <a href="http://technorati.com/tag/jsonp" rel="tag">jsonp</a>, <a href="http://technorati.com/tag/timeline" rel="tag">timeline</a></div>Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com0tag:blogger.com,1999:blog-5992049.post-1156872856210398802006-08-30T01:57:00.000+09:002006-10-26T14:50:19.544+09:00Personalized JSONP - Google Calendar JSON Proxy ServiceGoogle 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. <br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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. <br /><br />Please check out the site bellow :<br /><br />Google Calendar JSON Proxy Service<br /><a href="http://gcal2json.ning.com/">http://gcal2json.ning.com/</a><br /><br />Also there's a sample client application program.<br /><br /><a href="http://www.geocities.jp/stormriders999/gcal_json_client_sample_e.html">http://www.geocities.jp/stormriders999/gcal_json_client_sample_e.html</a><br /><br /><br />Do you think this is really a good personalized web 2.0 service, don't you?<br /><br /><div class="Tags">Technorati tags: <a href="http://technorati.com/tag/google" rel="tag">google</a>, <a href="http://technorati.com/tag/calendar" rel="tag">calendar</a>, <a href="http://technorati.com/tag/authentication" rel="tag">authentication</a>, <a href="http://technorati.com/tag/json" rel="tag">json</a>, <a href="http://technorati.com/tag/jsonp" rel="tag">jsonp</a></div>Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com1tag:blogger.com,1999:blog-5992049.post-1155214725179771342006-08-10T21:55:00.000+09:002006-10-26T14:50:19.484+09:00del.icio.us network JSONdel.icio.us has released <a href="http://blog.del.icio.us/blog/2006/08/show_off_your_n.html">network badge</a>.<br /><br />And also we can get JSON data.<br /><br /><a href="http://del.icio.us/feeds/json/network/stomita">http://del.icio.us/feeds/json/network/stomita<br /></a><br />JSONP is also supported.<br /><br /><a href="http://del.icio.us/feeds/json/network/stomita?callback=handleNetwork">http://del.icio.us/feeds/json/network/stomita?callback=handleNetwork<br /></a> <br /><br />This feature is not officially announced, though.<br /><br /><div class="Tags">Technorati tags: <a href="http://technorati.com/tag/json" rel="tag">json</a>, <a href="http://technorati.com/tag/del.icio.us" rel="tag">del.icio.us</a>, <a href="http://technorati.com/tag/jsonp" rel="tag">jsonp</a></div>Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com0tag:blogger.com,1999:blog-5992049.post-1154604493878289542006-08-03T20:12:00.000+09:002006-10-26T14:50:19.423+09:00Custom Calendar App using Google Authentication API for WebAppAbout 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.<br /><br /><a href="http://googleaccount.ning.com/">http://googleaccount.ning.com/</a><br /><br />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.<br /><br />You can see the source code if you are a member of <a href="http://www.ning.com">ning</a>.<br /><br /><br /><div class="Tags">Technorati tags: <a href="http://technorati.com/tag/google" rel="tag">google</a>, <a href="http://technorati.com/tag/account" rel="tag">account</a>, <a href="http://technorati.com/tag/authentication" rel="tag">authentication</a>, <a href="http://technorati.com/tag/calendar" rel="tag">calendar</a>, <a href="http://technorati.com/tag/identity" rel="tag">identity</a>, <a href="http://technorati.com/tag/api" rel="tag">api</a></div>Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com0tag:blogger.com,1999:blog-5992049.post-1151930311663476362006-07-03T20:49:00.000+09:002006-10-26T14:50:19.354+09:00Google Account Authentication and Identity Web ServicesRecently Google announced the release of their <a href="http://code.google.com/apis/accounts/AuthForWebApps.html">account authentication API for web applications</a>. In a nutshell, they allowed other web apps to use their account information to login, which is very similar to Single Sign-On.<br /><br />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.<br /><br />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).<br /><br />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)<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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. <br /> <br />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.<br /><br />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.<br /><br /><ol><br /> <li><b>It is a platform provided by service provider</b><br /> <ul><br /> <li>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.</li><br /> <li>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. </li><br /> </ul><br /> </li><br /> <li><b>It is a developer-oriented service</b><br /> <ul><br /> <li>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.</li><br /> <li>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. </li><br /> </ul><br /> </li> <br /> <li><b>Other service providers will follow it</b><br /> <ul><br /> <li>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 <a href="http://blogs.zdnet.com/BTL/?p=2662">announced</a> the plan to introduce authentication service.</li><br /> <li>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.</li><br /> </ul><br /> </li><br /></ol><br /><br />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.<br /><br /><br /><div class="Tags">Technorati tags: <a href="http://technorati.com/tag/google" rel="tag">google</a>, <a href="http://technorati.com/tag/liberty" rel="tag">liberty</a>, <a href="http://technorati.com/tag/identity" rel="tag">identity</a>, <a href="http://technorati.com/tag/usercentric" rel="tag">usercentric</a>, <a href="http://technorati.com/tag/sso" rel="tag">sso</a>, <a href="http://technorati.com/tag/authentication" rel="tag">authentication</a></div>Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com0tag:blogger.com,1999:blog-5992049.post-1149234973890773852006-06-02T16:26:00.000+09:002006-10-26T14:50:19.300+09:00Google AJAX Search and JSON Web Sevice CallingIn this blog I've mentioned about remoting technology using JSON in dynamic script loading (<a href="http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/">JSONP</a>). It's great because it doesn't require any app server for mashuping services, and scales well. <br /><br />Among major service providers, first, <a href="http://del.icio.us/help/json">del.icio.us noticed</a> that and widely introduced for the developers, and then <a href="http://developer.yahoo.com/common/json.html">Yahoo implemented</a> same feature but even more sophisticated one. Amazon's xslt feature <a href="http://aws.typepad.com/aws/2006/05/using_aws_and_x.html">enables same service</a>. However, the giant google didn't have any service interface for browser applications (except Google Maps) so far.<br /><br />But finally they introduced <a href="http://code.google.com/apis/ajaxsearch/">'Google AJAX Search'</a>. <br /><br />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.<br /><br />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!) :<br /><br /><a href="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">http://www.google.com/uds/GwebSearch?<span style="font-weight:bold;">callback=GwebSearch.RawCompletion</span>&lstkp=0&context=0&rsz=small&hl=ja&q=Google&key=internal-documentation&v=0.1<br /></a><br /><br />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.<br /><br />This is my JSON with padding test page.<br /><a href="http://www.geocities.jp/stormriders999/jsontest.html">http://www.geocities.jp/stormriders999/jsontest.html<br /></a><br /><br /><br /><div class="Tags">Technorati tags: <a href="http://technorati.com/tag/json" rel="tag">json</a>, <a href="http://technorati.com/tag/jsonp" rel="tag">jsonp</a>, <a href="http://technorati.com/tag/google" rel="tag">google</a>, <a href="http://technorati.com/tag/ajax" rel="tag">ajax</a></div>Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com0tag:blogger.com,1999:blog-5992049.post-1148277809010457622006-05-22T14:54:00.000+09:002006-10-26T14:50:19.232+09:00dojo 0.3.0 supports JSONPDojo 0.3.0 has released a few days ago (? actually I'm not sure exactly when), and it is said that the release supports <a href="http://ajaxian.com/archives/jsonp-json-with-padding">JSONP</a> callback style in ScriptSrcIO. <br /><br /><a href="http://archive.dojotoolkit.org/nightly/tests/io/test_ScriptSrcIO.html">http://archive.dojotoolkit.org/nightly/tests/io/test_ScriptSrcIO.html<br /></a><br /><br />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.<br /><br /><div class="Tags">Technorati tags: <a href="http://technorati.com/tag/json" rel="tag">json</a>, <a href="http://technorati.com/tag/jsonp" rel="tag">jsonp</a>, <a href="http://technorati.com/tag/dojo" rel="tag">dojo</a>, <a href="http://technorati.com/tag/javascript" rel="tag">javascript</a></div>Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com0tag:blogger.com,1999:blog-5992049.post-1146480621614487512006-05-01T19:38:00.000+09:002006-10-26T14:50:19.112+09:00Del.icio.us brows.erI've created another tool : <a href="http://www.geocities.jp/stormriders999/delbrowser.html">del.icio.us brows.er</a> .<br /><br />Interface looks like <a href="http://johnvey.com/features/deliciousdirector/">del.icio.us direc.tor</a>, but brows.er has so much difference from direc.tor. <br /><ul><br /><li>No bookmarklet. Just access to the page linked above.</li><br /><li>No server hosting environement. You can run even in your local PC. Please check it by saving the site as a html doc.</li><br /><li>No api authentication. All data is gotten via JSON public feeds.</li><br /><li>Not restricted to your posts. All del.icio.us users' posts are browsable.</li><br /></ul><br /><br /><div class="Tags">Technorati tags: <a href="http://technorati.com/tag/delicious" rel="tag">delicious</a>, <a href="http://technorati.com/tag/del.icio.us" rel="tag">del.icio.us</a>, <a href="http://technorati.com/tag/json" rel="tag">json</a></div>Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com0tag:blogger.com,1999:blog-5992049.post-1144988381476478552006-04-14T12:59:00.000+09:002006-10-26T14:50:19.050+09:00JSON Feeds of Google ReaderYou 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.<br /><br />For example, this is my feeds about web 2.0.<br /><br /><script type="text/javascript" src="http://www.google.com/reader/ui/publisher.js"></script><br /><script type="text/javascript" src="http://www.google.com/reader/public/javascript/user/03853986730064725171/label/web2.0?n=5&callback=GRC_p(%7Bc%3A'green'%2Ct%3A'My%20items%20labeled%20%5C042web2.0%5C042'%2Cs%3A'false'%7D)%3Bnew%20GRC"></script><br /><br />If you can check the source HTML code of this page, you might notice that this is some kind of <a href="http://ajaxian.com/archives/jsonp-json-with-padding">JSON with padding (JSONP)</a> call. Actually, you can check what feed data is sent from Google via following URLs :<br /><br /><a href="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<br /></a><br /><a href="http://www.google.com/reader/public/javascript/user/03853986730064725171/label/web2.0?n=5&callback=hello">http://www.google.com/reader/public/javascript/user/03853986730064725171/label/web2.0?n=5&callback=hello</a><br /><br />The most intuitive way to see the JSONP services, I think, is to use my <a href="http://www.geocities.jp/stormriders999/jsontest.html">JSON with Padding Tester</a>. 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.<br /><br /><br /><div class="Tags">Technorati tags: <a href="http://technorati.com/tag/json" rel="tag">json</a>, <a href="http://technorati.com/tag/jsonp" rel="tag">jsonp</a>, <a href="http://technorati.com/tag/google" rel="tag">google</a>, <a href="http://technorati.com/tag/rss" rel="tag">rss</a>, <a href="http://technorati.com/tag/google reader" rel="tag">google reader</a></div>Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com0tag:blogger.com,1999:blog-5992049.post-1141201674839689962006-03-01T17:11:00.000+09:002006-10-26T14:50:18.993+09:00Name Changed : My Del.icio.us Recommendation SnippetRecently I noticed that original del.icio.us is providing <a href="http://blog.del.icio.us/blog/2005/08/people_who_like.html">"Del.icio.us Recommendation Engine"</a>, so I changed the name of this module to <a href="http://www.geocities.jp/stormriders999/delview.html">"My Del.icio.us Recommendation Snippet"</a>. <br /><br />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.<br /><br /><div class="Tags">Technorati tags: <a href="http://technorati.com/tag/delicious" rel="tag">delicious</a>, <a href="http://technorati.com/tag/del.icio.us" rel="tag">del.icio.us</a>, <a href="http://technorati.com/tag/json" rel="tag">json</a>, <a href="http://technorati.com/tag/jsonp" rel="tag">jsonp</a>, <a href="http://technorati.com/tag/recommendation" rel="tag">recommendation</a>, <a href="http://technorati.com/tag/personalization" rel="tag">personalization</a></div>Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com0tag:blogger.com,1999:blog-5992049.post-1140619554438606002006-02-22T23:45:00.000+09:002007-02-03T10:34:51.112+09:00Why 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.<br /><br />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. <br /><br />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.Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com0tag:blogger.com,1999:blog-5992049.post-1140613470432473212006-02-22T20:32:00.000+09:002006-10-26T14:50:18.879+09:00Del.icio.us Recommendation EngineWhile researching recent del.icio.us's native support of JSONP, an interesting idea hit me and fired up my imagination. Devoting recent days to this development, and finally I created an attractive script moudule. <a href="http://www.geocities.jp/stormriders999/delview.html">"Del.icio.us Recommendation Engine"</a>, I call it. <br /><br />"Del.icio.us Recommendation Engine" is a recommendation link list generator extracted from site owner's bookmarks archived in <a href="http://del.icio.us">del.icio.us</a>. If you tell your del.icio.us ID to the site, you can get the site owner's bookmarks as a recommendation. While creating your recommendation list, your recent del.icio.us posts and associated tags automatically used as your preference information.<br /><br />It is cool because we don't need any server infrastructure for generating recommendation list. Entire generation process is done in client side Javascript. <a href="http://json.org">JSON</a> (or <a href="http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/">JSONP</a>) and <a href="http://ajaxpatterns.org/On-Demand_Javascript">On-Demand JavaScript</a> techniques are used to get del.icio.us posts.<br /><br />Seeing is believing. Please <a href="http://www.geocities.jp/stormriders999/delview.html">look and see it</a>.<br /><br />I think it is a kind of interesting module, but I don't think it is the final achivement of my personalized 2.0 project. Yes, this module does some kind of personalization for the visitors, but techniques used in this module cannot be used in many cases. I think there're many issues to be solved there in order to be a generic personalized web 2.0 service solution.<br /><br />Anyway, I created some "personalized 2.0 like " service module. It's totally fun. Enjoy yourself.<br /><br /><div class="Tags">Technorati tags: <a href="http://technorati.com/tag/delicious" rel="tag">delicious</a>, <a href="http://technorati.com/tag/del.icio.us" rel="tag">del.icio.us</a>, <a href="http://technorati.com/tag/json" rel="tag">json</a>, <a href="http://technorati.com/tag/jsonp" rel="tag">jsonp</a>, <a href="http://technorati.com/tag/recommendation" rel="tag">recommendation</a>, <a href="http://technorati.com/tag/personalization" rel="tag">personalization</a></div>Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com0tag:blogger.com,1999:blog-5992049.post-1140097971342897332006-02-16T22:36:00.000+09:002006-10-26T14:50:18.826+09:00Del.icio.us is Now Doing JSONP, or Callback SupportI don't know when <a href="http://del.icio.us">del.icio.us</a> began the <a href="http://del.icio.us/help/json">JSON service</a>, 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.<br /><br />But while doing test of <a href="http://www.geocities.jp/stormriders999/jsontest.html">JSON with Padding Tester</a> (JSONP Tester), I found that they are implementing callback function parameter like <a href="http://developer.yahoo.net/common/json.html">Yahoo</a>.<br /><br />Check out this.<br /><br /><a href="http://del.icio.us/feeds/json/stomita?callback=JsonUtil.responseCallbacks%5B0%5D">http://del.icio.us/feeds/json/stomita?callback=JsonUtil.responseCallbacks%5B0%5D<br /></a><br /><br />It is not mentioned <a href="http://del.icio.us/help/json">official web help page</a> and couldn't find any articles about this new feature. I'm not sure when they implemented it (maybe old). <br /><br />Anyway I included del.icio.us call in <a href="http://www.geocities.jp/stormriders999/jsontest.html">JSONP Tester</a> page.<br /><br /><br /><div class="Tags">Technorati tags: <a href="http://technorati.com/tag/del.icio.us" rel="tag">del.icio.us</a>, <a href="http://technorati.com/tag/delicious" rel="tag">delicious</a>, <a href="http://technorati.com/tag/json" rel="tag">json</a>, <a href="http://technorati.com/tag/jsonp" rel="tag">jsonp</a>, <a href="http://technorati.com/tag/callback" rel="tag">callback</a></div>Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com0tag:blogger.com,1999:blog-5992049.post-1140091758790611072006-02-16T20:36:00.000+09:002006-10-26T14:50:18.770+09:00JSONP Service and SecurityBefore 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 (<a href="http://www.mozilla.org/projects/security/components/same-origin.html">same-origin policy</a>), there might be same or similar concerns in JSONP service. <br /><br />Let's consider <span style="font-style:italic;">Site Y</span> is a JSONP service site (like Yahoo), and <span style="font-style:italic;">Site M</span> is your JSONP mashup site, and <span style="font-style:italic;">User u</span> is a visitor to <span style="font-style:italic;">Site M</span>. <span style="font-style:italic;">Site O</span> is a simple web service provider nothing related to these services, but might be an atacker's target.<br /><br />(Note that these are only my guesses) <br /><br /><h4><br />If <span style="font-style:italic;">M</span> is malicious, can <span style="font-style:italic;">M</span> steal the identity information of <span style="font-style:italic;">u</span> in <span style="font-style:italic;">Y</span> ?<br /></h4><br /><br /><span style="font-style:italic;">M</span> cannot steal it without cooperation of <span style="font-style:italic;">Y</span>. If <span style="font-style:italic;">Y</span> have a unrestricted JSONP interface to access <span style="font-style:italic;">u</span>'s identity information, <span style="font-style:italic;">M</span> can. If there's no consent of <span style="font-style:italic;">u</span>, <span style="font-style:italic;">Y</span> should be responsible for unintended usage of <span style="font-style:italic;">u</span>'s identity information.<br /><br /><h4><br />If <span style="font-style:italic;">Y</span> is malicious, can <span style="font-style:italic;">Y</span> effect bad thing (information theft, session hijack) to <span style="font-style:italic;">M</span> ?<br /></h4><br /><br />Absolutely <span style="font-style:italic;">Y</span> 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 <span style="font-style:italic;">Y</span>. Loaded code is automatically executed without any validation (this is a key point of JSONP) and the excecution priviledge become that of <span style="font-style:italic;">Site M</span>. So <span style="font-style:italic;">M</span> have to do trust <span style="font-style:italic;">Y</span> as long as <span style="font-style:italic;">M</span> is using <span style="font-style:italic;">Y</span>'s service.<br /><br /><h4><br />If <span style="font-style:italic;">Y</span> become suddenly malicious, and the loaded code effected bad to <span style="font-style:italic;">M</span>, who is responsible ?<br /></h4><br /><br />Of course <span style="font-style:italic;">Y</span> is responsible basically. If the information theft is <span style="font-style:italic;">u</span>'s identity information in <span style="font-style:italic;">M</span>, <span style="font-style:italic;">M</span> also should be responsible (about unintended usage of <span style="font-style:italic;">u</span>'s identity information).<br /><br /><h4><br />If <span style="font-style:italic;">Y</span> is malicious, Can <span style="font-style:italic;">Y</span> attack <span style="font-style:italic;">O</span> ?<br /></h4><br /><br />Yes, for example, requesting huge amout of requests to <span style="font-style:italic;">O</span>. And - similar to DDoS - the attacking context become that of <span style="font-style:italic;">User u</span>. But it's not so special case in JSONP service because any malicious site can do that. The main concern here is trust. If <span style="font-style:italic;">User u</span> trusted <span style="font-style:italic;">Site M</span>, and not knowing <span style="font-style:italic;">M</span> is using <span style="font-style:italic;">Y</span>'s service (and <span style="font-style:italic;">u</span> might be not trusting <span style="font-style:italic;">Y</span>), <span style="font-style:italic;">M</span> was responsible for prior explanation about using <span style="font-style:italic;">Y</span>'s services, because, if notified, <span style="font-style:italic;">u</span> might not have used the <span style="font-style:italic;">M</span>'s service. And M should also be responsible for <span style="font-style:italic;">Site O</span><br /><br /><h4><br />Can <span style="font-style:italic;">Y</span> steal the identity information of <span style="font-style:italic;">u</span> in <span style="font-style:italic;">Site O</span> ?<br /></h4><br /><br />Basically no. If there were vulnerabilities in <span style="font-style:italic;">O</span> it might be yes. If <span style="font-style:italic;">u</span> accepted the usage of cross domain XMLHttpRequest in some way (browser setting?), it might also be yes, but it's under <span style="font-style:italic;">u</span>'s responsibility.<br /><br /><h4><br />Can <span style="font-style:italic;">Y</span> affect the transaction between <span style="font-style:italic;">u</span> and <span style="font-style:italic;">O</span> ?<br /></h4><br /><br />Basically no. If there were vulnerabilities in <span style="font-style:italic;">O</span> it might be yes. <a href="http://en.wikipedia.org/wiki/Cross-site_request_forgery">CSRF</a> might be one of them. <span style="font-style:italic;">O</span> should be responsible with its own vulnerability.<br /><br /><div class="Tags">Technorati tags: <a href="http://technorati.com/tag/json" rel="tag">json</a>, <a href="http://technorati.com/tag/jsonp" rel="tag">jsonp</a>, <a href="http://technorati.com/tag/security" rel="tag">security</a>, <a href="http://technorati.com/tag/web2.0" rel="tag">web2.0</a></div>Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com0tag:blogger.com,1999:blog-5992049.post-1139625437689888252006-02-11T11:20:00.000+09:002006-10-26T14:50:18.715+09:00JSON with Padding TesterAgainst 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.<br /><br />As I posted <a href="http://personalized20.blogspot.com/2006/02/remoting-technique-in-personalized-20.html">before</a>, <a href="http://ajaxpatterns.org/On-Demand_Javascript">On-Demand Javascript</a> and <a href="http://www.crockford.com/JSON/index.html">JSON </a>combination is really nice, and a protocol called <a href="http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/">JSONP</a> (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 <a href="https://addons.mozilla.org/extensions/moreinfo.php?id=1843&application=firefox">FireBug</a>) ), jsonp seems cannot. <br /><br />So I created a tiny testing tool to cover this. By <a href="http://www.geocities.jp/stormriders999/jsontest.html">JSON with Padding Test</a> , 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.<br /><br /><div class="Tags">Technorati tags: <a href="http://technorati.com/tag/json" rel="tag">json</a>, <a href="http://technorati.com/tag/jsonp" rel="tag">jsonp</a>, <a href="http://technorati.com/tag/web2.0" rel="tag">web2.0</a></div>Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com1tag:blogger.com,1999:blog-5992049.post-1139494154111319482006-02-09T22:22:00.000+09:002006-10-26T14:50:18.651+09:00Remoting Technique in Personalized 2.0 ServicesWhile I am wanting to connect to all services around the world, remoting from web browser is really needed. XMLHttpRequest, which is said to be a key element of Ajax, enables the browser to retrieve data asynchronously from server-side services. Due to this function, we can assume a web browser like a web service client. But by following reasons I don't like so much to use this.<br /><br />The most disappointing thing about XMLHttpRequest is - it cannot reach services provided from other domains. This restriction might be come from some security or privacy concern. To avoid this restriction, a technique is often used, <a href="http://ajaxpatterns.org/Cross-Domain_Proxy">Cross Domain Proxy</a>. However, the necessity of the server to be located in the same domain and proxy browser's all request prevents from scaling.<br /><br />By the way, XMLHttpRequest is not the only one to get asynchronous data. There is another way for browser to retrieve service information dynamically - it is called <a href="http://ajaxpatterns.org/On-Demand_Javascript">On-demand Javascript</a> and <a href="http://www.crockford.com/JSON/index.html">JSON </a>combination.<br /><br />JSON is a data format and can be directly parsed by Javascript engine. This is done by calling <span style="font-style:italic;">eval()</span> function of Javascript. For some security reason eval function is not so recommended for the remotely retrieved data, but if the remote service itself is trusted <span style="font-style:italic;">eval()</span> function is very useful. <br /><br />However, in On-demand Javascript pattern, we don't use <span style="font-style:italic;">eval()</span> function. There are several way to evaluate JSON data - <a href="http://del.icio.us/help/json">del.icio.us JSON feed</a> is one of the way to include remotely provided JSON object. The most useful way to do this is , I think, the idea called <a href="http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/">jsonp</a> - (JSON padding). This is something like a protocol between JavaScript client and JSON server - giving callback function name inside of url parameter, and returning the Javascript callback function and JSON data as a function's argument. This idea is also seen in <a href="http://developer.yahoo.net/common/json.html">Yahoo Web Services with JSON output</a>, and it works well.<br /><br />One really good thing of On-demand Javascript and JSON, compared with XMLHttpRequest and Cross Domain Proxy, is that they don't have the complexity in authenticating user. Almost all web applications now maintain user's session by cookies, and they are automatically sent while requesting url. Because On-demand Javascript loading request is totally same as usual browser request, a JSON server can specify the requesting user by the cookies previously given. <br /><br />On the other hand, Cross Domain Proxy can request remote resources, but the actual requester is local server, not browser, so no cookies available. Because authentication is always needed to access control or personalize service information, the local server has to keep the end user's credential for the remote service.<br /><br />For these reasons, I adopt On-demand Javascript and JSON call for remoting technique. It can be regareded as one of the user centric approach. Anyway my true interest is to share personalized or individual data (that is, identity-aware data) from anywhere in the world. Next post is going to be about that.<br /><br /><br /><div class="Tags">Technorati tags: <a href="http://technorati.com/tag/json" rel="tag">json</a>, <a href="http://technorati.com/tag/jsonp" rel="tag">jsonp</a>, <a href="http://technorati.com/tag/remoting" rel="tag">remoting</a>, <a href="http://technorati.com/tag/ajax" rel="tag">ajax</a>, <a href="http://technorati.com/tag/web2.0" rel="tag">web2.0</a></div>Shinichi Tomitahttp://www.blogger.com/profile/07610874657513123637noreply@blogger.com0