Ok thats a point, thanks for your thoughts. I also do not think that Google will log something but I still can't see a convincing reason for doing so.
Especially the gadget type url method does not need a proxy, all relevant information is within the header. And with respect to security it is much more secure to communicate between two well known hosts than between a client, an unkown proxy and two hosts (app server and network server). Cross site scripting security is in fact blown away by the proxy server - no one knows what is done there - so no control at all. The smart browser who detects that your ajax call is going to another site prohibits the access and allows only access to the proxy - who did not serve the information at all. And what it makes it worth there is that the proxy has no clue (because its API is not specified) to redirect a call to the app server. It is simple as that I, that a proxy removes all security approaches in one go - there is no security at all (I am only speaking of the proxy here). Please compare the scenarios of the gadget types url and html and build yourself a big picture of the wired data access paths. And after been through the stuff compare it with known authentication shemas - I will be surprised if you find one. After that you might want to check the Facebook API because that system is already up and running. I like to come back to my focus, I think for some types of gadget applications a server access to the network for the whole opensocial api will become necessary. Until then, myself and most other developers could live with the existing api and accept insecure and redundant traffic as long as it does not have to be secure or authentic. While the later one is already part of investigation and will hopefully be solved in the near future. On 11 Nov., 20:17, Jattfx <[EMAIL PROTECTED]> wrote: > Why? Because its the only way. Assume siteA is google.com and its > where the app is hosted. The app devolver wants to make a request to > hisite.com which is SiteB. So the only way for siteA to access siteB > and receive response is using a server-sided proxy. The other way > would be to use js ajax requests but there is the cross site security > issue that will block you from doing it. Plus I don't think google are > going to "log" whats being sent thru their servers....wait, nvm, they > log everything else so you probably don't have anything left to hide. > > On Nov 11, 11:46 am, siegi <[EMAIL PROTECTED]> wrote: > > > As far as I understand any data transfered from the module definition > > source and further loads and ajax calls (_IG_Fetch*) is passed or > > filtered through a proxy box. > > > If that is the case then any data is sent to somewhere which is > > neither controlled by the social network nor by the gadget developer. > > > Why is the system designed like this? Who wants to peek every bit > > requested from any gadget? > > > With respect to performance this also not the best solution. > > > I would rather allow direct client gadget communication or filtering > > through the social network servers but no filtering by third party > > servers. > > > Hopefully, I simply did not understand the system architecture right > > and someone from the builders could drop me a correction or an > > alternative method. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OpenSocial Developers" group. To post to this group, send email to opensocial-api@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/opensocial-api?hl=en -~----------~----~----~----~------~----~------~--~---
