Any comments are appreciated whether they are drive-by or not :) In our use case the URLs are dynamically generated, but I can certainly imagine a use case where they are not. I would think we would need options for both types of resources. For the server side rewriter, we would need someway to tell the server which URLs to attach the token to, but that may just be a minor detail.
For option 3 are you talking about a feature param? Basically it would specify a host name to attach tokens to? -Ryan From: John Hjelmstad <[email protected]> To: [email protected], Date: 03/08/2012 01:51 PM Subject: Re: Accessing Protected Resources (ie images) Tricky situation, but not wholly uncommon. A few random thoughts: 1. Add an async gadgets.io.getProxyUrl() call. Painful, but would allow for a roundtrip to Shindig to pick up one or more signed URLs (or URLs w/ token attached). 2. Do the URLs *need* to be dynamically generated? If not, you can have a server-side rewriter take care of attaching a signature/token. 3. Add a <Param> directive requesting server injection of a map of signatures per-hostname. Let gadgets.io.getProxyUrl() attach signatures on a per-hostname basis. Total drive-by comment, apologies if the state of the art has progressed since I've last looked :) --j On Thu, Mar 8, 2012 at 8:57 AM, Ryan J Baxter <[email protected]> wrote: > We have run into a problem where we have images protected by OAuth that we > need to use in our gadgets. Usually a for an image would go through the > content proxy (gadgets.io.getProxyUrl), but the content proxy cannot do > the OAuth dance so we are kind of stuck. One solution would be to request > the the binary data for the image, base64 encode it, and put it in the > page that way, but there is a 32K limit on the size of the data URL for > image tags in IE8, which we have to support, and we are sure we will go > over that limit. Has anyone run into this problem? If so how have you > gotten around it? > > -Ryan >
