Hi John,

Regarding blank schemes, does that mean that in this particular case, the 
iframeurl returned in the metadata request would be schema-relative and it 
would be up to the container to add that information before rendering the 
iframeurl?

While I hate to suggest adding more to the container config, wouldn't a 
simple solution be to add the lockedDomain scheme to the container.js? 
That way the makeRenderingUri code can simple prepend it to the host 
before parsing.

Thanks,
-Stanton



From:   John Hjelmstad <[email protected]>
To:     [email protected], 
Cc:     Stanton Sievers/Westford/IBM@Lotus
Date:   04/01/2011 01:06
Subject:        Re: DefaultIframeUriManager for locked domains



Hi Stanton,

Sounds like we could use a little improvement to the logic. It does work 
for
us, and has for some time, but for better robustness it couldn't hurt to
make some edits.

Re: blank schema, that's for schema-relative URLs. Widely used in the 
code,
largely b/c we don't have a convenient way to inject the current protocol
being used.

-j

On Thu, Mar 31, 2011 at 7:09 PM, Stanton Sievers 
<[email protected]>wrote:

> I don't think the gadget url is null, rather, this test is overriding 
the
> LockedDomainPrefixGenerator to always produce "LOCKED".
>
> I find it interesting to see that these tests assert that the scheme is
> "".  Why is that?  Shouldn't the renderingUri returned by 
makeRenderingUri
> have a scheme, as it does in the non-locked domain case.
>
> These tests would also hit the exception if the locked domain suffix 
were
> set to have a port number.  A simple way to reproduce the issue I'm 
seeing
> is set LD_SUFFIX in DefaultIframeUriManagerTest to be
> ".lockeddomain.com:8080".
>
> Best regards,
> -Stanton
>
>
>
> From:   Ryan J Baxter/Westford/IBM@Lotus
> To:     [email protected],
> Cc:     Ziv Horesh <[email protected]>
> Date:   03/31/2011 21:48
> Subject:        Re: DefaultIframeUriManager for locked domains
>
>
>
> So I just ran the unit tests in DefaultIframeUriManagerTest,java and 
this
> code does get hit.  ldAddedForcedAlways seems to touch that code.  This
> test produces LOCKED.lockeddomain.com as a domain and Uri.parse does not
> blow up on that.  However I did notice that the gadget url in the test 
is
> null, so I am not sure if this test is valid since you can't create a 
hash
>
> of that.  Stanton, we probably want to take a deeper look at this test.
>
> -Ryan
>
> Email: [email protected]
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From:   John Hjelmstad <[email protected]>
> To:     [email protected],
> Cc:     Ziv Horesh <[email protected]>
> Date:   03/31/2011 09:06 PM
> Subject:        Re: DefaultIframeUriManager for locked domains
>
>
>
> Not when we run tests in Shindig... unless somehow that code path is 
never
> hit.
>
> On Thu, Mar 31, 2011 at 5:42 PM, Ziv Horesh <[email protected]> wrote:
>
> > On Thu, Mar 31, 2011 at 4:18 PM, John Hjelmstad <[email protected]>
> wrote:
> >
> > > Hi Stanton,
> > >
> > > Odd, this has worked for us for quite some time. Uri.parse(...) just
> > > doesn't
> > > throw a UriException. Are you overriding UriParser?
> > >
> > But we are overriding the parser...
> >
> >
> > >
> > > On Thu, Mar 31, 2011 at 2:57 PM, Stanton Sievers 
<[email protected]
> > > >wrote:
> > >
> > > > Hi,
> > > >
> > > > Has anyone been able to use the DefaultIframeUriManager when 
locked
> > > > domains are configured?  I've configured
> > > > gadgets.uri.iframe.lockedDomainSuffix in my container.js and have
> set
> > > > shindig.locked-domain.enabled=true in shindig.properties.  I seem 
to
>
> be
> > > > hitting the correct code paths, but I think the logic in
> > > > DefaultIframeUriManager.makeRenderingUri() is incorrect.
> > > >
> > > > In the case where locked domains are enabled we do a string
> > concatenation
> > > > of the generated locked domain prefix and the configured
> > > > gadgets.uri.iframe.lockedDomainSuffix in order to build the host
> name.
> > > The
> > > > problem is that immediately after that we try to do Uri.parse() on
> the
> > > > host name which is throwing a UriException because we don't have a
> > > > protocol/schema for the url, i.e., the url is just <gadget url
> > > > hash>.mydomain.com instead of http://<gadget url 
hash>.mydomain.com.
> > > >
> > > > Does this just not work for the DefaultIframeUriManager and those
> who
> > > want
> > > > locked domains need to bind to their own UriModule?
> > > >
> > > > Thanks,
> > > > -Stanton
> > > >
> > > >
> > >
> >
>
>
>
>
>
>
>



Reply via email to