Hi,
by my way trying to continue developing I found some evidence that the
filter actual does something.
In my test environment I deployed an XML module definition, which
loads several files from a local server (localhost:8080), all these
files are correctly returned by the proxy module - without beeing
modified. Which is somehow surprising because the proxy uses some
local JavaScript as well (but that is another area for problems).
So far - so good, but when I try to use _IG_Fetch* for the same
address, I only receive this funny message:
throw 1; < don't be evil' >{ }
In other words there is a filter but I only filters some parts, whole
files with code could be uploaded and pass the filter but AJAX
requests through the defined API are restricted. Any questions - any
more?
On 11 Nov., 20:50, siegi <[EMAIL PROTECTED]> wrote:
> 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 [email protected]
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
-~----------~----~----~----~------~----~------~--~---
