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 <[email protected]> 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", >
