As mentioned, this is a good policy, and definitely something that we want to do - but it simply doesn't work, because we output a <base> tag with the gadget URI in it (to make relative URIs work), which makes the scheme relative to the gadget URI, not the iframe renderer. This means that if the gadget URI is on a different scheme to the iframe renderer, you are guaranteeing mixed content warnings, not avoiding them!
I have an example here from a trivial gadget: <Module> <ModulePrefs title="test" /> <Content type="html"> <![CDATA[ ><link rel="stylesheet" href="/static/gadgets/gmail/gmail.css" type="text/css" /> <p>This is just a test.</p> ]]> </Content> </Module> The output from the iframe renderer is: <html><head> <base href="http://start-test.warwick.ac.uk/portal/gadgets/local/example/prefs-test.xml";><!-- snip.... --> <link href="//start-test.warwick.ac.uk/gadgets/proxy?container=warwick&gadget=http%3A%2F%2Fstart-test.warwick.ac.uk%2Fportal%2Fgadgets%2Flocal%2Fexchange%2Fliveedu-mail.xml&debug=0&nocache=0&refresh=3600&url=https%3A%2F%2Fstart-test.warwick.ac.uk%2Fstatic%2Fgadgets%2Fgmail%2Fgmail.css" rel="stylesheet" type="text/css"> </head> <body dir="ltr"> <p>This is just a test.</p> <script>gadgets.util.runOnLoadHandlers();</script></body></html> The link href in this gadget will resolve to http://start-test.warwick.ac.uk/gadgets/proxy (scheme relative to the base href), but the iframe renderer is called from https, thereby throwing mixed content warnings. Mat On 13 August 2010 01:19, John Hjelmstad <[email protected]> wrote: > As has been discussed, the rationale for this is to support HTTP and HTTPS > without mixed-content warnings. > > We could do this easily if we had a context object with the current schema > in it. Some installations of Shindig do, and can override the hook in > DefaultIframeUriManager (and others): > > protected String getScheme(Gadget gadget, String container) { > // Scheme-relative by default. Override for specific use cases. > return null; > } > > > --j > > On Thu, Aug 12, 2010 at 5:07 PM, Gagandeep singh <[email protected]>wrote: > >> Hi Mat, Paul >> >> Sorry for the late response. I tried looking up what the browser behavior >> is >> for uri's without a scheme but could not find anything useful. I have had >> my >> own doubts about schemeless uri's (i still have some), but i vaguely >> remember Ziv explaining and convincing me that it is better to output a >> schemeless uri. The argument was something along the lines that the browser >> can use the same scheme as that of the page that emits the uri and we don't >> go through the trouble of figuring out the scheme by looking at the gadget >> url etc. >> >> From a correctness point of view, there is nothing wrong in emitting uri's >> with scheme and schemeless uri's can be confusing. The tests written >> in StyleTagProxyEmbeddedUrlsVisitorTest >> just test what the proxyUriManager emits :) So if we finalize on getting >> rid >> of schemeless uris, please go ahead and modify the tests appropriately. All >> we care about is that proxying functionality is retained. >> >> And it so happens that schemeless uri's also work within css, just like >> they >> currently work with any other url generated by the page html. The browser >> uses the scheme of the html page the css is loaded in context of. Btw, what >> was the javascript use case you had in mind ? >> >> On Wed, Aug 11, 2010 at 2:52 PM, Christiaan Hees <[email protected]> >> wrote: >> >> > I think I found something related to this. >> > A post to metadata with something like: >> > >> > >> {"context":{"country":"US","language":"en","view":"default","container":"default"},"gadgets":[{"url":" >> > http://www.google.com/ig/modules/hello.xml","moduleId":1}]} >> > >> > returns an invalid iframeUrl: >> > iframeUrl: "// >> > >> > >> http://localhost:8080/gadgets/ifr?url=http%3A%2F%2Fwww.google.com%2Fig%2Fmodules%2Fhello.xml&container=default&view=%25view%25&lang=%25lang%25&country=%25country%25&debug=%25debug%25&nocache=%25nocache%25&v=8090dbad37029ea9eaa5e6c6d9cef98a >> > " >> > >> > You can see it on this page with firebug: >> > http://localhost:8080/container/sample-metadata.html >> > >> > >> Good find. It seems the problem arises from the following snippet in >> DefaultIframeUrimanager: >> >> // 2. Set host/authority. >> String host; >> if (usingLockedDomain(gadget, container)) { >> host = ldGen.getLockedDomainPrefix(gadget.getSpec().getUrl()) + >> getReqVal(container, LOCKED_DOMAIN_SUFFIX_KEY); >> } else { >> host = getReqVal(container, UNLOCKED_DOMAIN_KEY); >> } >> uri.setAuthority(host); >> >> What is happening is that we are setting the authority as " >> http://localhost:8080"; and scheme as null, whereas we should be setting >> authority as "localhost:8080". The following snippet in container.js >> explains why this happens: >> >> "defaultShindigTestHost": "http://${SERVER_HOST}:${SERVER_PORT}";, >> "gadgets.uri.iframe.unlockedDomain": "${Cur['defaultShindigTestHost']}", >> >> >> A small fix would be to do this: >> "defaultShindigTestAuthority": "${SERVER_HOST}:${SERVER_PORT}", >> "gadgets.uri.iframe.unlockedDomain": >> "${Cur['defaultShindigTestAuthority']}", >> >> >> On Tue, Aug 10, 2010 at 3:33 PM, Mat Mannion <[email protected] >> >wrote: >> > >> > > Yes, sorry - wrote the mail in a rush. It should be the same as the >> > iframe >> > > URL. >> > > >> > > On 10 August 2010 13:36, Paul Lindner <[email protected]> wrote: >> > > > actually to avoid mixed-content warnings you'll probably want to >> match >> > > the >> > > > scheme of the iframe URL. >> > > > >> > > > On Tue, Aug 10, 2010 at 5:29 AM, Mat Mannion < >> [email protected] >> > > >wrote: >> > > > >> > > >> Can we set the scheme to be the same as the gadget URL, rather than >> > > >> guessing at http? >> > > >> >> > > >> Mat >> > > >> >> > > >> On 10 August 2010 10:48, Paul Lindner <[email protected]> >> wrote: >> > > >> > I'm also seeing schemeless URIs leaking into the CSS rewriter >> > output. >> > > >> > Here's some output from samplecontainer: >> > > >> > >> > > >> > div.bubble { >> > > >> > >> > > >> > background-image: >> > > >> > >> > > >> >> > > >> > >> url('//localhost:8080/gadgets/proxy?container=default&gadget=http%3A%2F%2Flocalhost%3A8080%2Fsamplecontainer%2Fexamples%2FSocialHelloWorld.xml&debug=0&nocache=0&url=http%3A%2F%2Flocalhost%3A8080%2Fsamplecontainer%2Fexamples%2Fbubble.gif'); >> > > >> > >> > > >> > background-repeat: no-repeat; >> > > >> > >> > > >> > width: 202px; >> > > >> > >> > > >> > >> > > >> > What's confusing is that the tests as written >> > > >> > (StyleTagProxyEmbeddedUrlsVisitorTest) expect this broken output. >> > > >> > >> > > >> > I'm going to set the scheme to http for now, I'd like to know why >> > this >> > > is >> > > >> > the way it is. I can see schemeless URIs being useful in a >> > javascript >> > > >> > context, but I cannot fathom how they're supposed to work >> otherwise. >> > > >> > Gagan/John can you fill us in? >> > > >> > >> > > >> > On Thu, Aug 5, 2010 at 8:41 AM, Gagandeep singh < >> > [email protected] >> > > >> >wrote: >> > > >> > >> > > >> >> Hi Mat >> > > >> >> >> > > >> >> You could post a snippet of the html which has the scheme-less >> > link, >> > > the >> > > >> >> iframe you are talking about and the culprit <base tag> in gadget >> > > html. >> > > >> >> That >> > > >> >> should help dev@ community understand the problem better. >> > > >> >> Also, you might want to take a look at >> > > >> >> AbsolutePathReferenceRewriter< >> > > >> >> >> > > >> >> > > >> > >> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/rewrite/AbsolutePathReferenceVisitor.java >> > > >> >> >. >> > > >> >> It expands all the relative urls relative to the base tag >> provided >> > in >> > > >> the >> > > >> >> html. It doesnt have iframe-src for now, but i guess it can be >> > added >> > > and >> > > >> >> might solve the problem your seeing. >> > > >> >> >> > > >> >> On Thu, Aug 5, 2010 at 4:45 PM, Mat Mannion < >> > [email protected] >> > > > >> > > >> >> wrote: >> > > >> >> >> > > >> >> > Hi all, >> > > >> >> > >> > > >> >> > I understand the thinking behind scheme-less proxy/concat URIs, >> > but >> > > I >> > > >> >> > don't think they're working as intended. The problem is that >> the >> > > >> >> > intention is that they should be on the same scheme as the >> iframe >> > > >> >> > renderer, but we then insert a <base> tag with the gadget URI, >> > > which >> > > >> >> > means that the URIs for /proxy and /concat are actually on the >> > same >> > > >> >> > scheme as the gadget - this is causing issues for us as we >> don't >> > > run >> > > >> >> > the shindig server on HTTP at all. At least, this is the >> > behaviour >> > > I'm >> > > >> >> > seeing in Google Chrome. >> > > >> >> > >> > > >> >> > Could someone take a look at this and tell me if I'm right in >> my >> > > >> >> > deduction that this is what's causing the problem? >> > > >> >> > >> > > >> >> > Thanks in advance, >> > > >> >> > >> > > >> >> > Mat >> > > >> >> > >> > > >> >> > -- >> > > >> >> > Mat Mannion >> > > >> >> > Web Developer >> > > >> >> > IT Services >> > > >> >> > University of Warwick >> > > >> >> > Coventry >> > > >> >> > CV4 7AL >> > > >> >> > >> > > >> >> > Tel: 024 765 74433 >> > > >> >> > Email: [email protected] >> > > >> >> > >> > > >> >> >> > > >> > >> > > >> > >> > > >> > >> > > >> > -- >> > > >> > Paul Lindner -- [email protected] -- linkedin.com/in/plindner >> > > >> > >> > > >> >> > > >> >> > > >> >> > > >> -- >> > > >> Mat Mannion >> > > >> Web Developer >> > > >> IT Services >> > > >> University of Warwick >> > > >> Coventry >> > > >> CV4 7AL >> > > >> >> > > >> Tel: 024 765 74433 >> > > >> Email: [email protected] >> > > >> >> > > > >> > > > >> > > > >> > > > -- >> > > > Paul Lindner -- [email protected] -- linkedin.com/in/plindner >> > > > >> > > >> > > >> > > >> > > -- >> > > Mat Mannion >> > > Web Developer >> > > IT Services >> > > University of Warwick >> > > Coventry >> > > CV4 7AL >> > > >> > > Tel: 024 765 74433 >> > > Email: [email protected] >> > > >> > >> > -- Mat Mannion Web Developer IT Services University of Warwick Coventry CV4 7AL Tel: 024 765 74433 Email: [email protected]
