Hi Matt,
I couldn't wait for this to come around to the Shindig list, so I'll
respond here. :) If we can't find a simple answer here, we can cross-post.
As far as I know, Rave doesn't do any overriding of Shindig's locked domain
services.
Are you making use of a named container other than "default"? If so, the
log may be indicating that the default container still has %authority% in
its config.
Thanks,
-Stanton
On Wed, Apr 30, 2014 at 4:53 PM, Merrill, Matt <mmerrill@mitre.org> wrote:
> Hi all,
>
> I’m having an issue getting locked domains to work with Rave 0.23 and
> shindig 2.5.0-beta5. I have read the rave configuring locked domains page
> already (
> https://rave.apache.org/documentation/configure-locked-domain.html) and
> have used it as a basis for my setup.
>
> I am getting the following statement in the logs:
> level=WARN logger=org.apache.shindig.gadgets.HashLockedDomainService You
> should not be using %authority% replacement in a running environment!
> level=WARN logger=org.apache.shindig.gadgets.HashLockedDomainService Check
> your config and specify an explicit locked domain suffix.
> level=WARN logger=org.apache.shindig.gadgets.HashLockedDomainService Found
> suffix: %authority%
>
> No matter what I do for configuration in container.js, I’m getting this
> output. Before I emailed the Shindig list, I wanted to ask the Rave list
> about this since I know that Rave augments or overrides a lot of the
> shindig configuration. Is Rave doing anything to override shindig’s locked
> domain configuration? I couldn’t seem to find anything but wanted to check.
>
> Locked domains appear to be working correctly even with this log message
> spitting out, but the log message makes me wonder if my configuration is
> correct. I have searched in my codebase far and wide to see if
> “%authority%” is present anywhere and it is not. I’ve even looked at the
> default shindig container.js file to see where that string is specified and
> made sure that I’ve overridden those properties
> ("default.domain.locked.client", "default.domain.locked.server",
> "default.domain.unlocked.client",”default.domain.unlocked.server").
>
> I’m pasting relevant portions of the container.js configuration below
> (cleansed of real url’s). Does anyone have any idea why this might be
> being spit out?
>
> Thanks!
> -Matt
>
> Portion of container.js configuration:
> "gadgets.iframeBaseUri" : "/gmodules/gadgets/ifr",
> "gadgets.uri.iframe.basePath" : "/gmodules/gadgets/ifr",
>
> "gadgets.jsUriTemplate" : "http://
> ${Cur['gadgets.uri.iframe.unlockedDomain']}/gmodules/gadgets/js/%js%",
>
> "default.domain.locked.client" : "OBSCURED.com:9999",
> "default.domain.locked.server" : "OBSCURED.com:9999",
> "default.domain.unlocked.client" : "OBSCURED.com:9999",
> "default.domain.unlocked.server" : "OBSCURED.com:9999",
>
> "gadgets.uri.iframe.lockedDomainRequired" : true,
> "gadgets.uri.iframe.lockedDomainSuffix" : ".OBSCURED.com:9999",
> "gadgets.uri.iframe.unlockedDomain" : "OBSCURED.com:9999",
> "gadgets.uri.iframe.basePath" : "/gmodules/gadgets/ifr",
>
> "gadgets.uri.js.host" : "//${Cur['gadgets.uri.iframe.unlockedDomain']}",
> "gadgets.uri.js.path" : "/gmodules/gadgets/js",
> "gadgets.uri.oauth.callbackTemplate" :
> "//%host%/gmodules/gadgets/oauthcallback",
> "gadgets.osDataUri" : "http://%host%/gmodules/rpc",
>
> "gadgets.securityTokenType" : "secure",
> "gadgets.securityTokenKey" : "file:///OBSCURED.txt",
>
> "defaultShindigTestHost": "http://OBSCURED.com:9999",
>
> "defaultShindigProxyConcatAuthority": "OBSCURED.com:9999",
>
> "gadgets.uri.concat.host" : "${Cur['gadgets.uri.iframe.unlockedDomain']}",
> "gadgets.uri.concat.path" : "/gmodules/gadgets/concat",
> "gadgets.uri.concat.js.splitToken" : "false",
>
> "gadgets.uri.proxy.host" : "${Cur['gadgets.uri.iframe.unlockedDomain']}",
> "gadgets.uri.proxy.path" : "/gmodules/gadgets/proxy",
>
|