tag:blogger.com,1999:blog-8112154.post6394477207194013716..comments2024-03-19T08:55:45.961+05:30Comments on blog.rakeshpai.me: How To Build A Read/Write JavaScript APIRakesh Paihttp://www.blogger.com/profile/00328152982823663876noreply@blogger.comBlogger19125tag:blogger.com,1999:blog-8112154.post-40365953698359178512011-07-28T06:58:48.752+05:302011-07-28T06:58:48.752+05:30You can actually learn A LOT developing for a CMS....You can actually learn A LOT developing for a CMS. ThanksMartin Lapietrahttp://www.lapietradaterra.com.arnoreply@blogger.comtag:blogger.com,1999:blog-8112154.post-65068338674688522122010-01-13T16:58:44.107+05:302010-01-13T16:58:44.107+05:30levidad, awesome. Will be looking forward to your ...levidad, awesome. Will be looking forward to your post. Do let me know.Rakesh Paihttps://www.blogger.com/profile/00328152982823663876noreply@blogger.comtag:blogger.com,1999:blog-8112154.post-19514080643062420962010-01-13T08:43:37.094+05:302010-01-13T08:43:37.094+05:30Hi, Rakesh, thanks for the help! With your informa...Hi, Rakesh, thanks for the help! With your information I was able to make it work and finish the core functionality.<br /><br />You asked where and how I was going to use that. It is that my company is going to build kind of a JavaScript API for a client that does not want its users to have to download the javascript file. It must be as simple as including a reference to the library in the page a calling a function for displaying some ads in a div of their choice. I thought I would help and research some cross-domain techniques and found yours interesting compared to others I've seen.<br /><br />The API is not complete yet, it lacks some tuning, but that's easy work now. When it's done I will post an article in a blog I'm going to start, publishing my source code so that others can improve and extend it, and when that happens I'll remember to point this page of yours as the source of the technique, and I can also post a comment here with the link to my source code.<br /><br />Thanks again and take care!Phillippe Santanahttps://www.blogger.com/profile/15183290949125416737noreply@blogger.comtag:blogger.com,1999:blog-8112154.post-58276271625631450662010-01-09T13:08:53.227+05:302010-01-09T13:08:53.227+05:30levidad,
I guess I should've explained that b...levidad,<br /><br />I guess I should've explained that better. The only way I've been able to do this is to look for an identifier in the data that signals that the data is complete. For example, you could terminate the data with something like "||end||" or such to indicate that there's nothing more to be flushed down.<br /><br />The client meanwhile, polls the iframe, assembles the data, and checks if the data ends with ||end||. If it doesn't, there's more to be read. If it does, the ||end|| can be stripped, and the rest of the data can be used.<br /><br />It's nice to know you are using this technique. Would be great if you can write about your experience using it. I'll look forward to it. Would also be great if you can show what you are using it for.Rakesh Paihttps://www.blogger.com/profile/00328152982823663876noreply@blogger.comtag:blogger.com,1999:blog-8112154.post-84168818840812358172010-01-09T06:54:04.555+05:302010-01-09T06:54:04.555+05:30Hello, Rakesh, very nice post!
I'm trying to ...Hello, Rakesh, very nice post!<br /><br />I'm trying to implement your technique and I'm almost there. I just can't figure out one thing though: the server builds as many iframes as needed to fragment the data. How to make sure that all the response markup has finished loading so that I can access the iframes from my js API?<br /><br />Because right after I call the close method of the iframe to send the request (as you describe in step 4) the next line gets executed (the one that tries to retrieve the data from the response iframes), and as the response hasn't yet arrived there is no data to collect, no iframes to be found...<br /><br />I have searched a lot (you wouldn't believe) and couldn't figure that out. I've read about closures but still can't see how it fits into this scenario.<br /><br />If you could provide a sample implementation of your technique, it would be most helpful.<br /><br />Thanks in advance!Phillippe Santanahttps://www.blogger.com/profile/15183290949125416737noreply@blogger.comtag:blogger.com,1999:blog-8112154.post-70762956176632970162008-03-14T21:37:00.000+05:302008-03-14T21:37:00.000+05:30Yes. In the case of Beacon it's only Beacon part...Yes. In the case of Beacon it's only Beacon partners that get a key and that's a whole contractual process - not exactly scalable/viral but it doesn't have to be for them. Another route is to charge some small amount for a key and ask for a credit card. Or freely give keys that access your test environment but charge for production keys.<BR/><BR/>Thanks for your reply.Eric Phttps://www.blogger.com/profile/01588189056604414087noreply@blogger.comtag:blogger.com,1999:blog-8112154.post-69344243980880047662008-03-14T20:30:00.000+05:302008-03-14T20:30:00.000+05:30True. I agree completely.Now only if we could find...True. I agree completely.<BR/><BR/>Now only if we could find a decent way to decide who should get an API key.Rakesh Paihttps://www.blogger.com/profile/00328152982823663876noreply@blogger.comtag:blogger.com,1999:blog-8112154.post-26940079508170376602008-03-14T20:05:00.000+05:302008-03-14T20:05:00.000+05:30True. But if your widget/mashup/API is being used...True. But if your widget/mashup/API is being used on lots of sites it could be inconvenient for the user to have to grant access to each site. You would have to balance this against the sensitivity of the data being delivered by the API or the potential destructiveness/spamminess of the API on the server side.<BR/><BR/>But if you could securely verify that the domain of the hosting page matched the domain of the API key, and the API keys were granted in a secure fashion (ie, not just anyone can get one), then you could grant access to the site based on their API key.<BR/><BR/>I'm thinking about Facebook Beacon as an example here.Eric Phttps://www.blogger.com/profile/01588189056604414087noreply@blogger.comtag:blogger.com,1999:blog-8112154.post-13179400269014806592008-03-14T14:01:00.000+05:302008-03-14T14:01:00.000+05:30Hi Eric.The idea of this technique is to _give_ ac...Hi Eric.<BR/><BR/>The idea of this technique is to _give_ access to other sites that want authenticated user data.<BR/><BR/>The best (and probably sufficient) way to ensure that this data doesn't fall into unauthorized hands is to have the user opt-in to give the data to any site he wishes. This can be done using simple mechanisms - like what Google Calendar API currently does. It's kind of like an OpenID authentication of sorts, having a similar user experience.Rakesh Paihttps://www.blogger.com/profile/00328152982823663876noreply@blogger.comtag:blogger.com,1999:blog-8112154.post-86762189214394543982008-03-14T09:59:00.000+05:302008-03-14T09:59:00.000+05:30My bad, I missed the part in step 7 where you expl...My bad, I missed the part in step 7 where you explain how the static resource is used.<BR/><BR/>I still have a general question about how this approach prevents sites that trying to use your API to gain access to your authenticated user's data.Eric Phttps://www.blogger.com/profile/01588189056604414087noreply@blogger.comtag:blogger.com,1999:blog-8112154.post-80292220591611189792008-03-14T08:41:00.000+05:302008-03-14T08:41:00.000+05:30In step 2 I am assuming that they are verifying th...In step 2 I am assuming that they are verifying the domain of the parent page so the can match it up against an API key on their end to prevent evil sites from silently accessing people's calendars. You say that The URL of this resource is stored for use later. How is it stored such that they prevent the parent page from substituting in a "trusted" domain that may already be authenticated? (a version of a CSRF attack)Eric Phttps://www.blogger.com/profile/01588189056604414087noreply@blogger.comtag:blogger.com,1999:blog-8112154.post-51117966205855956652008-03-05T19:05:00.000+05:302008-03-05T19:05:00.000+05:30Anonymous,It sounds like you might be right about ...Anonymous,<BR/><BR/>It sounds like you might be right about the domain switching thing in the context of sub domains. I will have to try it out to be sure. I shall get back to you about it soon.Rakesh Paihttps://www.blogger.com/profile/00328152982823663876noreply@blogger.comtag:blogger.com,1999:blog-8112154.post-70427285713031037822008-03-03T00:53:00.000+05:302008-03-03T00:53:00.000+05:30Thanks for the answer!I assume that you without pr...Thanks for the answer!<BR/>I assume that you without problem can shorten document.domain in the parent window. But if you for example set the iframe src to a static resource image located at images.example.com, is it in some way possible to shorten the document.domain also for the grandchild iframe?<BR/><BR/>I looks like the javascript in the parent window (at example.com) doesn't have permission to shorten the document.domain in the grandchild iframe (at images.example.com).<BR/><BR/>Is it perhaps possible to set the document.domain before the iframe src is loaded?<BR/><BR/>I'm not really a javascript programmer, but I'm always curious when it comes to corner cases like this... :)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8112154.post-35653144109767068422008-02-29T19:57:00.000+05:302008-02-29T19:57:00.000+05:30Anonymous,So, if the static resource is from a dif...Anonymous,<BR/><BR/>So, if the static resource is from a different subdomain within the same domain, you might face a problem in step 8 above. (I say "might" because I haven't tried this as yet. So, obviously, the rest of this comment is just a theory - but one I think should work perfectly.)<BR/><BR/>Now, when polling for the iframe, you won't directly have access to the iframe, since it's of a different document.domain (subdomain included). Moreover, the document.domain cannot be changed. It can, however, be made 'shorter' in some ways. Which means that images.example.com and www.example.com can both have their document.domain shortened to example.com.<BR/><BR/>Once that's done, the parent window and the grandchild iframe can communicate with each other seamlessly.Rakesh Paihttps://www.blogger.com/profile/00328152982823663876noreply@blogger.comtag:blogger.com,1999:blog-8112154.post-33288694061891473072008-02-29T03:01:00.000+05:302008-02-29T03:01:00.000+05:30Great blog post! How do you solve the situation wh...Great blog post! <BR/>How do you solve the situation when: "the static resources I mentioned could even be from a different sub-domain within the same domain"?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8112154.post-36591651554296729252008-02-06T13:08:00.000+05:302008-02-06T13:08:00.000+05:30Hi Ankit,This seems like a fairly basic JavaScript...Hi Ankit,<BR/><BR/>This seems like a fairly basic JavaScript question. AFAIK, there's no easy way to "stall" execution in JavaScript (though I'm fairly sure there can be complex ways of doing it). In any case, you should not need to - it's probably a bad design idea anyway.<BR/><BR/>Instead, you should use the power of closures here. Set all your variables and methods inside the setTimeout if you want to wait for computing results inside the setTimeout first.<BR/><BR/>Since the setTimeout function call is inside the closure, your variable values are "trapped", even if the execution of the constructor is complete, giving you access to all the variables, even letting you set them at a later time.Rakesh Paihttps://www.blogger.com/profile/00328152982823663876noreply@blogger.comtag:blogger.com,1999:blog-8112154.post-57780471856288568752008-02-06T03:13:00.000+05:302008-02-06T03:13:00.000+05:30Hi,Thanks for the great tutorial. I have run into ...Hi,<BR/><BR/>Thanks for the great tutorial. I have run into a problem though. I am creating a new object in my api that has a key. Thus, the constructor takes the key as an argument, connects to the server, retrieves a bunch of information according to the key and stores it in various object variables.<BR/><BR/>function myObject(key) {<BR/>//get info from server (cross domain)<BR/>this.variable = info; //info is obtained from server<BR/>}<BR/><BR/>Now when you say that "polling the iframe it created to check for the existance of child iframes", I couldn't find any other method other than to use the setInterval function to do this. <BR/><BR/><BR/>function myObject(key) {<BR/>//get info from server (cross domain)<BR/>this.func = function () {<BR/>//connect to server via iframe based proxy and get info<BR/>clearInterval(id);<BR/>this.variable = info; //info is obtained from server<BR/>}<BR/>id=setInterval(this.func,10);<BR/>}<BR/><BR/>But now, the constructor ends before the object variables are set!! Is there any way to avoid this? Is there some way to stall the constructor till all object variables are set?Ankithttps://www.blogger.com/profile/03003702806890793158noreply@blogger.comtag:blogger.com,1999:blog-8112154.post-91752445045560913092007-11-21T21:04:00.000+05:302007-11-21T21:04:00.000+05:30Thanks, Alex. I actually did come across your site...Thanks, Alex. I actually did come across your site when researching about how to achieve cross-domain Ajax cleanly. The only reason I gave it a pass (and Subspace and CrossSafe), was because of the setup required for the API user.<BR/><BR/>I guess getting cross-domain Ajax to work has been discussed at length here and elsewhere, and there are various workable solutions at hand. What this solution's USP is that there's absolutely no setup required by API users to start using the API. No DNS (re)mapping, no "put this file on your server", no "use XYZ toolkit to write your JavaScript", nothing. As a bonus, there are no additional resources requested in the form of bridges of any kind.Rakesh Paihttps://www.blogger.com/profile/00328152982823663876noreply@blogger.comtag:blogger.com,1999:blog-8112154.post-21927865187665815322007-11-21T18:55:00.000+05:302007-11-21T18:55:00.000+05:30You will probably want to check outhow to cross do...You will probably want to check out<BR/><BR/><A HREF="http://www.alexpooley.com/2007/08/07/how-to-cross-domain-javascript" REL="nofollow">how to cross domain javascript</A><BR/><BR/>for a clean method of read/write. There's a couple of caveats, but the solution solves many cases.Unknownhttps://www.blogger.com/profile/00828531803677369975noreply@blogger.com