I dislike white-lists a lot since it makes running 'any gadget' on a
social network site a -lot- more human effort dependent.
Especially if a gadget developer would have to send an email to
hundreds to thousands of different open social enabled sites, every
time they makeRequest to a new domain ... that just doesn't scale and
will lead to a lot of broken gadgets... Of course if you have a very
tightly controlled environment where you wrote all the gadgets your
self that might work, but otherwise it would be a recipe for disaster.
Besides that would be an open social spec change, and those
discussions belong on the the spec discussion group: [EMAIL PROTECTED]
and not in shindig land, we implement the spec we don't create it :)
I think adding a security token, that included the IP would already
provide a good solid security model to prevent abuse, and i don't
think it would break existing gadgets nor change the specification, so
i'd strongly prefer that.
-- Chris
On Jul 11, 2008, at 2:59 PM, Karsten Beyer wrote:
Hi,
i don't understand. The proxy is even delivering pages when there is
no
security token at all. e.g.
http://shindig.mydomain/gadgets/proxy?url=google.com
At the server the page is requested from, there is no indication,
that it is
fetched by a proxy. There could be severe legal trouble if someone
abuses
our open proxy to do something illegal as we have no way to prove
otherwise.
So my idea was to whitelist the domains from which the proxy will
fetch
content.
Best Regards
Karsten Beyer
On Fri, Jul 11, 2008 at 2:19 PM, Ropu <[EMAIL PROTECTED]> wrote:
U can try adding the ip the the Security Token too.
ropu
On Fri, Jul 11, 2008 at 6:20 AM, Karsten Beyer <[EMAIL PROTECTED]>
wrote:
Hi,
what is the suggested strategy to prevent abuse of the open proxy at
/gadgets/proxy? I found some old discussions from february about
adding
the
IP address of the user as HTTP header. Some testing however showed
that
this
is not yet implemented.
Are there any plans to implement some kind of whitelist feature?
More
importantly: Are there any reasons against implementing such a
feature?
Best Regards,
Karsten Beyer
[EMAIL PROTECTED]
--
.-. --- .--. ..-
R o p u
