-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2025/
-----------------------------------------------------------
(Updated 2011-09-29 17:03:35.492298)
Review request for shindig, Paul Lindner, johnfargo, Ryan Baxter, Jesse
Ciancetta, and Stanton Sievers.
Changes
-------
Adding Jesse. Could you please take a look at these changes?
A new review with the feature work is in the works, but this lays down most of
the foundation for it.
Summary
-------
Sorry for the crazy diffs here. Much stuff has moved around.
This is the cleanup part of the patch, I want a few good eyes first before I
move on to the feature work.
Some highlights:
* org.apache.shindig.gadgets.uri.DefaultIframeUriManager
Nearly everything relating to locked domains has been moved to
org.apache.shindig.gadgets.LockedDomainService
Removed validation on uri for locked domains from this class. It was never
actually used.
* org.apache.shindig.gadgets.uri.ProxyUriBase
Removed check for INVALID_DOMAIN, nothing in the code paths leading there ever
set that status.
* org.apache.shindig.gadgets.uri.UriStatus
Removed INVALID_DOMAIN, it was not used anymore. This class seems more focused
on caching anyway.
* org.apache.shindig.gadgets.HashLockedDomainService
Implemented new methods added to interface. Renamed some methods for clarity
and java convention.
Augmented some existing implementation from code that used to be in
org.apache.shindig.gadgets.uri.DefaultIframeUriManager
For documentation purposes:
I looked through what appears to be 3 proxies.
* Content proxy - gadgets.io.getProxyUrl
* makeRequest proxy - gadgets.io.makeRequest
* RPC Proxy - osapi.http.get
Content proxy denies all requests to a locked domain by default. It's assumed
that it's configured on a url that would ensure it is only used for things like
image or sctipt tags, etc.
makeRequest does not appear to do any locked domain checking to make sure the
gadget is valid for the locked domain. While it's reasonable to assume a
malicious gadget will not use the locked domain url of another gadget, it's
possible it could craft a request to the proxy on its own locked domain and
forge the gadget passed in to appear as another gadget. I'll be making changes
to this proxy to include locked domain validation.
RPC Proxy appears to be made from the container on behalf of a gadget, the
gadget passed in should be legitimate. I have not tried to make this request
on a locked domain to see if the proxy will respond. (Gadget pretending to be
the container making the request)
This addresses bug SHINDIG-1628.
https://issues.apache.org/jira/browse/SHINDIG-1628
Diffs
-----
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/HashLockedDomainService.java
1174376
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/LockedDomainService.java
1174376
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/ProxyHandler.java
1174376
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/DefaultIframeUriManager.java
1174376
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/ProxyUriBase.java
1174376
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/UriStatus.java
1174376
http://svn.apache.org/repos/asf/shindig/trunk/php/test/gadgets/ContainerConfigTest.php
1174376
http://svn.apache.org/repos/asf/shindig/trunk/config/container.js 1174376
Diff: https://reviews.apache.org/r/2025/diff
Testing
-------
Thanks,
Dan
