You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Nuwan Bandara <nu...@wso2.com> on 2009/09/27 18:38:58 UTC
Like to contribute
Hello,
I would like to contribute to shindig development and for its growth.
--
Thanks & Regards
/Nuwan Bandara
RE: Reverse proxy and URL gadgets
Posted by "Weygandt, Jon" <jw...@ebay.com>.
Bullet point #6c of section 3.1.3 - Compliance: Gadget Server - Process;
of the Gadgets API Specifiction describes one method:
http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Gadget
s-API-Specification.html#process
iGoogle originally implemented this.
-----Original Message-----
From: Kevin Brown [mailto:etnu@google.com]
Sent: Tuesday, September 29, 2009 10:05 PM
To: shindig-dev@incubator.apache.org
Subject: Re: Reverse proxy and URL gadgets
On Mon, Sep 28, 2009 at 4:32 AM, <sa...@wipro.com> wrote:
> Hi,
>
> Working with Shindig we have come across some use cases for which we
> modified shindig code base.
>
> 1. For URL gadgets shindig do redirect to the gadget URL, however in
> the reverse proxy it's an issue for web masters. So we have modified
> that part to respond as HTTP 200 (no redirect).
>
> 2. Why shindig does not support the JS features for URL gadgets? [One
> reason could be cross site scripting but in *a company setup* with
> *reverse
> proxy* this can be useful feature to have]
>
What do you mean by "support"? How would shindig "support" getting the
JS code into the third-party iframe?
>
> 3. Request parameter passing to all gadgets - We have modified Shindig
> to pass all the request parameters to the gadgets in a page.
>
> We have these features implemented, we love to get an opinion of the
> community regarding these changes.
>
> Thanks,
>
> Samik
>
> Please do not print this email unless it is absolutely necessary.
>
> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of the
> addressee(s) and may contain proprietary, confidential or privileged
> information. If you are not the intended recipient, you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately and destroy all copies of this message and any
attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient
> should check this email and any attachments for the presence of
> viruses. The company accepts no liability for any damage caused by any
> virus transmitted by this email.
>
> www.wipro.com
>
Re: Reverse proxy and URL gadgets
Posted by Kevin Brown <et...@google.com>.
On Mon, Sep 28, 2009 at 4:32 AM, <sa...@wipro.com> wrote:
> Hi,
>
> Working with Shindig we have come across some use cases for which we
> modified shindig code base.
>
> 1. For URL gadgets shindig do redirect to the gadget URL, however in the
> reverse proxy it's an issue for web masters. So we have modified that part
> to respond as HTTP 200 (no redirect).
>
> 2. Why shindig does not support the JS features for URL gadgets? [One
> reason could be cross site scripting but in *a company setup* with *reverse
> proxy* this can be useful feature to have]
>
What do you mean by "support"? How would shindig "support" getting the JS
code into the third-party iframe?
>
> 3. Request parameter passing to all gadgets - We have modified Shindig to
> pass all the request parameters to the gadgets in a page.
>
> We have these features implemented, we love to get an opinion of the
> community regarding these changes.
>
> Thanks,
>
> Samik
>
> Please do not print this email unless it is absolutely necessary.
>
> The information contained in this electronic message and any attachments to
> this message are intended for the exclusive use of the addressee(s) and may
> contain proprietary, confidential or privileged information. If you are not
> the intended recipient, you should not disseminate, distribute or copy this
> e-mail. Please notify the sender immediately and destroy all copies of this
> message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient
> should check this email and any attachments for the presence of viruses. The
> company accepts no liability for any damage caused by any virus transmitted
> by this email.
>
> www.wipro.com
>
RE: Reverse proxy and URL gadgets
Posted by "Weygandt, Jon" <jw...@ebay.com>.
For the basics of the rendering parameters...
For the request parameters, are you talking about what is in bullet item
6?
http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Gadget
s-API-Specification.html#rfc.section.3.1
The ones we found missing for URL developer consumption, but were
already part of Shindig's iframe url, were: view, view-params.
We also added one additional parameters for developers: env - to let
them know what environment they are running in, e.g. production, sandbox
and dev.
For our use (not gadget developers use) we need: parent, rpctoken
We do security in our own way, since we are integrating to legacy
applications. Our security token is very long, so the resultant request
must be done by a POST, as the URL exceeds IE's limit of 2000 rather
quickly. It is through the security tokens that the developer gets the
equivalent of viewer. Plus our tokens are time stamped so caching is not
an issue for us. makeRequest documents signing by Oauth, which might be
more applicable.
For the JS libraries...
In order to make use of as much of the JS functions as possible, you
need things like hangman substituted messages and preloads. These are
very dependent upon what the users specific parameters were, and make
Facebook's approach with static JS less desirable. And the "libs"
approach of iGoogle require a more stateful server (a problem with a
cluster of machines). So once we went with the POST the limit on
parameter size was lifted. We put everything needed into a single "is"
parameter. It includes <script src=...> tags, it includes the call to
gadgets.config, plus a bit more. Plus this parameter is signed to
ensure it is not tampered with. Once we did this, large pieces of the
core JS API works.
The other item is that gadgets core, and rpc use document.location. For
obvious things like prefs, but also for rpctoken and parent. This is OK
for the very first render, but most URL developers will have multiple
pages. For this the "is" parameter includes a "fake url" that can be
parsed inside of the gadgets API to get the info, simply replaced
document.location with "gadgets_location_href_override ||
document.location.href;"
For a limited JS functionality...
If all we want is basic rpc/pubsub, static JS includes would be fine.
This may be a good starting point for a standard implementation. The
goals would be to ensure security and portability (if possible)
Security - at least today, the gadget developer needs to run (and trust)
JS code from the gadget server.
Portability - can we create a method that will let developers run on
multiple sites, hopefully w/o a whitelist of trusted sites?
-----Original Message-----
From: samik.chakraborty@wipro.com [mailto:samik.chakraborty@wipro.com]
Sent: Monday, September 28, 2009 12:09 PM
To: shindig-dev@incubator.apache.org
Subject: RE: Reverse proxy and URL gadgets
Yes we can work for a common solution to this problem and a standard way
to integrate these gadgets.* API features for URL gadgets. For starter
we can target pubsub, dynamic height (as we also have found them very
much required and we have them implemented in our Shindig code base).
Also for #3 if we can have a standard way for forwarding the request
paramters to the URL gadgets that will reduce the use of makRequest
calls - this as we have seen increases the server round trips.
Thanks,
Samik
________________________________
From: Weygandt, Jon [mailto:jweygandt@ebay.com]
Sent: Mon 9/28/2009 11:44 PM
To: shindig-dev@incubator.apache.org
Subject: RE: Reverse proxy and URL gadgets
Regarding #2, parts of the JS features have been implemented for URL
gadgets
Myspace:
http://wiki.developer.myspace.com/index.php?title=Messaging_from_an_IFra
me
eBay:
http://developer.ebay.com/DevZone/selling-manager-applications/Concepts/
SellingManagerApps_APIGuide.html#starting
iGoggle: with "limited" support for gadgets.* API, using the libs
parameter.
I wonder if there are other examples?
All of these have different methods for inclusion of the JS, which is a
problem for writing portable gadgets. I believe the most important
feature to support is RPC and dynamic height. In the future pubsub will
also be valuable. Features like makeRequest, and by extension the
OpenSocial data requests, are difficult to support due to the same
origin policy for XMLHttpRequest. But then, gadget developers choosing
to do a URL gadget can use REST and RPC.
There's an interesting proposal for OpenSocial, but not for v1.0,
regarding this:
http://wiki.opensocial.org/index.php?title=Support_iframe_model_applicat
ion_in_gadget_spec
While we have already solved this, if there is interest, I'd be
interested in working for a common solution.
Jon
-----Original Message-----
From: samik.chakraborty@wipro.com [mailto:samik.chakraborty@wipro.com]
Sent: Monday, September 28, 2009 4:33 AM
To: shindig-dev@incubator.apache.org
Subject: Reverse proxy and URL gadgets
Hi,
Working with Shindig we have come across some use cases for which we
modified shindig code base.
1. For URL gadgets shindig do redirect to the gadget URL, however in the
reverse proxy it's an issue for web masters. So we have modified that
part to respond as HTTP 200 (no redirect).
2. Why shindig does not support the JS features for URL gadgets? [One
reason could be cross site scripting but in *a company setup* with
*reverse proxy* this can be useful feature to have]
3. Request parameter passing to all gadgets - We have modified Shindig
to pass all the request parameters to the gadgets in a page.
We have these features implemented, we love to get an opinion of the
community regarding these changes.
Thanks,
Samik
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressee(s)
and may contain proprietary, confidential or privileged information. If
you are not the intended recipient, you should not disseminate,
distribute or copy this e-mail. Please notify the sender immediately and
destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient
should check this email and any attachments for the presence of viruses.
The company accepts no liability for any damage caused by any virus
transmitted by this email.
www.wipro.com
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressee(s)
and may contain proprietary, confidential or privileged information. If
you are not the intended recipient, you should not disseminate,
distribute or copy this e-mail. Please notify the sender immediately and
destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient
should check this email and any attachments for the presence of viruses.
The company accepts no liability for any damage caused by any virus
transmitted by this email.
www.wipro.com
RE: Reverse proxy and URL gadgets
Posted by sa...@wipro.com.
Yes we can work for a common solution to this problem and a standard way to integrate these gadgets.* API features for URL gadgets. For starter we can target pubsub, dynamic height (as we also have found them very much required and we have them implemented in our Shindig code base).
Also for #3 if we can have a standard way for forwarding the request paramters to the URL gadgets that will reduce the use of makRequest calls - this as we have seen increases the server round trips.
Thanks,
Samik
________________________________
From: Weygandt, Jon [mailto:jweygandt@ebay.com]
Sent: Mon 9/28/2009 11:44 PM
To: shindig-dev@incubator.apache.org
Subject: RE: Reverse proxy and URL gadgets
Regarding #2, parts of the JS features have been implemented for URL
gadgets
Myspace:
http://wiki.developer.myspace.com/index.php?title=Messaging_from_an_IFra
me
eBay:
http://developer.ebay.com/DevZone/selling-manager-applications/Concepts/
SellingManagerApps_APIGuide.html#starting
iGoggle: with "limited" support for gadgets.* API, using the libs
parameter.
I wonder if there are other examples?
All of these have different methods for inclusion of the JS, which is a
problem for writing portable gadgets. I believe the most important
feature to support is RPC and dynamic height. In the future pubsub will
also be valuable. Features like makeRequest, and by extension the
OpenSocial data requests, are difficult to support due to the same
origin policy for XMLHttpRequest. But then, gadget developers choosing
to do a URL gadget can use REST and RPC.
There's an interesting proposal for OpenSocial, but not for v1.0,
regarding this:
http://wiki.opensocial.org/index.php?title=Support_iframe_model_applicat
ion_in_gadget_spec
While we have already solved this, if there is interest, I'd be
interested in working for a common solution.
Jon
-----Original Message-----
From: samik.chakraborty@wipro.com [mailto:samik.chakraborty@wipro.com]
Sent: Monday, September 28, 2009 4:33 AM
To: shindig-dev@incubator.apache.org
Subject: Reverse proxy and URL gadgets
Hi,
Working with Shindig we have come across some use cases for which we
modified shindig code base.
1. For URL gadgets shindig do redirect to the gadget URL, however in the
reverse proxy it's an issue for web masters. So we have modified that
part to respond as HTTP 200 (no redirect).
2. Why shindig does not support the JS features for URL gadgets? [One
reason could be cross site scripting but in *a company setup* with
*reverse proxy* this can be useful feature to have]
3. Request parameter passing to all gadgets - We have modified Shindig
to pass all the request parameters to the gadgets in a page.
We have these features implemented, we love to get an opinion of the
community regarding these changes.
Thanks,
Samik
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressee(s)
and may contain proprietary, confidential or privileged information. If
you are not the intended recipient, you should not disseminate,
distribute or copy this e-mail. Please notify the sender immediately and
destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient
should check this email and any attachments for the presence of viruses.
The company accepts no liability for any damage caused by any virus
transmitted by this email.
www.wipro.com
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
RE: Reverse proxy and URL gadgets
Posted by "Weygandt, Jon" <jw...@ebay.com>.
Regarding #2, parts of the JS features have been implemented for URL
gadgets
Myspace:
http://wiki.developer.myspace.com/index.php?title=Messaging_from_an_IFra
me
eBay:
http://developer.ebay.com/DevZone/selling-manager-applications/Concepts/
SellingManagerApps_APIGuide.html#starting
iGoggle: with "limited" support for gadgets.* API, using the libs
parameter.
I wonder if there are other examples?
All of these have different methods for inclusion of the JS, which is a
problem for writing portable gadgets. I believe the most important
feature to support is RPC and dynamic height. In the future pubsub will
also be valuable. Features like makeRequest, and by extension the
OpenSocial data requests, are difficult to support due to the same
origin policy for XMLHttpRequest. But then, gadget developers choosing
to do a URL gadget can use REST and RPC.
There's an interesting proposal for OpenSocial, but not for v1.0,
regarding this:
http://wiki.opensocial.org/index.php?title=Support_iframe_model_applicat
ion_in_gadget_spec
While we have already solved this, if there is interest, I'd be
interested in working for a common solution.
Jon
-----Original Message-----
From: samik.chakraborty@wipro.com [mailto:samik.chakraborty@wipro.com]
Sent: Monday, September 28, 2009 4:33 AM
To: shindig-dev@incubator.apache.org
Subject: Reverse proxy and URL gadgets
Hi,
Working with Shindig we have come across some use cases for which we
modified shindig code base.
1. For URL gadgets shindig do redirect to the gadget URL, however in the
reverse proxy it's an issue for web masters. So we have modified that
part to respond as HTTP 200 (no redirect).
2. Why shindig does not support the JS features for URL gadgets? [One
reason could be cross site scripting but in *a company setup* with
*reverse proxy* this can be useful feature to have]
3. Request parameter passing to all gadgets - We have modified Shindig
to pass all the request parameters to the gadgets in a page.
We have these features implemented, we love to get an opinion of the
community regarding these changes.
Thanks,
Samik
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressee(s)
and may contain proprietary, confidential or privileged information. If
you are not the intended recipient, you should not disseminate,
distribute or copy this e-mail. Please notify the sender immediately and
destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient
should check this email and any attachments for the presence of viruses.
The company accepts no liability for any damage caused by any virus
transmitted by this email.
www.wipro.com
Reverse proxy and URL gadgets
Posted by sa...@wipro.com.
Hi,
Working with Shindig we have come across some use cases for which we modified shindig code base.
1. For URL gadgets shindig do redirect to the gadget URL, however in the reverse proxy it's an issue for web masters. So we have modified that part to respond as HTTP 200 (no redirect).
2. Why shindig does not support the JS features for URL gadgets? [One reason could be cross site scripting but in *a company setup* with *reverse proxy* this can be useful feature to have]
3. Request parameter passing to all gadgets - We have modified Shindig to pass all the request parameters to the gadgets in a page.
We have these features implemented, we love to get an opinion of the community regarding these changes.
Thanks,
Samik
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
Re: Like to contribute
Posted by Chris Chabot <ch...@google.com>.
Hey Nuwan,
I'm not sure what to say other then "great! go for it!"
You can find the details on our svn repo, and of our bug tracking system
where you can create issues & attach our patches too at
http://incubator.apache.org/shindig/ & if there's anything we can do to help
with, please feel free to post your questions to the shindig-dev list.
On Sun, Sep 27, 2009 at 6:38 PM, Nuwan Bandara <nu...@wso2.com> wrote:
> Hello,
>
> I would like to contribute to shindig development and for its growth.
>
> --
> Thanks & Regards
> /Nuwan Bandara
>