Re: Terminate the Apache Shindig Project

[Davies,Douglas]

Super big frowny face.

> On Oct 7, 2015, at 2:31 PM, Ryan Baxter  wrote:
> 
> Hi fellow Shindig Devs,
> 
> I would like to let you all know that the Shindig PMC has voted to
> terminate the Shindig project and move it to the attic.  I have already
> informed the Apache board about the termination in this months board report
> (below).
> 
> As most of you have probably noticed we have seen a decline in
> participation in all aspects of the project over the past months and the
> downward trend has been happening for over a year now.  This can certainly
> be seen in our reports to the board [1].
> 
> If anyone has any questions please let me know, and I will be sure to keep
> everyone up to date as we transition the project to the attic.  Thanks.
> 
> -Ryan
> 
> [1] https://cwiki.apache.org/confluence/display/SHINDIG/Board+Reports
> 
> -- Forwarded message -
> From: Ryan Baxter 
> Date: Mon, Oct 5, 2015 at 9:29 PM
> Subject: Terminate the Apache Shindig Project
> To: bo...@apache.org 
> Cc: priv...@shindig.apache.org 
> 
> 
> WHEREAS, the Project Management Committee of the Apache DirectMemory
> project has chosen by vote to recommend moving the project to the
> Attic; and
> 
> WHEREAS, the Board of Directors deems it no longer in the best
> interest of the Foundation to continue the Apache Shindig project
> due to inactivity;
> 
> NOW, THEREFORE, BE IT RESOLVED, that the Apache Shindig
> project is hereby terminated; and be it further
> 
> RESOLVED, that the Attic PMC be and hereby is tasked with
> oversight over the software developed by the Apache Shindig
> Project; and be it further
> 
> RESOLVED, that the office of "Vice President, Apache Shindig" is
> hereby terminated; and be it further
> 
> RESOLVED, that the Apache Shindig PMC is hereby terminated.

appId vs appUrl

[Davies,Douglas]

I’m trying to figure out why BlobCrypterSecurityToken uses the appUrl in the 
getter for appId.  It looks like I’ve had this discussion before

http://markmail.org/message/v2csm3vrxoddeztg

I don't even remember going down this path 4 years ago… but now it’s causing me 
issues because with the module_id stuff enabled I now get the #module_id=xxx 
hash added to the end of the url which screws up the way I was storing my 
gadgets (they are stored with the non-hashed url and an appId number generated 
by the database).

Has anyone dealt with this and worked out a solution?  This wasn’t an issue 
until the module_id stuff.  Right now I’ve had to intercept my queries at the 
jpa layer to strip off the hash portion, but not an elegant solution.

Thanks,
Doug Davies

Re: missing osapi endpoints

[Davies,Douglas]

I guess this old thread

http://markmail.org/message/n7t2xicqvwu2sfio

alludes to my same issue.

doug

On Jun 2, 2015, at 10:28 AM, Davies,Douglas  wrote:

> I do see this in the logs
> 
> INFO: 
> https://myserver/opensocial/rpc?method=system.listMethods&st=oclc:LXcpXCAPLyrVfHlxPmnSKYEU59aEt45_3VZPKNuPdSwMGnYaNSLikIGUaET_SEaVN70w-W7jQybrDLUoopvyxVbq8cs
>  has timed out because of the following exception: 
> org.apache.shindig.gadgets.http.BasicHttpFetcher - connect timed out - 30,012 
> ms.
> Jun 02, 2015 9:05:04 AM 
> org.apache.shindig.gadgets.render.DefaultServiceFetcher retrieveServices
> SEVERE: An HTTP 504 error occurred when fetching service methods from the 
> https://myserver/opensocial/rpc endpoint.
> 
> Interesting that the server tries to fetch the endpoints by calling through 
> the rpc endpoint on the target server, rather than just internally 
> introspecting?  I guess I could just define the osapi.servcies to prevent the 
> rpc call by removing the osapi.endPoints configuration.
> 
> doug
> 
> On Jun 2, 2015, at 9:50 AM, Davies,Douglas 
> mailto:davi...@oclc.org>> wrote:
> 
> Has anyone ever seen the osapi endpoints missing from the request for the 
> shindig js?  I occasionally get back javascript that is missing the endpoints 
> and all my osapi calls fail (undefined).  For example here is a good response
> 
> "osapi.services":{"gadgets.rpc":["container.listMethods"],"//%host%/opensocial/rpc":"spaces.update
>  spaces.delete albums.create http.head gadgets.token 
> activitystreams.supportedFields messages.modify userprefs.create 
> activities.create permissions.hasPermission containersecuritytoken.refresh 
> userprefs.get applications.get http.get spaces.supportedFields 
> mediaItems.delete spaces.get people.get gadgets.supportedFields 
> gadgets.cajaSupportedFields mediaItems.update http.put appdata.create 
> activitystreams.delete http.delete cache.invalidate albums.delete 
> userprefs.delete applications.create messages.delete appdata.update 
> people.update activities.supportedFields applications.update http.post 
> albums.get gadgets.cajole gadgets.proxySupportedFields applications.delete 
> people.supportedFields gadgets.metadata albums.supportedFields albums.update 
> spaces.create activities.delete mediaItems.get groups.get 
> applications.supportedFields mediaItems.supportedFields gadgets.proxy 
> activities.update gadgetContext.get activitystreams.create 
> activitystreams.get messages.get activitystreams.update mediaItems.create 
> messages.create gadgets.jsSupportedFields gadgets.tokenSupportedFields 
> activities.get gadgets.js appdata.get appdata.delete userprefs.update 
> system.listMethods".split(" “)}
> 
> and a bad one
> 
> "osapi.services":{"gadgets.rpc":["container.listMethods”]}
> 
> It seems to be a timing issue and MAY have been introduced when I started 
> using updateContainerSecurityToken refreshing (but I can’t say that for sure 
> — I only started seeing this when I implemented the refresh logic).
> 
> Ideas what to look for?
> 
> doug
> 

Re: missing osapi endpoints

[Davies,Douglas]

I do see this in the logs

INFO: 
https://myserver/opensocial/rpc?method=system.listMethods&st=oclc:LXcpXCAPLyrVfHlxPmnSKYEU59aEt45_3VZPKNuPdSwMGnYaNSLikIGUaET_SEaVN70w-W7jQybrDLUoopvyxVbq8cs
 has timed out because of the following exception: 
org.apache.shindig.gadgets.http.BasicHttpFetcher - connect timed out - 30,012 
ms.
Jun 02, 2015 9:05:04 AM org.apache.shindig.gadgets.render.DefaultServiceFetcher 
retrieveServices
SEVERE: An HTTP 504 error occurred when fetching service methods from the 
https://myserver/opensocial/rpc endpoint.

Interesting that the server tries to fetch the endpoints by calling through the 
rpc endpoint on the target server, rather than just internally introspecting?  
I guess I could just define the osapi.servcies to prevent the rpc call by 
removing the osapi.endPoints configuration.

doug

On Jun 2, 2015, at 9:50 AM, Davies,Douglas 
mailto:davi...@oclc.org>> wrote:

Has anyone ever seen the osapi endpoints missing from the request for the 
shindig js?  I occasionally get back javascript that is missing the endpoints 
and all my osapi calls fail (undefined).  For example here is a good response

"osapi.services":{"gadgets.rpc":["container.listMethods"],"//%host%/opensocial/rpc":"spaces.update
 spaces.delete albums.create http.head gadgets.token 
activitystreams.supportedFields messages.modify userprefs.create 
activities.create permissions.hasPermission containersecuritytoken.refresh 
userprefs.get applications.get http.get spaces.supportedFields 
mediaItems.delete spaces.get people.get gadgets.supportedFields 
gadgets.cajaSupportedFields mediaItems.update http.put appdata.create 
activitystreams.delete http.delete cache.invalidate albums.delete 
userprefs.delete applications.create messages.delete appdata.update 
people.update activities.supportedFields applications.update http.post 
albums.get gadgets.cajole gadgets.proxySupportedFields applications.delete 
people.supportedFields gadgets.metadata albums.supportedFields albums.update 
spaces.create activities.delete mediaItems.get groups.get 
applications.supportedFields mediaItems.supportedFields gadgets.proxy 
activities.update gadgetContext.get activitystreams.create activitystreams.get 
messages.get activitystreams.update mediaItems.create messages.create 
gadgets.jsSupportedFields gadgets.tokenSupportedFields activities.get 
gadgets.js appdata.get appdata.delete userprefs.update 
system.listMethods".split(" “)}

and a bad one

"osapi.services":{"gadgets.rpc":["container.listMethods”]}

It seems to be a timing issue and MAY have been introduced when I started using 
updateContainerSecurityToken refreshing (but I can’t say that for sure — I only 
started seeing this when I implemented the refresh logic).

Ideas what to look for?

doug

missing osapi endpoints

[Davies,Douglas]

Has anyone ever seen the osapi endpoints missing from the request for the 
shindig js?  I occasionally get back javascript that is missing the endpoints 
and all my osapi calls fail (undefined).  For example here is a good response

"osapi.services":{"gadgets.rpc":["container.listMethods"],"//%host%/opensocial/rpc":"spaces.update
 spaces.delete albums.create http.head gadgets.token 
activitystreams.supportedFields messages.modify userprefs.create 
activities.create permissions.hasPermission containersecuritytoken.refresh 
userprefs.get applications.get http.get spaces.supportedFields 
mediaItems.delete spaces.get people.get gadgets.supportedFields 
gadgets.cajaSupportedFields mediaItems.update http.put appdata.create 
activitystreams.delete http.delete cache.invalidate albums.delete 
userprefs.delete applications.create messages.delete appdata.update 
people.update activities.supportedFields applications.update http.post 
albums.get gadgets.cajole gadgets.proxySupportedFields applications.delete 
people.supportedFields gadgets.metadata albums.supportedFields albums.update 
spaces.create activities.delete mediaItems.get groups.get 
applications.supportedFields mediaItems.supportedFields gadgets.proxy 
activities.update gadgetContext.get activitystreams.create activitystreams.get 
messages.get activitystreams.update mediaItems.create messages.create 
gadgets.jsSupportedFields gadgets.tokenSupportedFields activities.get 
gadgets.js appdata.get appdata.delete userprefs.update 
system.listMethods".split(" “)}

and a bad one

"osapi.services":{"gadgets.rpc":["container.listMethods”]}

It seems to be a timing issue and MAY have been introduced when I started using 
updateContainerSecurityToken refreshing (but I can’t say that for sure — I only 
started seeing this when I implemented the refresh logic).

Ideas what to look for?

doug

Re: implementing container token refresh

[Davies,Douglas]

Perhaps I can inject a AuthenticationHandler that allows certain endpoint to be 
bypassed by generating an anonymous security token.

doug

On May 13, 2015, at 9:05 AM, Davies,Douglas 
mailto:davi...@oclc.org>> wrote:

(I’m not sure this ever posted yesterday… so pardon me if it comes through 
twice)

I’m looking into implementing container token refresh using the 
container.config_[osapi.container.ContainerConfig.GET_CONTAINER_TOKEN] 
mechanism.  This function would then either call back to my application or to 
shindig to fetch a new token.  Ideally I want to have the first 
updateContainerSecurityToken call start the refresh process.  However if I do 
that and I want to go with the approach of having shindig provide the endpoint 
for generating the token (by adding an osapi rpc service) then I’d already need 
a valid token to make the call to shindig.  If I provide the endpoint in my own 
application then I have to work out my own security scheme.  And I still have 
concerns with the token being exposed via network traffic or introspection on 
the javascript.  I guess that’s why they are short-lived.  Has anyone else 
implemented a server-side solution?  How did you handle securing the call (if 
at all)?  Any suggestions welcome.

UPDATE: It would be nice is there was someway to set allowUnauthenticated on a 
per method basis.  I know even our listMethods call requires a token (which 
would be nice if it didn’t).

Thanks,
doug

implementing container token refresh

[Davies,Douglas]

(I’m not sure this ever posted yesterday… so pardon me if it comes through 
twice)

I’m looking into implementing container token refresh using the 
container.config_[osapi.container.ContainerConfig.GET_CONTAINER_TOKEN] 
mechanism.  This function would then either call back to my application or to 
shindig to fetch a new token.  Ideally I want to have the first 
updateContainerSecurityToken call start the refresh process.  However if I do 
that and I want to go with the approach of having shindig provide the endpoint 
for generating the token (by adding an osapi rpc service) then I’d already need 
a valid token to make the call to shindig.  If I provide the endpoint in my own 
application then I have to work out my own security scheme.  And I still have 
concerns with the token being exposed via network traffic or introspection on 
the javascript.  I guess that’s why they are short-lived.  Has anyone else 
implemented a server-side solution?  How did you handle securing the call (if 
at all)?  Any suggestions welcome.

UPDATE: It would be nice is there was someway to set allowUnauthenticated on a 
per method basis.  I know even our listMethods call requires a token (which 
would be nice if it didn’t).

Thanks,
doug

implementing container token refresh

[Davies,Douglas]

I’m looking into implementing container token refresh using the 
container.config_[osapi.container.ContainerConfig.GET_CONTAINER_TOKEN] 
mechanism.  This function would then either call back to my application or to 
shindig to fetch a new token.  Ideally I want to have the first 
updateContainerSecurityToken call start the refresh process.  However if I do 
that and I want to go with the approach of having shindig provide the endpoint 
for generating the token (by adding an osapi rpc service) then I’d already need 
a valid token to make the call to shindig.  If I provide the endpoint in my own 
application then I have to work out my own security scheme.  And I still have 
concerns with the token being exposed via network traffic or introspection on 
the javascript.  I guess that’s why they are short-lived.  Has anyone else 
implemented a server-side solution?  How did you handle securing the call (if 
at all)?  Any suggestions welcome.

Thanks,
doug

Re: getActiveSiteHolder

[Davies,Douglas]

I have submitted bug 

https://issues.apache.org/jira/browse/SHINDIG-1994

and a proposed fix in review 

https://reviews.apache.org/r/33940

The issue has to do with the new module id stuff and the callback in 
gadget_site:navigateTo being called before the setModuleId_ method competes.  I 
restructured the code to have the broken path not call the callback until the 
setModuleId completes.

I guess I’ll have to patch this locally for now, since I’ve implemented the 
module_id stuff in our code.  I doubt there will be a shindig 2.5.3 release 
anytime soon.

doug

Re: getActiveSiteHolder

[Davies,Douglas]

Ok, I figured it out.  It has to do with the MODULE_ID renderParam, which is 
why I didn’t see this issue until I implemented module_id stuff.

If I do the following:

var renderParams = {};
renderParams[osapi.container.RenderParam.MODULE_ID] = 1;
container.navigateGadget(gadgetSite, gadgetXml, {}, renderParams, function(){
// log active site immediately (undefined)
console.log("activeSiteHolder1=" + gadgetSite.getActiveSiteHolder());
// log active site 1 second later (now has a value)
setTimeout(function() {
console.log("activeSiteHolder2=" + gadgetSite.getActiveSiteHolder());
}, 1000);
});

activeSiteHolder is undefined on the first getter (even though I’m in the 
callback function).  If I removed the 2nd line and not set the MODULE_ID render 
param then it works.  I’ll see if I can dig into why.

doug

On May 6, 2015, at 9:36 AM, Davies,Douglas 
mailto:davi...@oclc.org>> wrote:

Stanton,

I could have sworn that’s what my code was doing originally (the callback).  
But I just tried it in the sample I sent and it’s working.  Thanks!  I’ll let 
ya know if I experience any further problems with it.

doug

On May 5, 2015, at 8:35 PM, Stanton Sievers 
mailto:ssiev...@apache.org>> wrote:

Hi Doug,

If you want to get a handle to the sites and holders you should be doing so
in the optional callback to navigateGadget.  See the method signature [1]
for more information.  You can also hook the lifecycle callbacks [2] and
listen for ON_NAVIGATED [3] and you'll be given the site after the gadget
has rendered.

I hope that helps!

-Stanton

[1]
https://github.com/apache/shindig/blob/trunk/features/src/main/javascript/features/container/container.js#L192
[2]
https://github.com/apache/shindig/blob/trunk/features/src/main/javascript/features/container/container.js#L275
[3]
https://github.com/apache/shindig/blob/trunk/features/src/main/javascript/features/container.util/constant.js#L170

On Tue, May 5, 2015 at 9:29 AM, Davies,Douglas  wrote:

Hi Stanton,

Thanks for the feedback.

Here’s a working (or non-working) example of the problem.  Just drop this
in your common container directory along-side index.html.





  function init() {
  var gadgetXml = '
<a  rel="nofollow" href="https://dl.dropboxusercontent.com/u/445894/gadgets/settitle.xml">https://dl.dropboxusercontent.com/u/445894/gadgets/settitle.xml</a>';
  var container = new osapi.container.Container({});
  var gadgetSite = container.newGadgetSite(
document.getElementById('1') );
  container.navigateGadget(gadgetSite, gadgetXml, [], {});
  // log active site immediately (undefined)
  console.log("activeSiteHolder1=" +
gadgetSite.getActiveSiteHolder());
  // log active site 1 second later (now has a value)
  setTimeout(function() {
  console.log("activeSiteHolder2=" +
gadgetSite.getActiveSiteHolder());
  }, 1000);
  }


and the output

"activeSiteHolder1=undefined"
"activeSiteHolder2=[object Object]"

Occasionally even activeSiteHolder2 will still be undefined.  A refresh
usually causes it to have a value.  activeSiteHolder1 always appears to be
undefined.  This occasionally bites us with our chrome not rendering
(chrome not shown here) because it’s dependent on finding the gadget
element.

Should I reopen or create a new jira?  I can try to look into why it’s
doing this.  Any suggestions are welcome.  I tried to wait for the onRender
lifecycle callback, and even that didn’t work.

Also (Ryan included), about my earlier question about updating the wiki
with my module_id discoveries… how is that commonly done.  Funneled through
someone?

Thanks,
doug

On May 1, 2015, at 9:28 AM, Stanton Sievers > wrote:

This seems vaguely familiar but I can't pinpoint a JIRA ticket for the
exact issue.  I did find [1] which I encountered a year ago or so.

What version of Shindig are you using?  At what point in the gadget
lifecycle are you trying to get the active holder?

[1] https://issues.apache.org/jira/browse/SHINDIG-1965

On Wed, Apr 29, 2015 at 11:39 AM, Davies,Douglas > wrote:

Has anyone had any inconsistencies with gadgetSite.getActiveSiteHolder()
not being initialized immediately after container.navigateGadget?  I use
this to add chrome to my gadget.  Sometimes this fails because the active
site holder isn’t set yet.  If I delay for a second (or add an alert) then
it’s set.  I even tried adding an onRender lifecycle callback, with the
same result (I figured if I was getting the callback rendering should be
done).  It appears that it’s either suppose to return loadingGadgetHolder
or currentGadgetHolder.

Ideas?

doug

Re: getActiveSiteHolder

[Davies,Douglas]

Stanton,

I could have sworn that’s what my code was doing originally (the callback).  
But I just tried it in the sample I sent and it’s working.  Thanks!  I’ll let 
ya know if I experience any further problems with it.

doug

On May 5, 2015, at 8:35 PM, Stanton Sievers  wrote:

> Hi Doug,
> 
> If you want to get a handle to the sites and holders you should be doing so
> in the optional callback to navigateGadget.  See the method signature [1]
> for more information.  You can also hook the lifecycle callbacks [2] and
> listen for ON_NAVIGATED [3] and you'll be given the site after the gadget
> has rendered.
> 
> I hope that helps!
> 
> -Stanton
> 
> [1]
> https://github.com/apache/shindig/blob/trunk/features/src/main/javascript/features/container/container.js#L192
> [2]
> https://github.com/apache/shindig/blob/trunk/features/src/main/javascript/features/container/container.js#L275
> [3]
> https://github.com/apache/shindig/blob/trunk/features/src/main/javascript/features/container.util/constant.js#L170
> 
> On Tue, May 5, 2015 at 9:29 AM, Davies,Douglas  wrote:
> 
>> Hi Stanton,
>> 
>> Thanks for the feedback.
>> 
>> Here’s a working (or non-working) example of the problem.  Just drop this
>> in your common container directory along-side index.html.
>> 
>> 
>> 
>> > src="../../../gadgets/js/container.js?c=1&debug=1&container=default">
>> 
>>function init() {
>>var gadgetXml = '
>> <a  rel="nofollow" href="https://dl.dropboxusercontent.com/u/445894/gadgets/settitle.xml">https://dl.dropboxusercontent.com/u/445894/gadgets/settitle.xml</a>';
>>var container = new osapi.container.Container({});
>>var gadgetSite = container.newGadgetSite(
>> document.getElementById('1') );
>>container.navigateGadget(gadgetSite, gadgetXml, [], {});
>>// log active site immediately (undefined)
>>console.log("activeSiteHolder1=" +
>> gadgetSite.getActiveSiteHolder());
>>// log active site 1 second later (now has a value)
>>setTimeout(function() {
>>console.log("activeSiteHolder2=" +
>> gadgetSite.getActiveSiteHolder());
>>}, 1000);
>>}
>> 
>> 
>> and the output
>> 
>> "activeSiteHolder1=undefined"
>> "activeSiteHolder2=[object Object]"
>> 
>> Occasionally even activeSiteHolder2 will still be undefined.  A refresh
>> usually causes it to have a value.  activeSiteHolder1 always appears to be
>> undefined.  This occasionally bites us with our chrome not rendering
>> (chrome not shown here) because it’s dependent on finding the gadget
>> element.
>> 
>> Should I reopen or create a new jira?  I can try to look into why it’s
>> doing this.  Any suggestions are welcome.  I tried to wait for the onRender
>> lifecycle callback, and even that didn’t work.
>> 
>> Also (Ryan included), about my earlier question about updating the wiki
>> with my module_id discoveries… how is that commonly done.  Funneled through
>> someone?
>> 
>> Thanks,
>> doug
>> 
>> On May 1, 2015, at 9:28 AM, Stanton Sievers > ssiev...@apache.org>> wrote:
>> 
>> This seems vaguely familiar but I can't pinpoint a JIRA ticket for the
>> exact issue.  I did find [1] which I encountered a year ago or so.
>> 
>> What version of Shindig are you using?  At what point in the gadget
>> lifecycle are you trying to get the active holder?
>> 
>> [1] https://issues.apache.org/jira/browse/SHINDIG-1965
>> 
>> On Wed, Apr 29, 2015 at 11:39 AM, Davies,Douglas > davi...@oclc.org>> wrote:
>> 
>> Has anyone had any inconsistencies with gadgetSite.getActiveSiteHolder()
>> not being initialized immediately after container.navigateGadget?  I use
>> this to add chrome to my gadget.  Sometimes this fails because the active
>> site holder isn’t set yet.  If I delay for a second (or add an alert) then
>> it’s set.  I even tried adding an onRender lifecycle callback, with the
>> same result (I figured if I was getting the callback rendering should be
>> done).  It appears that it’s either suppose to return loadingGadgetHolder
>> or currentGadgetHolder.
>> 
>> Ideas?
>> 
>> doug
>> 
>> 
>> 
>> 
>> 

Re: getActiveSiteHolder

[Davies,Douglas]

Where ever adding some documentation about module_id would be useful.

https://cwiki.apache.org/confluence/display/SHINDIG/Common+Container ?

I see discussions about Dan Dumont writing up some documentation for his 
changes, but I don’t see where that was ever done.

Thanks,
doug

On May 5, 2015, at 9:41 AM, Ryan Baxter 
mailto:rbaxte...@apache.org>> wrote:

On Tue, May 5, 2015 at 2:29 PM, Davies,Douglas 
mailto:davi...@oclc.org>> wrote:

Hi Stanton,

Thanks for the feedback.

Here’s a working (or non-working) example of the problem.  Just drop this
in your common container directory along-side index.html.





   function init() {
   var gadgetXml = '
<a  rel="nofollow" href="https://dl.dropboxusercontent.com/u/445894/gadgets/settitle.xml">https://dl.dropboxusercontent.com/u/445894/gadgets/settitle.xml</a>';
   var container = new osapi.container.Container({});
   var gadgetSite = container.newGadgetSite(
document.getElementById('1') );
   container.navigateGadget(gadgetSite, gadgetXml, [], {});
   // log active site immediately (undefined)
   console.log("activeSiteHolder1=" +
gadgetSite.getActiveSiteHolder());
   // log active site 1 second later (now has a value)
   setTimeout(function() {
   console.log("activeSiteHolder2=" +
gadgetSite.getActiveSiteHolder());
   }, 1000);
   }


and the output

"activeSiteHolder1=undefined"
"activeSiteHolder2=[object Object]"

Occasionally even activeSiteHolder2 will still be undefined.  A refresh
usually causes it to have a value.  activeSiteHolder1 always appears to be
undefined.  This occasionally bites us with our chrome not rendering
(chrome not shown here) because it’s dependent on finding the gadget
element.

Should I reopen or create a new jira?  I can try to look into why it’s
doing this.  Any suggestions are welcome.  I tried to wait for the onRender
lifecycle callback, and even that didn’t work.

Also (Ryan included), about my earlier question about updating the wiki
with my module_id discoveries… how is that commonly done.  Funneled through
someone?

Which page do you want to update?


Thanks,
doug

On May 1, 2015, at 9:28 AM, Stanton Sievers 
mailto:ssiev...@apache.org>mailto:ssiev...@apache.org>>> wrote:

This seems vaguely familiar but I can't pinpoint a JIRA ticket for the
exact issue.  I did find [1] which I encountered a year ago or so.

What version of Shindig are you using?  At what point in the gadget
lifecycle are you trying to get the active holder?

[1] https://issues.apache.org/jira/browse/SHINDIG-1965

On Wed, Apr 29, 2015 at 11:39 AM, Davies,Douglas 
mailto:davi...@oclc.org>mailto:davi...@oclc.org>>> wrote:

Has anyone had any inconsistencies with gadgetSite.getActiveSiteHolder()
not being initialized immediately after container.navigateGadget?  I use
this to add chrome to my gadget.  Sometimes this fails because the active
site holder isn’t set yet.  If I delay for a second (or add an alert) then
it’s set.  I even tried adding an onRender lifecycle callback, with the
same result (I figured if I was getting the callback rendering should be
done).  It appears that it’s either suppose to return loadingGadgetHolder
or currentGadgetHolder.

Ideas?

doug

Re: getActiveSiteHolder

[Davies,Douglas]

Hi Stanton,

Thanks for the feedback.

Here’s a working (or non-working) example of the problem.  Just drop this in 
your common container directory along-side index.html.





function init() {
var gadgetXml = 
'<a  rel="nofollow" href="https://dl.dropboxusercontent.com/u/445894/gadgets/settitle.xml">https://dl.dropboxusercontent.com/u/445894/gadgets/settitle.xml</a>';
var container = new osapi.container.Container({});
var gadgetSite = container.newGadgetSite( document.getElementById('1') 
);
container.navigateGadget(gadgetSite, gadgetXml, [], {});
// log active site immediately (undefined)
console.log("activeSiteHolder1=" + gadgetSite.getActiveSiteHolder());
// log active site 1 second later (now has a value)
setTimeout(function() {
console.log("activeSiteHolder2=" + 
gadgetSite.getActiveSiteHolder());
}, 1000);
}


and the output

"activeSiteHolder1=undefined"
"activeSiteHolder2=[object Object]"

Occasionally even activeSiteHolder2 will still be undefined.  A refresh usually 
causes it to have a value.  activeSiteHolder1 always appears to be undefined.  
This occasionally bites us with our chrome not rendering (chrome not shown 
here) because it’s dependent on finding the gadget element.

Should I reopen or create a new jira?  I can try to look into why it’s doing 
this.  Any suggestions are welcome.  I tried to wait for the onRender lifecycle 
callback, and even that didn’t work.

Also (Ryan included), about my earlier question about updating the wiki with my 
module_id discoveries… how is that commonly done.  Funneled through someone?

Thanks,
doug

On May 1, 2015, at 9:28 AM, Stanton Sievers 
mailto:ssiev...@apache.org>> wrote:

This seems vaguely familiar but I can't pinpoint a JIRA ticket for the
exact issue.  I did find [1] which I encountered a year ago or so.

What version of Shindig are you using?  At what point in the gadget
lifecycle are you trying to get the active holder?

[1] https://issues.apache.org/jira/browse/SHINDIG-1965

On Wed, Apr 29, 2015 at 11:39 AM, Davies,Douglas 
mailto:davi...@oclc.org>> wrote:

Has anyone had any inconsistencies with gadgetSite.getActiveSiteHolder()
not being initialized immediately after container.navigateGadget?  I use
this to add chrome to my gadget.  Sometimes this fails because the active
site holder isn’t set yet.  If I delay for a second (or add an alert) then
it’s set.  I even tried adding an onRender lifecycle callback, with the
same result (I figured if I was getting the callback rendering should be
done).  It appears that it’s either suppose to return loadingGadgetHolder
or currentGadgetHolder.

Ideas?

doug

getActiveSiteHolder

[Davies,Douglas]

Has anyone had any inconsistencies with gadgetSite.getActiveSiteHolder() not 
being initialized immediately after container.navigateGadget?  I use this to 
add chrome to my gadget.  Sometimes this fails because the active site holder 
isn’t set yet.  If I delay for a second (or add an alert) then it’s set.  I 
even tried adding an onRender lifecycle callback, with the same result (I 
figured if I was getting the callback rendering should be done).  It appears 
that it’s either suppose to return loadingGadgetHolder or currentGadgetHolder.

Ideas?

doug

Re: appId, moduleId, siteId

[Davies,Douglas]

Ugh… so this is all starting to ring a bell from a discussion I had years ago

https://mail-archives.apache.org/mod_mbox/shindig-dev/201112.mbox/%3cof8eaceec4.629d7942-on8525796f.005711e2-8525796f.00572...@notesdev.ibm.com%3E

and

https://issues.apache.org/jira/browse/SHINDIG-1557

In that bug I suggested that the calls to userPrefs were being made on behalf 
of the container, in other words the container security token was being used.  
This might be working as designed, but it means on the service side I can't 
just do token.getModuleId().  Instead I always need to pass along the extra 
piece of information to the service.

Dan Dumont suggested…

I think we would certainly want to make sure that all container-proxied 
requests ferry along the moduleId. I'll keep that in mind as I make these 
changes.  Thank you for pointing it out.

I don’t think those were changes that were ever made.  That’s fine, I can just 
switch my userPrefs to key off of moduleId (instead of siteId) and just pass it 
along, but I was hoping to not even have to do that since the gadget security 
token has the moduleId embedded appropriately.

At least I’ve wrapped my head around the moduleId stuff.  Not sure if it buys 
me anything at this point however.

Hmph!

doug

On Apr 27, 2015, at 12:47 PM, Davies,Douglas 
mailto:davi...@oclc.org>> wrote:

Doh!  I just realized that the validate method has to return the same value.  I 
changed it and I’m now getting back the moduleId in the json response.  Sweet!

So to summarize…

If I set RenderParam.MODULE_ID to -1 it causes the back-end to generate an id 
using ModuleIdManager (generate and validate).  This comes back in the json 
response to the “gadget.token” rpc call.  Thereafter, if I call 
gadgetSite.getModuleId() I get back the generated id.

Now if I set RenderParam.MODULE_ID to 1234 and I don’t provide my own 
ModuleIdManager, it will return a moduleId of 0.  If I instead implement the 
validate method (the generate does not get called in this scenario) to return 
the moduleId passed in then the module id is set correctly and I can use 
gadgetSite.getModuleId() as well.

I hope that helps someone else in the future.  Is there somewhere I could 
document this?  Not sure where the correct wiki is anymore and whether this 
falls under common container info or what.

Thanks!

doug

On Apr 27, 2015, at 11:35 AM, Davies,Douglas 
mailto:davi...@oclc.org>> wrote:

If I set renderParams[osapi.container.RenderParam.MODULE_ID] = -1

per http://comments.gmane.org/gmane.comp.web.shindig.devel/8498

* You can now request that a new moduleId be generated for a gadget when asking 
for a new token by setting it's
moduleId to a negative number and fetching a new token.  The response will come 
back with a moduleId you can
save for persistence.  There is a corresponding new class in Java to override 
if you plan on persisting
moduleIds.  It has 2 methods: validate and generate which are used to verify 
the validity of a moduleId,
viewerId, gadgetUrl combination or to generate (and persist) a new moduleId for 
that combination.

I now see the “generate” method of ModuleIdManager get called.  I have it 
returning 1234L.  However, the response still has moduleId set to 0.

[{"method":"gadgets.token","id":"gadgets.token","params":{"container":"sandbox","ids":["https://dl.dropboxusercontent.com/u/445894/gadgets/userprefs-consistency.xml#moduleId=-1"],"fields":["token","tokenTTL","moduleId"],"userId":"@viewer","groupId":"@self"}}]

[{"result":{"https://dl.dropboxusercontent.com/u/445894/gadgets/userprefs-consistency.xml#moduleId=-1":{"moduleId":0,"responseTimeMs":1430148807688,"tokenTTL":3600,"token":"sandbox:hdaOrK8oPiHzbXbZqWfCReLpNJ2rgioN3pIXAX33ChO9r6rxBgB9DOHkp02PzPD7xOIwYD5MpEDB0DFjVceBq-VRnFm2xCDpIbft5CpbF8r1nQP5VLRoxf4bbsxFG13vEso2adn9eBGg516thh7MtHa-i5Om-fxkH8ycXCLsFeZPqqIS1vEgLahykYYcoaGrbwxZfNDtGfLl9pH9bXIqpjkAArpWyiABVz_5C-6AE2I0xoc8LJIjZylSDrrqxN9GQUbp5gGa3yny5Qu5GG2GqSQeSrUaTm2tjQc3n15mlSUjBjt_LqjZ8_laeChEfVJOO2FurZO1uWOXoKzB4LIQZyZTDhoQ8Vxzsa0KZpT4JmdRRmKlMh7IiJAZmc9WTVEBHffJ_KYl3pHT11JmOjvbDS9t8rltEyDtxf4TOnmLFDosIdJcNTAiBv8nv5l6sm2o7CJRRGhQvhqStNUYVS0etReoCw9T8hTVZSKeAC5F1-Ew7qOjghLK3SsLPxXJZSRVnZ3xsolOQ9CAiRe852KhhpkBsvlCpW82r4N-wresRASzMOgM"}},"id":"gadgets.token”}]

doug

Re: appId, moduleId, siteId

[Davies,Douglas]

Doh!  I just realized that the validate method has to return the same value.  I 
changed it and I’m now getting back the moduleId in the json response.  Sweet!

So to summarize…

If I set RenderParam.MODULE_ID to -1 it causes the back-end to generate an id 
using ModuleIdManager (generate and validate).  This comes back in the json 
response to the “gadget.token” rpc call.  Thereafter, if I call 
gadgetSite.getModuleId() I get back the generated id.

Now if I set RenderParam.MODULE_ID to 1234 and I don’t provide my own 
ModuleIdManager, it will return a moduleId of 0.  If I instead implement the 
validate method (the generate does not get called in this scenario) to return 
the moduleId passed in then the module id is set correctly and I can use 
gadgetSite.getModuleId() as well.

I hope that helps someone else in the future.  Is there somewhere I could 
document this?  Not sure where the correct wiki is anymore and whether this 
falls under common container info or what.

Thanks!

doug

On Apr 27, 2015, at 11:35 AM, Davies,Douglas  wrote:

> If I set renderParams[osapi.container.RenderParam.MODULE_ID] = -1
> 
> per http://comments.gmane.org/gmane.comp.web.shindig.devel/8498
> 
> * You can now request that a new moduleId be generated for a gadget when 
> asking for a new token by setting it's
> moduleId to a negative number and fetching a new token.  The response will 
> come back with a moduleId you can
> save for persistence.  There is a corresponding new class in Java to override 
> if you plan on persisting
> moduleIds.  It has 2 methods: validate and generate which are used to verify 
> the validity of a moduleId,
> viewerId, gadgetUrl combination or to generate (and persist) a new moduleId 
> for that combination.
> 
> I now see the “generate” method of ModuleIdManager get called.  I have it 
> returning 1234L.  However, the response still has moduleId set to 0.
> 
> [{"method":"gadgets.token","id":"gadgets.token","params":{"container":"sandbox","ids":["https://dl.dropboxusercontent.com/u/445894/gadgets/userprefs-consistency.xml#moduleId=-1"],"fields":["token","tokenTTL","moduleId"],"userId":"@viewer","groupId":"@self"}}]
> 
> [{"result":{"https://dl.dropboxusercontent.com/u/445894/gadgets/userprefs-consistency.xml#moduleId=-1":{"moduleId":0,"responseTimeMs":1430148807688,"tokenTTL":3600,"token":"sandbox:hdaOrK8oPiHzbXbZqWfCReLpNJ2rgioN3pIXAX33ChO9r6rxBgB9DOHkp02PzPD7xOIwYD5MpEDB0DFjVceBq-VRnFm2xCDpIbft5CpbF8r1nQP5VLRoxf4bbsxFG13vEso2adn9eBGg516thh7MtHa-i5Om-fxkH8ycXCLsFeZPqqIS1vEgLahykYYcoaGrbwxZfNDtGfLl9pH9bXIqpjkAArpWyiABVz_5C-6AE2I0xoc8LJIjZylSDrrqxN9GQUbp5gGa3yny5Qu5GG2GqSQeSrUaTm2tjQc3n15mlSUjBjt_LqjZ8_laeChEfVJOO2FurZO1uWOXoKzB4LIQZyZTDhoQ8Vxzsa0KZpT4JmdRRmKlMh7IiJAZmc9WTVEBHffJ_KYl3pHT11JmOjvbDS9t8rltEyDtxf4TOnmLFDosIdJcNTAiBv8nv5l6sm2o7CJRRGhQvhqStNUYVS0etReoCw9T8hTVZSKeAC5F1-Ew7qOjghLK3SsLPxXJZSRVnZ3xsolOQ9CAiRe852KhhpkBsvlCpW82r4N-wresRASzMOgM"}},"id":"gadgets.token”}]
> 
> doug

Re: appId, moduleId, siteId

[Davies,Douglas]

If I set renderParams[osapi.container.RenderParam.MODULE_ID] = -1

per http://comments.gmane.org/gmane.comp.web.shindig.devel/8498

* You can now request that a new moduleId be generated for a gadget when asking 
for a new token by setting it's
moduleId to a negative number and fetching a new token.  The response will come 
back with a moduleId you can
save for persistence.  There is a corresponding new class in Java to override 
if you plan on persisting
moduleIds.  It has 2 methods: validate and generate which are used to verify 
the validity of a moduleId,
viewerId, gadgetUrl combination or to generate (and persist) a new moduleId for 
that combination.

I now see the “generate” method of ModuleIdManager get called.  I have it 
returning 1234L.  However, the response still has moduleId set to 0.

[{"method":"gadgets.token","id":"gadgets.token","params":{"container":"sandbox","ids":["https://dl.dropboxusercontent.com/u/445894/gadgets/userprefs-consistency.xml#moduleId=-1"],"fields":["token","tokenTTL","moduleId"],"userId":"@viewer","groupId":"@self"}}]

[{"result":{"https://dl.dropboxusercontent.com/u/445894/gadgets/userprefs-consistency.xml#moduleId=-1":{"moduleId":0,"responseTimeMs":1430148807688,"tokenTTL":3600,"token":"sandbox:hdaOrK8oPiHzbXbZqWfCReLpNJ2rgioN3pIXAX33ChO9r6rxBgB9DOHkp02PzPD7xOIwYD5MpEDB0DFjVceBq-VRnFm2xCDpIbft5CpbF8r1nQP5VLRoxf4bbsxFG13vEso2adn9eBGg516thh7MtHa-i5Om-fxkH8ycXCLsFeZPqqIS1vEgLahykYYcoaGrbwxZfNDtGfLl9pH9bXIqpjkAArpWyiABVz_5C-6AE2I0xoc8LJIjZylSDrrqxN9GQUbp5gGa3yny5Qu5GG2GqSQeSrUaTm2tjQc3n15mlSUjBjt_LqjZ8_laeChEfVJOO2FurZO1uWOXoKzB4LIQZyZTDhoQ8Vxzsa0KZpT4JmdRRmKlMh7IiJAZmc9WTVEBHffJ_KYl3pHT11JmOjvbDS9t8rltEyDtxf4TOnmLFDosIdJcNTAiBv8nv5l6sm2o7CJRRGhQvhqStNUYVS0etReoCw9T8hTVZSKeAC5F1-Ew7qOjghLK3SsLPxXJZSRVnZ3xsolOQ9CAiRe852KhhpkBsvlCpW82r4N-wresRASzMOgM"}},"id":"gadgets.token”}]

doug

Re: appId, moduleId, siteId

[Davies,Douglas]

We are on the latest (2.5.2).

On Apr 27, 2015, at 11:10 AM, Martin Hoeller 
mailto:mar...@xss.co.at>> wrote:

Hi!

Are you using a recent version of shindig?
There was a bug that got fixed about 2 years ago:
https://issues.apache.org/jira/browse/SHINDIG-1891

hth,
- martin


Am Mon, 27 Apr 2015 13:30:47 + schrieb "Davies,Douglas" 
mailto:davi...@oclc.org>>:

Stanton,

Thanks for the rundown on the different ids and what they are.
That’s helpful (and along the same lines as the conclusion I came to).

So I tried changing ModuleIdManagerImpl to return 1234L.  However
when I do the following in the gadget

alert(gadgets.Prefs().getModuleId());

I still see 0.  I set a breakpoint and I do NOT see the generate
method get called.

I also tried doing the following in my js container.

renderParams[osapi.container.RenderParam.MODULE_ID] = 1234;

I do see an rpc request as follows:

[{"method":"gadgets.token","id":"gadgets.token","params":{"container":"sandbox","ids":["https://dl.dropboxusercontent.com/u/445894/gadgets/userprefs-consistency.xml#moduleId=1234"],"fields":["token","tokenTTL","moduleId"],"userId":"@viewer","groupId":"@self"}}]

with a response of

[{
   "result": {
   
"https://dl.dropboxusercontent.com/u/445894/gadgets/userprefs-consistency.xml#moduleId=1234":
{ "moduleId": 0,
   "token":
"sandbox:zHzRL-vIuzoZ_84zMMigXr87NIBfvDijZdW-eF8cXSsAbIzCwWeLtr8I6tP0zrBL_iFcYO3c4AQwdZTUE_Bnvc5mB4i-PQ5QvUI-Z_SfWU7hBmIKEGNSJ1JznG8NWX_jdfGfkRe3hfjGlwOimVhcuynZheLfEHzssTL3WwWHa0xxmzmmlwbGkYwlClbKG5QLli4X8Tw4llnepPjYKwL7xu1pVWyF2VlSTaU-z1OZLQQ7fuHQszzTwUW77G2vDnSX49xIoCXmud52am10xEU_zpmbjDMb3AQ6trCkcEcwnGiurZExfiyMPa97VKlnXKiB2vC_0B22mbu9_moCU-vfFaNYcHXBKXlO6nsmV8SOSFOGi9l_9aQTX5YOaox0TJ4QU3vJYaarooQVwy2BWchS9qE216metnRvKHtFZ4pSuEw_aAdda8rlQ8LBkMLroqQaozJzi3OLdZ6y0SI3HRwSjAlZ77epTSk7b3m0_GmWIP7j4Qth-jcuVjgf_Gbs8tY3E6HFlGBsUzXcgLxLIKqNYZk_41XTErzYGtOxSMXJl_3mFALX",
"responseTimeMs": 1430141170844, "tokenTTL": 3600
   }
   },
   "id": "gadgets.token"
}
]

I see the #moduleId of 1234 tacked onto the gadget spec url, however
it appears the moduleId comes back as 0 in the response.

I must be missing something here.

Again, it feels like I should be using moduleId in userPrefs instead
of siteId, since it’s baked into the security token and it can’t be
spoofed easily and isn’t exposed as a parameter.

I’ll keep playing around with this, but thanks for the
clarifications.  Did you and Ryan ever implement this in the
container you were working on?

Thanks,
doug

On Apr 25, 2015, at 9:01 AM, Stanton Sievers
mailto:ssiev...@apache.org><mailto:ssiev...@apache.org>> 
wrote:

Hi Doug,

You may have already gotten to the bottom of this but I'll provide a
quick rundown here anyway.

siteId: Client-side ID that is generated to help manage communication
between the container and the gadget sites for services like actions,
selection, and more

appId: An id that is unique to the application, i.e. gadget, being
rendered.  AppId in the case of gadgets is generally just the URL to
the gadget XML.  Thus, this ID is the same across all instances of a
given gadget and is for storing data like app data.

moduleId: An id that is unique to the instance of a gadget.  If
multiple instances of the same gadget are rendering on the page, they
should have unique module ids.  The server is also aware of module
ids, as you saw with ModuleIdManager, and is the one responsible for
generating them.  They are included in security tokens to
differentiate between separate instances of a gadget. The module id
for a gadget instance should be the same across page reloads.  A
gadget preferences implementation would use the module id to store
instance-specific information.


Shindig's default implementation of moduleId is naive (it's always
0!) but a ModuleIdManager implementation can be injected that handles
them more intelligently.

I hope that helps!

On Fri, Apr 24, 2015 at 4:10 PM, Davies,Douglas
mailto:davi...@oclc.org><mailto:davi...@oclc.org>> wrote:

I think I just had an ah ha moment.  I realized the ModuleIdManager is
concerned about persistence.  I’m not sure that’s what I need here.  I
think the piece I was missing it RenderParam.MODULE_ID on the
container side.  I’m gonna play with this and I’ll be back if I have
more questions.

Thanks,
doug


On Apr 24, 2015, at 2:15 PM, Davies,Douglas
mailto:davi...@oclc.org><mailto:davi...@oclc.org>> wrote:

Ok, I think I’ve figured this out (at least our use-case).

We are using the siteId all over the place in the container and having
to pass it along to the userPrefs calls.  I’m guessing I shouldn’t be
doing this and allowed the moduleId bake into the sec

Re: appId, moduleId, siteId

[Davies,Douglas]

Stanton,

Thanks for the rundown on the different ids and what they are.  That’s helpful 
(and along the same lines as the conclusion I came to).

So I tried changing ModuleIdManagerImpl to return 1234L.  However when I do the 
following in the gadget

alert(gadgets.Prefs().getModuleId());

I still see 0.  I set a breakpoint and I do NOT see the generate method get 
called.

I also tried doing the following in my js container.

renderParams[osapi.container.RenderParam.MODULE_ID] = 1234;

I do see an rpc request as follows:

[{"method":"gadgets.token","id":"gadgets.token","params":{"container":"sandbox","ids":["https://dl.dropboxusercontent.com/u/445894/gadgets/userprefs-consistency.xml#moduleId=1234"],"fields":["token","tokenTTL","moduleId"],"userId":"@viewer","groupId":"@self"}}]

with a response of

[{
"result": {

"https://dl.dropboxusercontent.com/u/445894/gadgets/userprefs-consistency.xml#moduleId=1234":
 {
"moduleId": 0,
"token": 
"sandbox:zHzRL-vIuzoZ_84zMMigXr87NIBfvDijZdW-eF8cXSsAbIzCwWeLtr8I6tP0zrBL_iFcYO3c4AQwdZTUE_Bnvc5mB4i-PQ5QvUI-Z_SfWU7hBmIKEGNSJ1JznG8NWX_jdfGfkRe3hfjGlwOimVhcuynZheLfEHzssTL3WwWHa0xxmzmmlwbGkYwlClbKG5QLli4X8Tw4llnepPjYKwL7xu1pVWyF2VlSTaU-z1OZLQQ7fuHQszzTwUW77G2vDnSX49xIoCXmud52am10xEU_zpmbjDMb3AQ6trCkcEcwnGiurZExfiyMPa97VKlnXKiB2vC_0B22mbu9_moCU-vfFaNYcHXBKXlO6nsmV8SOSFOGi9l_9aQTX5YOaox0TJ4QU3vJYaarooQVwy2BWchS9qE216metnRvKHtFZ4pSuEw_aAdda8rlQ8LBkMLroqQaozJzi3OLdZ6y0SI3HRwSjAlZ77epTSk7b3m0_GmWIP7j4Qth-jcuVjgf_Gbs8tY3E6HFlGBsUzXcgLxLIKqNYZk_41XTErzYGtOxSMXJl_3mFALX",
"responseTimeMs": 1430141170844,
"tokenTTL": 3600
}
},
"id": "gadgets.token"
}
]

I see the #moduleId of 1234 tacked onto the gadget spec url, however it appears 
the moduleId comes back as 0 in the response.

I must be missing something here.

Again, it feels like I should be using moduleId in userPrefs instead of siteId, 
since it’s baked into the security token and it can’t be spoofed easily and 
isn’t exposed as a parameter.

I’ll keep playing around with this, but thanks for the clarifications.  Did you 
and Ryan ever implement this in the container you were working on?

Thanks,
doug

On Apr 25, 2015, at 9:01 AM, Stanton Sievers 
mailto:ssiev...@apache.org>> wrote:

Hi Doug,

You may have already gotten to the bottom of this but I'll provide a quick
rundown here anyway.

siteId: Client-side ID that is generated to help manage communication
between the container and the gadget sites for services like actions,
selection, and more

appId: An id that is unique to the application, i.e. gadget, being
rendered.  AppId in the case of gadgets is generally just the URL to the
gadget XML.  Thus, this ID is the same across all instances of a given
gadget and is for storing data like app data.

moduleId: An id that is unique to the instance of a gadget.  If multiple
instances of the same gadget are rendering on the page, they should have
unique module ids.  The server is also aware of module ids, as you saw with
ModuleIdManager, and is the one responsible for generating them.  They are
included in security tokens to differentiate between separate instances of
a gadget. The module id for a gadget instance should be the same across
page reloads.  A gadget preferences implementation would use the module id
to store instance-specific information.


Shindig's default implementation of moduleId is naive (it's always 0!) but
a ModuleIdManager implementation can be injected that handles them more
intelligently.

I hope that helps!

On Fri, Apr 24, 2015 at 4:10 PM, Davies,Douglas 
mailto:davi...@oclc.org>> wrote:

I think I just had an ah ha moment.  I realized the ModuleIdManager is
concerned about persistence.  I’m not sure that’s what I need here.  I
think the piece I was missing it RenderParam.MODULE_ID on the container
side.  I’m gonna play with this and I’ll be back if I have more questions.

Thanks,
doug


On Apr 24, 2015, at 2:15 PM, Davies,Douglas 
mailto:davi...@oclc.org>> wrote:

Ok, I think I’ve figured this out (at least our use-case).

We are using the siteId all over the place in the container and having
to pass it along to the userPrefs calls.  I’m guessing I shouldn’t be doing
this and allowed the moduleId bake into the security token to be used
server-side to identify the gadget.

So… I implemented my own ModuleIdManager, however I noticed it NEVER
gets called.  I traced it back to getToken in GadgetsHandlerService, which
in turn is called by the token method over in GadgetsHandler.  It looks as
follows

@Operation(httpMethods = {"POST", "GET"}, path = "token")
public Map token(BaseRequestItem
request)
  throws Prot

Re: appId, moduleId, siteId

[Davies,Douglas]

I think I just had an ah ha moment.  I realized the ModuleIdManager is 
concerned about persistence.  I’m not sure that’s what I need here.  I think 
the piece I was missing it RenderParam.MODULE_ID on the container side.  I’m 
gonna play with this and I’ll be back if I have more questions.

Thanks,
doug


On Apr 24, 2015, at 2:15 PM, Davies,Douglas  wrote:

> Ok, I think I’ve figured this out (at least our use-case).
> 
> We are using the siteId all over the place in the container and having to 
> pass it along to the userPrefs calls.  I’m guessing I shouldn’t be doing this 
> and allowed the moduleId bake into the security token to be used server-side 
> to identify the gadget.
> 
> So… I implemented my own ModuleIdManager, however I noticed it NEVER gets 
> called.  I traced it back to getToken in GadgetsHandlerService, which in turn 
> is called by the token method over in GadgetsHandler.  It looks as follows
> 
> @Operation(httpMethods = {"POST", "GET"}, path = "token")
> public Map token(BaseRequestItem 
> request)
>throws ProtocolException {
>  return new AbstractExecutor() {
>@Override
>protected Callable createJob(String url, BaseRequestItem 
> request)
>throws ProcessingException {
>  return createTokenJob(url, request);
>}
>  }.execute(request);
> }
> 
> However I NEVER see this endpoint hit.  I see the metadata endpoint get 
> called.  Does the js container need to be doing something with the “token” 
> endpoint?  I don’t see it documented anywhere.  The common container that 
> comes with shindig doesn’t seem to call this endpoint either.
> 
> Thanks,
> doug
> 
> On Apr 22, 2015, at 12:49 PM, Davies,Douglas 
> mailto:davi...@oclc.org>> wrote:
> 
> I’ve been combing through past conversations and wikis, but I’ve yet to find 
> a good explanation of the difference between appId, moduleId, and siteId.  
> Does anyone know where I can find a good explanation of where I should be 
> using each one?  Right now I think the default ModuleIIdManager always 
> returns 0.  We are using siteId quite a bit in our container to indicate 
> which gadget is making requests.  I know the moduleId is baked into the 
> SecurityToken and it would be a better implementation.  Any guidance on this 
> would be appreciated.
> 
> Thanks,
> Doug
> 
> 
> 

Re: appId, moduleId, siteId

[Davies,Douglas]

Ok, I think I’ve figured this out (at least our use-case).

We are using the siteId all over the place in the container and having to pass 
it along to the userPrefs calls.  I’m guessing I shouldn’t be doing this and 
allowed the moduleId bake into the security token to be used server-side to 
identify the gadget.

So… I implemented my own ModuleIdManager, however I noticed it NEVER gets 
called.  I traced it back to getToken in GadgetsHandlerService, which in turn 
is called by the token method over in GadgetsHandler.  It looks as follows

@Operation(httpMethods = {"POST", "GET"}, path = "token")
public Map token(BaseRequestItem 
request)
throws ProtocolException {
  return new AbstractExecutor() {
@Override
protected Callable createJob(String url, BaseRequestItem 
request)
throws ProcessingException {
  return createTokenJob(url, request);
}
  }.execute(request);
}

However I NEVER see this endpoint hit.  I see the metadata endpoint get called. 
 Does the js container need to be doing something with the “token” endpoint?  I 
don’t see it documented anywhere.  The common container that comes with shindig 
doesn’t seem to call this endpoint either.

Thanks,
doug

On Apr 22, 2015, at 12:49 PM, Davies,Douglas 
mailto:davi...@oclc.org>> wrote:

I’ve been combing through past conversations and wikis, but I’ve yet to find a 
good explanation of the difference between appId, moduleId, and siteId.  Does 
anyone know where I can find a good explanation of where I should be using each 
one?  Right now I think the default ModuleIIdManager always returns 0.  We are 
using siteId quite a bit in our container to indicate which gadget is making 
requests.  I know the moduleId is baked into the SecurityToken and it would be 
a better implementation.  Any guidance on this would be appreciated.

Thanks,
Doug

appId, moduleId, siteId

[Davies,Douglas]

I’ve been combing through past conversations and wikis, but I’ve yet to find a 
good explanation of the difference between appId, moduleId, and siteId.  Does 
anyone know where I can find a good explanation of where I should be using each 
one?  Right now I think the default ModuleIIdManager always returns 0.  We are 
using siteId quite a bit in our container to indicate which gadget is making 
requests.  I know the moduleId is baked into the SecurityToken and it would be 
a better implementation.  Any guidance on this would be appreciated.

Thanks,
Doug

Re: container security tokens v.s. gadget security tokens

[Davies,Douglas]

Stanton,

Let me give that some thought today (wrap my head around the flow).

Looking through some archived messages I see a thread where it was discussed 
whether a gadget needed to do something to refresh an expired security token.  
It seems to me that is taken care of automatically and the only reason I’m 
having to refresh here is because I’ve changed the container context?

Thanks,
doug

On Apr 8, 2015, at 4:23 PM, Stanton Sievers  wrote:

> I'm not sure why non-callback approach would work any differently.  I'm
> wondering if you're getting into a situation where your container token is
> flagged as needing a refresh, because you explicitly provide a new token,
> but it's not expired.  Thus, your callback executes immediately, finishes,
> and then the rest of the updateContainerSecurityToken method executes.
> 
> That's probably why not providing a callback, or setting a timeout in your
> callback is working.  You're allowing updateContainerSecurityToken to
> finish and actually call shindig.auth.updateSecurityToken via the refresh
> method.
> 
> Hopefully that makes sense. :)
> 
> On Wed, Apr 8, 2015 at 2:20 PM, Davies,Douglas  wrote:
> 
>> I got it to work.  Not sure why I was using the callback flavor of
>> updateContainerSecurityToken.  If I change to this
>> 
>> container.updateContainerSecurityToken(null, token, 1800);
>> container.forceRefreshAllTokens();
>> 
>> it works fine.
>> 
>> doug
>> 
>> On Apr 8, 2015, at 2:15 PM, Davies,Douglas > davi...@oclc.org>> wrote:
>> 
>> It would appear that if I call container.forceRefreshAllTokens() as
>> follows, the gadget tokens are still the old ones
>> 
>> container.updateContainerSecurityToken(function() {
>>   container.forceRefreshAllTokens();
>> }, token, 1800);
>> 
>> if I put a delay, then it works
>> 
>> container.updateContainerSecurityToken(function() {
>>   setTimeout(function(){
>>   container.forceRefreshAllTokens();
>>   }, 2000);
>> }, token, 1800);
>> 
>> Looking at the updateContainerSecurityToken code in service.js it looks
>> like my flow would fall through the “Token no expired, but needs refresh.
>> Don’t block operations that need a valid token).  But as far as I can tell,
>> that immediately returns, but it’s cryptic after that.
>> 
>> osapi.container.Service.prototype.updateContainerSecurityToken =
>> function(callback, tokenOrWait, ttl) {
>>   var undef,
>>   now = osapi.container.util.getCurrentTimeMs(),
>>   token = typeof(tokenOrWait) != 'boolean' && tokenOrWait || undef,
>>   wait = typeof(tokenOrWait) == 'boolean' && tokenOrWait,
>>   needsRefresh = containerTokenTTL &&
>>   (fetching || token || !lastRefresh || now > lastRefresh +
>> containerTokenTTL);
>>   if (needsRefresh) {
>> // Hard expire in 95% of originial ttl.
>> var expired = !lastRefresh || now > lastRefresh + (containerTokenTTL
>> * 95 / 80);
>> if (!expired && callback) {
>>   // Token not expired, but needs refresh.  Don't block operations
>> that need a valid token.
>>   callback();
>> } else if (callback) {
>>   // We have a callback, there's either a fetch happening, or we
>> otherwise need to refresh the
>>   // token.  Place it in the callbacks queue to be run after the
>> fetch (currently running or
>>   // soon to be launched) completes.
>>   callbacks.push(callback);
>> }
>> 
>> if (token) {
>>   // We are trying to set a token initially.  Run refresh with a
>> fetch_once function that simply
>>   // returns the canned values.  Then schedule the refresh using the
>> function in the config
>>   refresh.call(this, function(result) {
>> result(token, ttl);
>>   });
>> } else if (!fetching && !wait) {
>>   // There's no fetch going on right now. Unless wait is true, we
>> need to start one right away
>>   // because the token needs a refresh.
>> 
>>   // If wait is true, the callback really just wants a valid token.
>> It may be called with an
>>   // error for informational purposes, but it's likely the callback
>> will simply queue up
>>   // immediately if there was an error.  To avoid spamming the
>> refresh method, we allow them to
>>   // specify `wait` so that it can wait for success without forcing a
>> fetch.
>>   refresh.call(this);
>> }
>>   } else if 

Re: container security tokens v.s. gadget security tokens

[Davies,Douglas]

I got it to work.  Not sure why I was using the callback flavor of 
updateContainerSecurityToken.  If I change to this

container.updateContainerSecurityToken(null, token, 1800);
container.forceRefreshAllTokens();

it works fine.

doug

On Apr 8, 2015, at 2:15 PM, Davies,Douglas 
mailto:davi...@oclc.org>> wrote:

It would appear that if I call container.forceRefreshAllTokens() as follows, 
the gadget tokens are still the old ones

container.updateContainerSecurityToken(function() {
   container.forceRefreshAllTokens();
}, token, 1800);

if I put a delay, then it works

container.updateContainerSecurityToken(function() {
   setTimeout(function(){
   container.forceRefreshAllTokens();
   }, 2000);
}, token, 1800);

Looking at the updateContainerSecurityToken code in service.js it looks like my 
flow would fall through the “Token no expired, but needs refresh. Don’t block 
operations that need a valid token).  But as far as I can tell, that 
immediately returns, but it’s cryptic after that.

osapi.container.Service.prototype.updateContainerSecurityToken = 
function(callback, tokenOrWait, ttl) {
   var undef,
   now = osapi.container.util.getCurrentTimeMs(),
   token = typeof(tokenOrWait) != 'boolean' && tokenOrWait || undef,
   wait = typeof(tokenOrWait) == 'boolean' && tokenOrWait,
   needsRefresh = containerTokenTTL &&
   (fetching || token || !lastRefresh || now > lastRefresh + 
containerTokenTTL);
   if (needsRefresh) {
 // Hard expire in 95% of originial ttl.
 var expired = !lastRefresh || now > lastRefresh + (containerTokenTTL * 95 
/ 80);
 if (!expired && callback) {
   // Token not expired, but needs refresh.  Don't block operations that 
need a valid token.
   callback();
 } else if (callback) {
   // We have a callback, there's either a fetch happening, or we otherwise 
need to refresh the
   // token.  Place it in the callbacks queue to be run after the fetch 
(currently running or
   // soon to be launched) completes.
   callbacks.push(callback);
 }

 if (token) {
   // We are trying to set a token initially.  Run refresh with a 
fetch_once function that simply
   // returns the canned values.  Then schedule the refresh using the 
function in the config
   refresh.call(this, function(result) {
 result(token, ttl);
   });
 } else if (!fetching && !wait) {
   // There's no fetch going on right now. Unless wait is true, we need to 
start one right away
   // because the token needs a refresh.

   // If wait is true, the callback really just wants a valid token. It may 
be called with an
   // error for informational purposes, but it's likely the callback will 
simply queue up
   // immediately if there was an error.  To avoid spamming the refresh 
method, we allow them to
   // specify `wait` so that it can wait for success without forcing a 
fetch.
   refresh.call(this);
 }
   } else if (callback) {
 // No refresh needed, run the callback because the token is fine.
 callback();
   }
 };
})();

doug


On Apr 8, 2015, at 1:55 PM, Davies,Douglas 
mailto:davi...@oclc.org><mailto:davi...@oclc.org>> wrote:

Thanks Stanton.  That’s what I am attempting to do, but it seems like I have to 
go through the whole process twice before it “sticks”.  I’m trying to determine 
if there is a timing issue here.  The code for the container refresh is really 
cryptic to read.  But it appears to me like it might return immediately and 
continue to refresh the token in the background.  Not sure.  I’ll keep ya 
posted.

doug

On Apr 8, 2015, at 1:44 PM, Stanton Sievers 
mailto:ssiev...@apache.org><mailto:ssiev...@apache.org>> 
wrote:

Hi Doug,

You should forceRefreshAllTokens.  Treat the gadget security tokens like
they are derived from the container security token (because they are).  The
gadget tokens in your case will have the old viewer id baked-in because
they were derived from the old container token which also had the old
viewer id baked-in.  Forcing the refresh will re-issue all of your gadget
tokens with the new viewer id.

I hope that helps!

-Stanton

On Wed, Apr 8, 2015 at 1:27 PM, Davies,Douglas 
mailto:davi...@oclc.org><mailto:davi...@oclc.org>> wrote:

I have a question about refreshing container and gadget security tokens.

When I call updateContainerSecurityToken on the container, do I then need
to call forceRefreshAllTokens for the gadgets?

I was looking at OpenSocial Explorer (http://opensocial.github.io/explorer
— Stanton and Ryan) and noticed it does something similar in it’s container

I have a container where I can dynamically change the Person for testing.
So I update the container token, but it seems like subsequent services
requests (for example people.get) continue to use a token for the previous
Person.

Ideas?  Hope this makes sense.

doug

Re: container security tokens v.s. gadget security tokens

[Davies,Douglas]

It would appear that if I call container.forceRefreshAllTokens() as follows, 
the gadget tokens are still the old ones

container.updateContainerSecurityToken(function() {
container.forceRefreshAllTokens();
}, token, 1800);

if I put a delay, then it works

container.updateContainerSecurityToken(function() {
setTimeout(function(){
container.forceRefreshAllTokens();
}, 2000);
}, token, 1800);

Looking at the updateContainerSecurityToken code in service.js it looks like my 
flow would fall through the “Token no expired, but needs refresh. Don’t block 
operations that need a valid token).  But as far as I can tell, that 
immediately returns, but it’s cryptic after that.

osapi.container.Service.prototype.updateContainerSecurityToken = 
function(callback, tokenOrWait, ttl) {
var undef,
now = osapi.container.util.getCurrentTimeMs(),
token = typeof(tokenOrWait) != 'boolean' && tokenOrWait || undef,
wait = typeof(tokenOrWait) == 'boolean' && tokenOrWait,
needsRefresh = containerTokenTTL &&
(fetching || token || !lastRefresh || now > lastRefresh + 
containerTokenTTL);
if (needsRefresh) {
  // Hard expire in 95% of originial ttl.
  var expired = !lastRefresh || now > lastRefresh + (containerTokenTTL * 95 
/ 80);
  if (!expired && callback) {
// Token not expired, but needs refresh.  Don't block operations that 
need a valid token.
callback();
  } else if (callback) {
// We have a callback, there's either a fetch happening, or we 
otherwise need to refresh the
// token.  Place it in the callbacks queue to be run after the fetch 
(currently running or
// soon to be launched) completes.
callbacks.push(callback);
  }

  if (token) {
// We are trying to set a token initially.  Run refresh with a 
fetch_once function that simply
// returns the canned values.  Then schedule the refresh using the 
function in the config
refresh.call(this, function(result) {
  result(token, ttl);
});
  } else if (!fetching && !wait) {
// There's no fetch going on right now. Unless wait is true, we need to 
start one right away
// because the token needs a refresh.

// If wait is true, the callback really just wants a valid token. It 
may be called with an
// error for informational purposes, but it's likely the callback will 
simply queue up
// immediately if there was an error.  To avoid spamming the refresh 
method, we allow them to
// specify `wait` so that it can wait for success without forcing a 
fetch.
refresh.call(this);
  }
} else if (callback) {
  // No refresh needed, run the callback because the token is fine.
  callback();
}
  };
})();

doug


On Apr 8, 2015, at 1:55 PM, Davies,Douglas 
mailto:davi...@oclc.org>> wrote:

Thanks Stanton.  That’s what I am attempting to do, but it seems like I have to 
go through the whole process twice before it “sticks”.  I’m trying to determine 
if there is a timing issue here.  The code for the container refresh is really 
cryptic to read.  But it appears to me like it might return immediately and 
continue to refresh the token in the background.  Not sure.  I’ll keep ya 
posted.

doug

On Apr 8, 2015, at 1:44 PM, Stanton Sievers 
mailto:ssiev...@apache.org>> wrote:

Hi Doug,

You should forceRefreshAllTokens.  Treat the gadget security tokens like
they are derived from the container security token (because they are).  The
gadget tokens in your case will have the old viewer id baked-in because
they were derived from the old container token which also had the old
viewer id baked-in.  Forcing the refresh will re-issue all of your gadget
tokens with the new viewer id.

I hope that helps!

-Stanton

On Wed, Apr 8, 2015 at 1:27 PM, Davies,Douglas 
mailto:davi...@oclc.org>> wrote:

I have a question about refreshing container and gadget security tokens.

When I call updateContainerSecurityToken on the container, do I then need
to call forceRefreshAllTokens for the gadgets?

I was looking at OpenSocial Explorer (http://opensocial.github.io/explorer
— Stanton and Ryan) and noticed it does something similar in it’s container

I have a container where I can dynamically change the Person for testing.
So I update the container token, but it seems like subsequent services
requests (for example people.get) continue to use a token for the previous
Person.

Ideas?  Hope this makes sense.

doug

Re: container security tokens v.s. gadget security tokens

[Davies,Douglas]

Thanks Stanton.  That’s what I am attempting to do, but it seems like I have to 
go through the whole process twice before it “sticks”.  I’m trying to determine 
if there is a timing issue here.  The code for the container refresh is really 
cryptic to read.  But it appears to me like it might return immediately and 
continue to refresh the token in the background.  Not sure.  I’ll keep ya 
posted.

doug

On Apr 8, 2015, at 1:44 PM, Stanton Sievers  wrote:

> Hi Doug,
> 
> You should forceRefreshAllTokens.  Treat the gadget security tokens like
> they are derived from the container security token (because they are).  The
> gadget tokens in your case will have the old viewer id baked-in because
> they were derived from the old container token which also had the old
> viewer id baked-in.  Forcing the refresh will re-issue all of your gadget
> tokens with the new viewer id.
> 
> I hope that helps!
> 
> -Stanton
> 
> On Wed, Apr 8, 2015 at 1:27 PM, Davies,Douglas  wrote:
> 
>> I have a question about refreshing container and gadget security tokens.
>> 
>> When I call updateContainerSecurityToken on the container, do I then need
>> to call forceRefreshAllTokens for the gadgets?
>> 
>> I was looking at OpenSocial Explorer (http://opensocial.github.io/explorer
>> — Stanton and Ryan) and noticed it does something similar in it’s container
>> 
>> I have a container where I can dynamically change the Person for testing.
>> So I update the container token, but it seems like subsequent services
>> requests (for example people.get) continue to use a token for the previous
>> Person.
>> 
>> Ideas?  Hope this makes sense.
>> 
>> doug
>> 
>> 
>> 
>> 

container security tokens v.s. gadget security tokens

[Davies,Douglas]

I have a question about refreshing container and gadget security tokens.

When I call updateContainerSecurityToken on the container, do I then need to 
call forceRefreshAllTokens for the gadgets?

I was looking at OpenSocial Explorer (http://opensocial.github.io/explorer — 
Stanton and Ryan) and noticed it does something similar in it’s container

I have a container where I can dynamically change the Person for testing.  So I 
update the container token, but it seems like subsequent services requests (for 
example people.get) continue to use a token for the previous Person.

Ideas?  Hope this makes sense.

doug

Re: EL expressions, Substituters, and Shindig

[Davies,Douglas]

Ok, it sounds like the right way to do this is with data-pipelining and 
templates.  I just had to create a new request handler.  For example

Re: EL expressions, Substituters, and Shindig

[Davies,Douglas]

Thanks.  It seems like Substituters worked on the entire gadget spec (replacing 
any __MODULE_xxx__, __UP_xxx__, etc.).  The templates stuff seems to only work 
in “text/os-data” nodes and no way to plug in your own template resolver.  My 
desire is to have something that more closely matched the opensocial 1.0 stuff, 
but using EL syntax.  But then I’m going way outside the opensocial spec if I 
do that.

Essentially what I’m really trying to do is provide a value that is necessary 
in making future service requests.  In our case it’s called a 
contextInstitutionId.  I initially tied this into the Person service, and the 
gadget writer could call that to get the value and append it to the service 
call request.  But it really seems like an environment type thing.  The context 
of where I am running.  So just looking for a way to provide this to the gadget 
developer.

doug

On Mar 27, 2015, at 4:09 PM, Ryan Baxter  wrote:

> Sorry Doug, I never really looked at this portion of Shindig.  Maybe
> someone else knows?
> 
> On Wed, Mar 25, 2015 at 4:18 PM, Davies,Douglas  wrote:
> 
>> Hi All,
>> 
>> I want to make a value available to my gadget via substitution of a
>> regular expression.  I know the old format was something like this
>> __MODULE_ID__.  I was able to get my own value working by writing my own
>> Substituter and injecting it.  So for example __MODULE_MY_KEY__ (I couldn’t
>> figure out how to get my own Type, so I first overloaded MODULE).  What I
>> really want is the EL opensocial 2.0 way of doing it ${Module.MyKey} or
>> preferably my own namespace ${Context.institutionId}.  It doesn’t look like
>> this is supported.  I can get it to work with UserPrefs just fine, but that
>> might be all that is supported.  Can anyone shed some light on this?
>> 
>> Thanks,
>> Doug Davies
>> 
>> 
>> 
>> 
>> 

EL expressions, Substituters, and Shindig

[Davies,Douglas]

Hi All,

I want to make a value available to my gadget via substitution of a regular 
expression.  I know the old format was something like this __MODULE_ID__.  I 
was able to get my own value working by writing my own Substituter and 
injecting it.  So for example __MODULE_MY_KEY__ (I couldn’t figure out how to 
get my own Type, so I first overloaded MODULE).  What I really want is the EL 
opensocial 2.0 way of doing it ${Module.MyKey} or preferably my own namespace 
${Context.institutionId}.  It doesn’t look like this is supported.  I can get 
it to work with UserPrefs just fine, but that might be all that is supported.  
Can anyone shed some light on this?

Thanks,
Doug Davies

not getting messages

[Davies,Douglas]

I haven’t gotten any messages from this listserv since 1/14.  Looking at 
markmail is see there are a few from 1/29.  Is anyone aware of any issue?  
Also, I’m a bit concerned about the lack of traffic.  Has the move to w3c 
changed things?  I guess I’m asking because my company is thinking of 
abandoning opensocial stating that it’s not an active community anymore.

Thanks,
Doug Davies

repo down

[Davies,Douglas]

Is http://svn.apache.org/repos/asf/shindig/trunk/ down?  It appears maybe all 
apache repos are down.

doug

renderDebug

[Davies,Douglas]

Hi guys.  While working up a solution for SHINDIG-1984 I noticed that in 
commoncontainer that renderDebug is set as follows

   testConfig[osapi.container.ContainerConfig.RENDER_DEBUG] = '0';

and then in container.js it does this

  this.renderDebug_ = (typeof param === 'undefined') ?
  Boolean(osapi.container.util.getSafeJsonValue(config,
  osapi.container.ContainerConfig.RENDER_DEBUG, false)) :
  (param === '1');

which sets this.renderDebug_ to TRUE (incorrectly).  I think the creation of 
the Boolean is only caring that the string has a value and setting to TRUE.

Is this a container/documentation error and we should fix the containers OR 
should the container.js code be able to handle the string?  I can submit a bug 
once we decide the correct approach.  For now I am changing my container to set 
RENDER_DEBUG to 0 (no quotes) so that I can continue working up a patch for 
SHINDIG-1984 (which relies on turning off renderDebug so that caching is 
enabled and I can reproduce my scenario).

Thanks,
Doug Davies

Re: [VOTE] Release Apache Shindig version 2.5.2

[Davies,Douglas]

I imagine everyone is gone on vacation, but if there is any chance of getting a 
2.5.2 release before the holidays I'd appreciate it.  Otherwise, see ya when 
you get back.

doug

On Nov 23, 2014, at 7:42 PM, Paul Lindner  wrote:

> +1 - ship it
> 
> On Mon Nov 10 2014 at 5:41:48 PM Ryan Baxter  wrote:
> 
>> Hi,
>> 
>> We solved 6 issues:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SHINDIG%20AND%
>> 20fixVersion%20%3D%202.5.2%20AND%20status%20%3D%20Resolved%20ORDER%20BY%
>> 20priority%20DESC
>> 
>> There are still a couple of issues left in JIRA:
>> https://issues.apache.org/jira/secure/IssueNavigator.
>> jspa?reset=true&pid=12310741&status=1
>> 
>> Staging repo:
>> https://repository.apache.org/content/repositories/orgapacheshindig-1001/
>> 
>> Web site:
>> http://shindig.apache.org/
>> 
>> Vote open for 72 hours.
>> 
>> [ ] +1
>> [ ] +0
>> [ ] -1
>> 

Re: [VOTE] Release Apache Shindig version 2.5.2

[Davies,Douglas]

Correct.

On Nov 19, 2014, at 3:10 PM, Ryan Baxter  wrote:

> Doug, I assume this is a dependency in your own implementation?
> 

Re: [VOTE] Release Apache Shindig version 2.5.2

[Davies,Douglas]

I found an issue with the updated guava version conflicting with our bonecp 
version, but I've fixed it in our end.  So still a +1 and looking forward to 
the release.

doug

On Nov 15, 2014, at 10:55 AM, Ryan Baxter  wrote:

> +1 from me.
> 
> I one other PMC member could check the release than we can publish it.
> 
> On Thu, Nov 13, 2014 at 8:53 AM, Stanton Sievers  wrote:
>> +1
>> 
>> Signatures and hashes look good.  Smoketest of the sample common container
>> looks good.
>> 
>> On Mon, Nov 10, 2014 at 8:41 PM, Ryan Baxter  wrote:
>> 
>>> Hi,
>>> 
>>> We solved 6 issues:
>>> 
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SHINDIG%20AND%20fixVersion%20%3D%202.5.2%20AND%20status%20%3D%20Resolved%20ORDER%20BY%20priority%20DESC
>>> 
>>> There are still a couple of issues left in JIRA:
>>> 
>>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310741&status=1
>>> 
>>> Staging repo:
>>> https://repository.apache.org/content/repositories/orgapacheshindig-1001/
>>> 
>>> Web site:
>>> http://shindig.apache.org/
>>> 
>>> Vote open for 72 hours.
>>> 
>>> [ ] +1
>>> [ ] +0
>>> [ ] -1
>>> 

Re: [VOTE] Release Apache Shindig version 2.5.2

[Davies,Douglas]

+1

On Nov 10, 2014, at 8:41 PM, Ryan Baxter  wrote:

> Hi,
> 
> We solved 6 issues:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SHINDIG%20AND%20fixVersion%20%3D%202.5.2%20AND%20status%20%3D%20Resolved%20ORDER%20BY%20priority%20DESC
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310741&status=1
> 
> Staging repo:
> https://repository.apache.org/content/repositories/orgapacheshindig-1001/
> 
> Web site:
> http://shindig.apache.org/
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1

Re: 2.5.2 release?

[Davies,Douglas]

Thanks Ryan!

On Nov 10, 2014, at 9:43 AM, Ryan Baxter  wrote:

> I have no problem doing a release whenever.  The problem is always
> trying to find some time to do them ;)  I will try to kick one off
> this week.
> 
> On Sat, Nov 8, 2014 at 12:26 PM, Stanton Sievers  wrote:
>> Hi Doug,
>> 
>> There's no set time frame on the 2.5.2 release.  If we think there are
>> enough fixed items to warrant a release then it's worth discussing.  As you
>> mentioned, there are 6 items fixed in 2.5.2 right now [1].
>> 
>> Personally, I think the mindset should be if we are in doubt whether or not
>> it's time to cut a release then cut a release.  It doesn't hurt to get
>> fixes out there, IMO.
>> 
>> What does everyone else think?
>> 
>> Thanks,
>> -Stanton
>> 
>> [1]
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SHINDIG%20AND%20fixVersion%20%3D%202.5.2%20AND%20status%20%3D%20Resolved%20ORDER%20BY%20priority%20DESC
>> 
>> On Fri, Nov 7, 2014 at 9:26 AM, Davies,Douglas  wrote:
>> 
>>> It's been about 8 months since the last release.  I see there are only
>>> about 6 out of the 25 tickets that have been resolved for 2.5.2.  What is
>>> the roadmap for releasing 2.5.2?  Is it determined by timeframe or bugs
>>> fixed?  I have a patch I contributed that we'd really like to get into our
>>> project, but I don't want to cause anyone unnecessary time to do a build if
>>> it's not time.
>>> 
>>> Thanks,
>>> Doug
>>> 

2.5.2 release?

[Davies,Douglas]

It's been about 8 months since the last release.  I see there are only about 6 
out of the 25 tickets that have been resolved for 2.5.2.  What is the roadmap 
for releasing 2.5.2?  Is it determined by timeframe or bugs fixed?  I have a 
patch I contributed that we'd really like to get into our project, but I don't 
want to cause anyone unnecessary time to do a build if it's not time.

Thanks,
Doug

Re: Shindig Logo Design - Please Vote for your Choice

[Davies,Douglas]

Wow, these are really great.  I vote for 09.

doug

Re: Review Request 25650: The NO_CACHE RenderParam does not appear to affect makeRequest

[Davies,Douglas]

Has anyone had a chance to look at this?  Just getting a feel as to if everyone 
thinks this is an acceptable fix.

doug

On Sep 15, 2014, at 3:19 PM, Doug Davies 
mailto:davi...@oclc.org>> wrote:

This is an automatically generated e-mail. To reply, visit: 
https://reviews.apache.org/r/25650/

Review request for shindig and Ryan Baxter.
By Doug Davies.

Updated Sept. 15, 2014, 7:19 p.m.

Changes

fixed unit tests and made nocache undefined if never defined in render or 
request params


Bugs: SHINDIG-1983
Repository: shindig
Description

The NO_CACHE RenderParam does not appear to affect makeRequest. This fix adds a 
NO_CACHE request param and if that's not defined then it tries to use the 
NO_CACHE render param and if that's not defined then no caching occurs.


Testing

I've tested the following scenarios

renderParams[osapi.container.RenderParam.NO_CACHE] = true; (and false)

and

params[gadgets.io.RequestParameters.NO_CACHE] = 1; (and 0)

and

neither defined




Diffs (updated)

  *   trunk/features/src/main/javascript/features/core.io/io.js (1625072)
  *   trunk/features/src/test/javascript/features/core.io/iotest.js (1515531)

View Diff

Re: caching and 500 errors

[Davies,Douglas]

So let me summarize.

1) The NO_CACHE RenderParam does not appear to affect makeRequest.  From what 
I’ve seen this would require a patch to io.js (as suggested at 
http://markmail.org/message/535kwx47svi626om).  I’ve found several projects 
that branch from shindig that have applied this patch.

2) Ideally it would be nice to do this on a per request basis with a new 
RequestParameters.NO_CACHE flag.  Nuxeo did this.  
http://hg.nuxeo.org/nuxeo/nuxeo-features/rev/46feb3f6ce5e

3) When doing an OUTH2 flow the first request to the service that returns the 
oauthApprovalUrl probably shouldn’t be cached or set in the staleResponse, 
because then it could possibly be used on the response for the ACTUAL request 
if it returns a 500 (my scenario).  Thus an endless loop of display the 
approval url and making the service call.

For now I am using my patched RequestPipleline which turns off caching for all 
oauth2 request.

public HttpResponse execute(HttpRequest request) throws GadgetException {
if (request.getAuthType() == AuthType.OAUTH2) {
request.setIgnoreCache(true);
}
return super.execute(request);
}

I can submit a patch for 1 or 2 (or both) if it’s agreed that’s desired 
functionality.  For #3 it might be outside my shindig knowledge scope, but I 
can try.

doug


On Aug 21, 2014, at 10:56 AM, Davies,Douglas  wrote:

> I found this issue
> 
> http://markmail.org/message/535kwx47svi626om
> 
> I wonder if this is my issue as well.  I am setting the nocache (even 
> appended &nocache=1 to my service call) and it still doesn’t work.
> 
> It really would be nice I could specify NO_CACHE on the RequestParameters.  
> Or is the Pipeline changes I suggested earlier (only for the oauth2 flow) the 
> right way to go?
> 
> doug
> 
> On Aug 21, 2014, at 9:58 AM, Davies,Douglas  wrote:
> 
>> Stanton,
>> 
>> Thanks for pointing me in the right direction.  It does appear I have a 
>> problem with my NO_CACHE setting.
>> 
>> I do the following when rendering the gadget.
>> 
>>  renderParams[osapi.container.RenderParam.NO_CACHE] = true;
>>  container.navigateGadget( gadgetSite, gadget.appUrl, {}, renderParams, 
>> function(gadgetInfo)
>> 
>> However I’m not seeing it set in MakeRequestHandler.java where it does
>> 
>>   req.setIgnoreCache("1".equals(getParameter(request, 
>> Param.NO_CACHE.getKey(), null)));
>> 
>> Looking into this.  From looking at the code it does seem like all this 
>> staleResponse and caching mumbo-jumbo should be bypassed if I get this set 
>> right.
>> 
>> Thanks,
>> doug
> 
> 

Re: caching and 500 errors

[Davies,Douglas]

I found this issue

http://markmail.org/message/535kwx47svi626om

I wonder if this is my issue as well.  I am setting the nocache (even appended 
&nocache=1 to my service call) and it still doesn’t work.

It really would be nice I could specify NO_CACHE on the RequestParameters.  Or 
is the Pipeline changes I suggested earlier (only for the oauth2 flow) the 
right way to go?

doug

On Aug 21, 2014, at 9:58 AM, Davies,Douglas  wrote:

> Stanton,
> 
> Thanks for pointing me in the right direction.  It does appear I have a 
> problem with my NO_CACHE setting.
> 
> I do the following when rendering the gadget.
> 
>   renderParams[osapi.container.RenderParam.NO_CACHE] = true;
>   container.navigateGadget( gadgetSite, gadget.appUrl, {}, renderParams, 
> function(gadgetInfo)
> 
> However I’m not seeing it set in MakeRequestHandler.java where it does
> 
>req.setIgnoreCache("1".equals(getParameter(request, 
> Param.NO_CACHE.getKey(), null)));
> 
> Looking into this.  From looking at the code it does seem like all this 
> staleResponse and caching mumbo-jumbo should be bypassed if I get this set 
> right.
> 
> Thanks,
> doug

Re: caching and 500 errors

[Davies,Douglas]

Stanton,

Thanks for pointing me in the right direction.  It does appear I have a problem 
with my NO_CACHE setting.

I do the following when rendering the gadget.

renderParams[osapi.container.RenderParam.NO_CACHE] = true;
container.navigateGadget( gadgetSite, gadget.appUrl, {}, renderParams, 
function(gadgetInfo)

However I’m not seeing it set in MakeRequestHandler.java where it does

req.setIgnoreCache("1".equals(getParameter(request, 
Param.NO_CACHE.getKey(), null)));

Looking into this.  From looking at the code it does seem like all this 
staleResponse and caching mumbo-jumbo should be bypassed if I get this set 
right.

Thanks,
doug

On Aug 20, 2014, at 4:44 PM, Davies,Douglas  wrote:

> The response code on the first request is a 200 and I see an access token 
> created in the db.  Then the next call is the one that returns the 500.  I 
> tried the “nocache” but wasn’t successful.  Let me try again.
> 
> What I ended up doing was this (just to test — not necessarily the solution). 
>  I extended DefaultRequestPipeline and then bound to it with Guice.
> 
> @Singleton
> public class PlatformDefaultRequestPipeline extends DefaultRequestPipeline {
> 
>@Inject
>public PlatformDefaultRequestPipeline(HttpFetcher httpFetcher,
>  HttpCache httpCache,
>  Provider oauthRequestProvider,
>  Provider 
> oauth2RequestProvider,
>  @RewriterRegistry(rewriteFlow = 
> ResponseRewriterList.RewriteFlow.REQUEST_PIPELINE)
>  ResponseRewriterRegistry 
> responseRewriterRegistry,
>  InvalidationService invalidationService,
>  @Nullable HttpResponseMetadataHelper 
> metadataHelper) {
> 
>super(httpFetcher, httpCache, oauthRequestProvider, 
> oauth2RequestProvider, responseRewriterRegistry,
>invalidationService, metadataHelper);
>}
> 
>protected HttpResponse fixFetchedResponse(HttpRequest request, 
> HttpResponse fetchedResponse,
>  @Nullable HttpResponse 
> invalidatedResponse, @Nullable HttpResponse staleResponse)
>throws GadgetException {
> 
>// Don't touch OAUTH2 requests (for now!!!)
> 
>if (request.getAuthType() == AuthType.OAUTH2) {
> 
>return fetchedResponse;
>}
> 
>return super.fixFetchedResponse(request, fetchedResponse, 
> invalidatedResponse, staleResponse);
>}
> 
> }
> 
> It just bypasses the fixFetchedResponse for oauth2 calls.  When I do this my 
> gadget behaves as desired.  Maybe that helps shed some more light on it.
> 
> doug
> 
> 
> 
> On Aug 20, 2014, at 4:30 PM, Stanton Sievers 
> mailto:ssiev...@apache.org>> wrote:
> 
> Hey Doug,
> 
> What's the HTTP response code on the first request that returns the
> oauthApprovalUrl?  From what I can tell, if the cachedResponse has a status
> code >=400, we won't use it as the staleResponse in the case of a 500 error
> on the subsequent request.
> 
> Regarding not caching your service calls at all, you can use the "nocache"
> in the render parameters but that will result in ALL calls bypassing the
> cache and not just your particular service calls.
> 
> Regards,
> -Stanton
> 
> 
> On Wed, Aug 20, 2014 at 11:18 AM, Davies,Douglas 
> mailto:davi...@oclc.org>> wrote:
> 
> Hi Guys,
> 
> It’s Doug Davies.  Been a while since I’ve been active on the shindig mail
> list.  We are getting back into our shindig implementation.  We have
> upgraded our container to the latest release.
> 
> We are having an issue that I think I brought up in the past, but I can’t
> find the thread in the archives.
> 
> Here’s the scenario…
> 
> We have an oauth2 gadget that makes a request to one of our internal
> services.  That service happens to return a 500 error for a bad parameter
> that gets passed in (I know probably not the right response, but I don’t
> have control over that).  When it makes the first call to the service it
> gets back an oauthApprovalUrl like it should.  I then present the UI for
> that link to initiate the oauth2 handshake.  Once it’s done the gadget then
> makes the request again, this time with an access token.  However, since
> the service returns a 500 it seems the DefaultRequestPipeline code uses the
> “staleResponse” (the last successful response that had the oauthApprovalUrl
> in it) and so I get into an infinite loop.
> 
> I tried setting
> 
> params[gadgets.io.RequestParameters.REFRESH_INTERVAL] = 0;
> 
> but that doesn’t seem to matter.  Ideas on how to solve this?  Even if a
> 500 error isn’t the right response to be returning, it still seems like I’d
> want to detect that this happened rather than the response looking like the
> oauth flow needs to be initiated again.
> 
> In fact, I don’t know that I want any of my service calls being cached.
> 
> Thanks,
> Doug Davies
> 
> 
> 
> 

Re: caching and 500 errors

[Davies,Douglas]

The response code on the first request is a 200 and I see an access token 
created in the db.  Then the next call is the one that returns the 500.  I 
tried the “nocache” but wasn’t successful.  Let me try again.

What I ended up doing was this (just to test — not necessarily the solution).  
I extended DefaultRequestPipeline and then bound to it with Guice.

@Singleton
public class PlatformDefaultRequestPipeline extends DefaultRequestPipeline {

@Inject
public PlatformDefaultRequestPipeline(HttpFetcher httpFetcher,
  HttpCache httpCache,
  Provider oauthRequestProvider,
  Provider oauth2RequestProvider,
  @RewriterRegistry(rewriteFlow = 
ResponseRewriterList.RewriteFlow.REQUEST_PIPELINE)
  ResponseRewriterRegistry 
responseRewriterRegistry,
  InvalidationService invalidationService,
  @Nullable HttpResponseMetadataHelper 
metadataHelper) {

super(httpFetcher, httpCache, oauthRequestProvider, 
oauth2RequestProvider, responseRewriterRegistry,
invalidationService, metadataHelper);
}

protected HttpResponse fixFetchedResponse(HttpRequest request, HttpResponse 
fetchedResponse,
  @Nullable HttpResponse 
invalidatedResponse, @Nullable HttpResponse staleResponse)
throws GadgetException {

// Don't touch OAUTH2 requests (for now!!!)

if (request.getAuthType() == AuthType.OAUTH2) {

return fetchedResponse;
}

return super.fixFetchedResponse(request, fetchedResponse, 
invalidatedResponse, staleResponse);
}

}

It just bypasses the fixFetchedResponse for oauth2 calls.  When I do this my 
gadget behaves as desired.  Maybe that helps shed some more light on it.

doug



On Aug 20, 2014, at 4:30 PM, Stanton Sievers 
mailto:ssiev...@apache.org>> wrote:

Hey Doug,

What's the HTTP response code on the first request that returns the
oauthApprovalUrl?  From what I can tell, if the cachedResponse has a status
code >=400, we won't use it as the staleResponse in the case of a 500 error
on the subsequent request.

Regarding not caching your service calls at all, you can use the "nocache"
in the render parameters but that will result in ALL calls bypassing the
cache and not just your particular service calls.

Regards,
-Stanton


On Wed, Aug 20, 2014 at 11:18 AM, Davies,Douglas 
mailto:davi...@oclc.org>> wrote:

Hi Guys,

It’s Doug Davies.  Been a while since I’ve been active on the shindig mail
list.  We are getting back into our shindig implementation.  We have
upgraded our container to the latest release.

We are having an issue that I think I brought up in the past, but I can’t
find the thread in the archives.

Here’s the scenario…

We have an oauth2 gadget that makes a request to one of our internal
services.  That service happens to return a 500 error for a bad parameter
that gets passed in (I know probably not the right response, but I don’t
have control over that).  When it makes the first call to the service it
gets back an oauthApprovalUrl like it should.  I then present the UI for
that link to initiate the oauth2 handshake.  Once it’s done the gadget then
makes the request again, this time with an access token.  However, since
the service returns a 500 it seems the DefaultRequestPipeline code uses the
“staleResponse” (the last successful response that had the oauthApprovalUrl
in it) and so I get into an infinite loop.

I tried setting

params[gadgets.io.RequestParameters.REFRESH_INTERVAL] = 0;

but that doesn’t seem to matter.  Ideas on how to solve this?  Even if a
500 error isn’t the right response to be returning, it still seems like I’d
want to detect that this happened rather than the response looking like the
oauth flow needs to be initiated again.

In fact, I don’t know that I want any of my service calls being cached.

Thanks,
Doug Davies

caching and 500 errors

[Davies,Douglas]

Hi Guys,

It’s Doug Davies.  Been a while since I’ve been active on the shindig mail 
list.  We are getting back into our shindig implementation.  We have upgraded 
our container to the latest release.

We are having an issue that I think I brought up in the past, but I can’t find 
the thread in the archives.

Here’s the scenario…

We have an oauth2 gadget that makes a request to one of our internal services.  
That service happens to return a 500 error for a bad parameter that gets passed 
in (I know probably not the right response, but I don’t have control over 
that).  When it makes the first call to the service it gets back an 
oauthApprovalUrl like it should.  I then present the UI for that link to 
initiate the oauth2 handshake.  Once it’s done the gadget then makes the 
request again, this time with an access token.  However, since the service 
returns a 500 it seems the DefaultRequestPipeline code uses the “staleResponse” 
(the last successful response that had the oauthApprovalUrl in it) and so I get 
into an infinite loop.

I tried setting

params[gadgets.io.RequestParameters.REFRESH_INTERVAL] = 0;

but that doesn’t seem to matter.  Ideas on how to solve this?  Even if a 500 
error isn’t the right response to be returning, it still seems like I’d want to 
detect that this happened rather than the response looking like the oauth flow 
needs to be initiated again.

In fact, I don’t know that I want any of my service calls being cached.

Thanks,
Doug Davies

Re: [VOTE] Release Apache Shindig version 2.5.0-update1

[Davies,Douglas]

Any update on this?

doug

On 10/5/13 6:13 PM, "Ryan Baxter"  wrote:

>Hi,
>
>We solved 5 issues:
>https://issues.apache.org/jira/issues/?jql=project%20%3D%20SHINDIG%20AND%2
>0fixVersion%20%3D%20%222.5.0-update1%22%20ORDER%20BY%20priority%20DESC
>
>
>Staging repo:
>https://repository.apache.org/content/repositories/orgapacheshindig-132/
>
>Web site:
>http://shindig.apache.org/
>
>Vote open for 72 hours.
>
>[ ] +1
>[ ] +0
>[ ] -1
>

Re: Releasing 2.5.0-update1

[Davies,Douglas]

+1

On 9/25/13 5:41 PM, "Ryan Baxter"  wrote:

>Hi All,
>
>Seems like a couple critical fixes have been delivered to
>2.5.0-update1 over the past few weeks and I have not seen any other
>reports of bugs coming in.  What does everyone thing about releasing
>2.5.0-update1?  We can always do an update2 if we end up finding
>anything else.
>
>-Ryan
>

Re: startup error

[Davies,Douglas]

Actually, I'm gonna take a step back... I think there might be an issue for
applications that also define an ehcache.

Shindig's EhCacheCacheProvider uses the following call

cacheManager = CacheManager.create(getConfiguration(configPath));

I think that is looking for a singleton instance.  If I provide my own
CacheProvider and change the line to this

cacheManager = CacheManager.newInstance(getConfiguration(configPath));

Then it works.  It's able to use shindig's configuration.

I think when it uses the create method it's looking for a singleton but
there are 2 caches defined and it has no choice but to fallback to the
failsafe configuration embedded in the ehcache jars, which has
overflowtodisk set to true BTW, thus I think my problem.


So the solution might be for me to just provide my own CacheProvider,
however I still think shindig should not assume it's the only ehcache
client.  I have to do some more reading about ehcaches to see if there is
another solution, but this seems to be my best bet right now.

doug


On 8/30/13 9:11 AM, "Davies,Douglas"  wrote:

>We have another ehcache manager (not provider) that seems to be
>conflicting with the shindig one, but only under jetty, not tomcat.  If I
>remove our cache manager things work.  I'm trying to figure out how to
>have two ehcache configurations or merge into one.  At any rateŠ not a
>shindig problem that I can see.  Thanks.
>
>doug
>
>On 8/28/13 3:32 PM, "Stanton Sievers"  wrote:
>
>>Hi Doug,
>>
>>The fix for SHINDIG-1912 shouldn't have any effect unless you are also
>>setting the "ehcache.disk.store.dir" system property somewhere.
>>Otherwise,
>>it defaults to the temp dir, which was the behavior prior to
>>SHINDIG-1912.
>>
>>From the error, it looks like you're trying to serialize something to
>>disk
>>that shouldn't be serialized.  Are you providing your own
>>ehcacheConfig.xml
>>or overriding the EhCacheCacheProvider?  By default we will only persist
>>the compiled JavaScript to disk and neither its keys nor values look like
>>the thing from the log entry you posted.
>>
>>Thanks,
>>-Stanton
>>
>>
>>On Wed, Aug 28, 2013 at 1:14 PM, Davies,Douglas  wrote:
>>
>>> Ok, I spoke too soon about us upgrading to 2.5.0 smoothly. :)
>>>
>>> Our container includes the shindig artifacts but also relies on Spring
>>>and
>>> a few other internal libraries.  If I startup under Tomcat 7 things are
>>> working fine.  If I run under Jetty I'm seeing this
>>>
>>> 2013-08-28 12:59:15,682 ERROR [expressions.datahread]
>>> net.sf.ehcache.store.disk.DiskStorageFactory - Disk Write of
>>> //%host%${CONTEXT_ROOT}/rpc failed:
>>> java.io.NotSerializableException: de.odysseus.el.tree.Tree
>>>
>>> In the logs (a lot of them) on startup.
>>>
>>> I'm going through and synching up our web.xml, etc.  I do know that we
>>> create our own ehcache for another one of our libraries we include.
>>>Could
>>> be a conflict there.
>>>
>>> This happened somewhere between beta5 and release.
>>>
>>> Any pointer on what to look for?  I've combed through the release
>>>notes.
>>>  I do see something about configuring ehcache (
>>> https://issues.apache.org/jira/browse/SHINDIG-1912).
>>>
>>> Doug Davies
>>>
>>>
>>>
>

Re: startup error

[Davies,Douglas]

We have another ehcache manager (not provider) that seems to be
conflicting with the shindig one, but only under jetty, not tomcat.  If I
remove our cache manager things work.  I'm trying to figure out how to
have two ehcache configurations or merge into one.  At any rateŠ not a
shindig problem that I can see.  Thanks.

doug

On 8/28/13 3:32 PM, "Stanton Sievers"  wrote:

>Hi Doug,
>
>The fix for SHINDIG-1912 shouldn't have any effect unless you are also
>setting the "ehcache.disk.store.dir" system property somewhere.
>Otherwise,
>it defaults to the temp dir, which was the behavior prior to SHINDIG-1912.
>
>From the error, it looks like you're trying to serialize something to disk
>that shouldn't be serialized.  Are you providing your own
>ehcacheConfig.xml
>or overriding the EhCacheCacheProvider?  By default we will only persist
>the compiled JavaScript to disk and neither its keys nor values look like
>the thing from the log entry you posted.
>
>Thanks,
>-Stanton
>
>
>On Wed, Aug 28, 2013 at 1:14 PM, Davies,Douglas  wrote:
>
>> Ok, I spoke too soon about us upgrading to 2.5.0 smoothly. :)
>>
>> Our container includes the shindig artifacts but also relies on Spring
>>and
>> a few other internal libraries.  If I startup under Tomcat 7 things are
>> working fine.  If I run under Jetty I'm seeing this
>>
>> 2013-08-28 12:59:15,682 ERROR [expressions.datahread]
>> net.sf.ehcache.store.disk.DiskStorageFactory - Disk Write of
>> //%host%${CONTEXT_ROOT}/rpc failed:
>> java.io.NotSerializableException: de.odysseus.el.tree.Tree
>>
>> In the logs (a lot of them) on startup.
>>
>> I'm going through and synching up our web.xml, etc.  I do know that we
>> create our own ehcache for another one of our libraries we include.
>>Could
>> be a conflict there.
>>
>> This happened somewhere between beta5 and release.
>>
>> Any pointer on what to look for?  I've combed through the release notes.
>>  I do see something about configuring ehcache (
>> https://issues.apache.org/jira/browse/SHINDIG-1912).
>>
>> Doug Davies
>>
>>
>>

Re: startup error

[Davies,Douglas]

Stanton,

Great observation.  I'll focus on that.  We don't provide our own
ehcacheConfig or EhCacheProvider.  It does look like it's trying to cache
container properties or something.  We do merge our container specific
properties (and overrides) using a class I wrote, so maybe that's
interfering.  I'll keep ya posted.

Thanks.

On 8/28/13 3:32 PM, "Stanton Sievers"  wrote:

>Hi Doug,
>
>The fix for SHINDIG-1912 shouldn't have any effect unless you are also
>setting the "ehcache.disk.store.dir" system property somewhere.
>Otherwise,
>it defaults to the temp dir, which was the behavior prior to SHINDIG-1912.
>
>From the error, it looks like you're trying to serialize something to disk
>that shouldn't be serialized.  Are you providing your own
>ehcacheConfig.xml
>or overriding the EhCacheCacheProvider?  By default we will only persist
>the compiled JavaScript to disk and neither its keys nor values look like
>the thing from the log entry you posted.
>
>Thanks,
>-Stanton
>
>
>On Wed, Aug 28, 2013 at 1:14 PM, Davies,Douglas  wrote:
>
>> Ok, I spoke too soon about us upgrading to 2.5.0 smoothly. :)
>>
>> Our container includes the shindig artifacts but also relies on Spring
>>and
>> a few other internal libraries.  If I startup under Tomcat 7 things are
>> working fine.  If I run under Jetty I'm seeing this
>>
>> 2013-08-28 12:59:15,682 ERROR [expressions.datahread]
>> net.sf.ehcache.store.disk.DiskStorageFactory - Disk Write of
>> //%host%${CONTEXT_ROOT}/rpc failed:
>> java.io.NotSerializableException: de.odysseus.el.tree.Tree
>>
>> In the logs (a lot of them) on startup.
>>
>> I'm going through and synching up our web.xml, etc.  I do know that we
>> create our own ehcache for another one of our libraries we include.
>>Could
>> be a conflict there.
>>
>> This happened somewhere between beta5 and release.
>>
>> Any pointer on what to look for?  I've combed through the release notes.
>>  I do see something about configuring ehcache (
>> https://issues.apache.org/jira/browse/SHINDIG-1912).
>>
>> Doug Davies
>>
>>
>>

startup error

[Davies,Douglas]

Ok, I spoke too soon about us upgrading to 2.5.0 smoothly. :)

Our container includes the shindig artifacts but also relies on Spring and a 
few other internal libraries.  If I startup under Tomcat 7 things are working 
fine.  If I run under Jetty I'm seeing this

2013-08-28 12:59:15,682 ERROR [expressions.datahread] 
net.sf.ehcache.store.disk.DiskStorageFactory - Disk Write of 
//%host%${CONTEXT_ROOT}/rpc failed:
java.io.NotSerializableException: de.odysseus.el.tree.Tree

In the logs (a lot of them) on startup.

I'm going through and synching up our web.xml, etc.  I do know that we create 
our own ehcache for another one of our libraries we include.  Could be a 
conflict there.

This happened somewhere between beta5 and release.

Any pointer on what to look for?  I've combed through the release notes.  I do 
see something about configuring ehcache 
(https://issues.apache.org/jira/browse/SHINDIG-1912).

Doug Davies

smooth

[Davies,Douglas]

Hi guys,

Been a while since I participated in the group.  Just wanted to let you know we 
upgraded our container to the release of shindig-2.5.0 (we had been at beta4 
for quite a while) and it went really smooth.  Beside the ImmediateFuture 
stuff, we had to change very little.

Thanks for all the hard work.  And congrats to Ryan!

Doug Davies
OCLC

Re: iGoogle

[Davies,Douglas]

Ya, I saw that thread but the answer seemed kind of vague. It's still unclear 
to me what other google products are utilizing opensocial and whether they'll 
be abandoning it as well. I guess whether google is supporting it or not at 
this point is irrelevant, but there are concerns around my company that this 
spells the doom of opensocial and we should be looking at other alternatives. I 
don't see it that way but others are. 

Doug

Sent from my iPad

On Jul 9, 2012, at 3:15 PM, "Ryan Baxter"  wrote:

> Doug, Paul had responded to a similar thread on the OpenSocial spec list
> [1].
> 
> [1]
> https://groups.google.com/forum/?fromgroups#!topic/opensocial-and-gadgets-spec/abooeRuiMcE
> 
> On Mon, Jul 9, 2012 at 11:01 AM, daviesd  wrote:
> 
> > Anyone have any opinion what the shutdown of iGoogle means for Google¹s
> > support of OpenSocial?  I¹m assuming (but don¹t know for sure) that
> > Google+,
> > etc. use opensocial (or at least google gadgets)?  Doesn¹t this just mean
> > that Google+ might become the new home for installing gadgets?  I know the
> > Googlers probably can¹t comment on this.  Just wondering if this has any
> > bearing on opensocial.
> >
> > doug
> >

redirect_uri

[Davies,Douglas]

In shindig.properties there is a value “shindig.oauth2.global-redirect-uri” for 
the default oauth2 callback uri to use if a client doesn’t configure one.  
There is also one for oauth1 “shindig.signing.global-callback-url”.  OAuth1 
also has one in container.js "//%host%${CONTEXT_ROOT}/gadgets/oauthcallback".

The one in container.js is nicer because it doesn’t have the protocol embedded 
in it.  Unfortunately there doesn’t seem to be one for oauth2.

Which one should be used to inject into the java code? globalRedirectUri in 
JSONOAuth2Persister.  Right now nothing is being set, but I assume I could use 
a @Named parameter.  Just wondered where that comes from and whether I can 
easily add a non protocol specific one for oauth2.  If it’s using the one from 
shindig.properties, is there a way to make it protocol agnostic?

Thanks,
doug

Re: URGENT: Shindig snapshots

[Davies,Douglas]

Interesting. I didn't know that existed.  So what is the shindig activity on 
builds.apache.org? Dead build process?  Just curious, since it seems to be 
running something. 

Thanks for talking a look at it. Hopefully there will be a snapshot for me 
tomorrow. 

On Jun 12, 2012, at 9:38 PM, "Paul Lindner"  wrote:

> Hmm, looks like the java.net download of the JVM failed on hudson.inuus.com 
> (my home server).  I'll fix it up..
> 
> On Tue, Jun 12, 2012 at 6:30 PM, Davies,Douglas  wrote:
> Paul, can you help out here?
> 
> Thanks,
> Doug
> 
> On Jun 12, 2012, at 9:01 PM, "Ryan J Baxter"  wrote:
> 
> > Doug, I am not really familiar how this all works.  Paul is probably your
> > best bet.
> >
> > -Ryan
> >
> >
> >
> >
> > From:   daviesd 
> > To: shindig ,
> > Date:   06/12/2012 10:34 AM
> > Subject:Re: Shindig snapshots
> >
> >
> >
> > I¹m not familiar with the continuous build, assembly, and snapshot process
> > for shindig, but it seems like the assemblies are failing (if this is even
> > how the snapshots are created).
> >
> > https://builds.apache.org/job/Shindig%20Assembly/
> >
> > I found a thread from back in May where this was being addressed.
> >
> > http://shindig-dev.markmail.org/thread/6xhhijzcpyguykl3
> >
> > Is there anyone besides Paul who can check on why artifacts have not been
> > generated since May 4 (if not I might URGENT him)?  Is no one else
> > dependant
> > on snapshots or are you just pulling trunk and creating your own?  We use
> > to
> > rely on the the daily snapshots but have been on beta1 for quite a while,
> > so
> > I didn¹t even realize no new artifacts were being generated.
> >
> > doug
> >
> >
> > On 6/11/12 2:34 PM, "daviesd"  wrote:
> >
> >> I¹m having issues again getting the latest maven artifacts (I¹ve been
> > using
> >> beta1 for a while now).  This is the repository I¹m using (for both beta
> > and
> >> snapshot)
> >>
> >> https://repository.apache.org/content/groups/public/org/apache/shindig
> >>
> >> However the snapshots don¹t seem to have been updated since the
> > beginning of
> >> May.  Am I using the wrong location?
> >>
> >> Doug
> >
> >
> 
> 
> 
> -- 
> Paul Lindner -- lind...@inuus.com -- profiles.google.com/pmlindner

URGENT: Shindig snapshots

[Davies,Douglas]

Paul, can you help out here?

Thanks,
Doug

On Jun 12, 2012, at 9:01 PM, "Ryan J Baxter"  wrote:

> Doug, I am not really familiar how this all works.  Paul is probably your 
> best bet.
> 
> -Ryan
> 
> 
> 
> 
> From:   daviesd 
> To: shindig , 
> Date:   06/12/2012 10:34 AM
> Subject:Re: Shindig snapshots
> 
> 
> 
> I¹m not familiar with the continuous build, assembly, and snapshot process
> for shindig, but it seems like the assemblies are failing (if this is even
> how the snapshots are created).
> 
> https://builds.apache.org/job/Shindig%20Assembly/
> 
> I found a thread from back in May where this was being addressed.
> 
> http://shindig-dev.markmail.org/thread/6xhhijzcpyguykl3
> 
> Is there anyone besides Paul who can check on why artifacts have not been
> generated since May 4 (if not I might URGENT him)?  Is no one else 
> dependant
> on snapshots or are you just pulling trunk and creating your own?  We use 
> to
> rely on the the daily snapshots but have been on beta1 for quite a while, 
> so
> I didn¹t even realize no new artifacts were being generated.
> 
> doug
> 
> 
> On 6/11/12 2:34 PM, "daviesd"  wrote:
> 
>> I¹m having issues again getting the latest maven artifacts (I¹ve been 
> using
>> beta1 for a while now).  This is the repository I¹m using (for both beta 
> and
>> snapshot)
>> 
>> https://repository.apache.org/content/groups/public/org/apache/shindig
>> 
>> However the snapshots don¹t seem to have been updated since the 
> beginning of
>> May.  Am I using the wrong location?
>> 
>> Doug
> 
> 

Re: oauth2 dance

[Davies,Douglas]

Thanks. I'll investigate option 4. 

On Apr 26, 2012, at 2:50 PM, "A Clarke"  wrote:

> Doug,
> 
> There's three options you can try out easily, none of these worked for us
> so we did option 4 and extended the OAuth2 Consumer and Provider to
> seamlessly suppress the dance.
> 
> 1) Client Credentials.  The authorization code flow hinges on the dance
> occuring, but client credentials works without the dance.  It requires that
> your target provider support client credentials.  The problem we
> encountered here was that there was no suitable way to assert the user's
> identity in the client credentials flow.
> 
> 2) Shared Client.  This dropped recently with Jira 1731.  It allows you to
> specify that all gadgets bound to a client share the same access and
> refresh tokens.  Meaning the user only has to go through the dance once.
> 
> 3) Custom implementation of shared clients.  You can write your own version
> of shared clients that returns the same token for every gadget in your
> OAuth2Persister.  This of course requires that a valid access token is
> available, either by opting in once or having some custom logic to
> prepoluate a token.
> 
> 4) Customize your provider and customize your consumer to work together.
> The approach that we eventually took.
> 
> 
> 
> On Thu, Apr 26, 2012 at 11:58 AM, daviesd  wrote:
> 
> > A quick yes or no question which is plaguing us right now.
> >
> > Does an oauth2 enabled gadget ALWAYS have to do the popup oauth2 dance?  In
> > other words, there is no way to make a service call without first having a
> > user click the authorization url and the authorization server redirecting
> > the browser back to the redirect uri.  Correct?  Is there a way to do this
> > automatically (but then I suspect you¹d get a browser warning).  And if you
> > don¹t share the access token across multiple services, then you¹d have to
> > go
> > through the oauth2 dance for each type of service???
> >
> > Ok, maybe not a simple yes/no answer. :)
> >
> > doug
> >

Re: Does data-pipelining in proxied content require oauth to be configured?

[Davies,Douglas]

Thanks Ryan. Hmmm... So any idea what we might be doing wrong?

Doug

Sent from my iPad

On Apr 26, 2012, at 6:38 PM, "Ryan J Baxter"  wrote:

> Doug, I have not tried this in a while, but last time I did OAuth was not 
> required.
> 
> -Ryan
> 
> 
> 
> 
> From:   daviesd 
> To: shindig , 
> Date:   04/26/2012 06:13 PM
> Subject:Does data-pipelining in proxied content require oauth to 
> be configured?
> 
> 
> 
> I have a developer trying to use proxied content.  Their gadget looks as
> follows:
> 
> href="http://localhost/some.php";
> type="html" 
> authz="signed"
> xmlns:os="http://ns.opensocial.org/2008/markup";>
>   
>
> 
> We keep getting a 403 back from the server
> 
> WARNING: The following fatal error occurred when OAuth was fetching 
> content:
> Unable to retrieve consumer key.
> Apr 26, 2012 6:04:38 PM org.apache.shindig.gadgets.render.Renderer render
> INFO: The gadget at http://dl.dropbox.com/u/x/gadgets/karen_proxy.xml
> did not render. The following error occurred: Unable to reach remote host.
> HTTP status 403.
> 
> If we set authz to none then we get ³Must sign by viewer to request 
> viewer².
> 
> So I¹m assuming you must turn authz on for data-pipelining to work.  Does
> this mean I need to configure oauth in shindig.properties?  I don¹t
> currently and this is probably my problem, but just checking.
> 
> doug
> 
> 

Re: Shindig running on different domain than container REVISITED

[Davies,Douglas]

Thanks Stanton. So no rpc_relay setup etc.?  Seems last time I did this I ran 
into that. 

Doug

Sent from my iPhone

On Mar 21, 2012, at 3:43 PM, "Stanton Sievers"  wrote:

> Hi Doug,
> 
> Yes, things work just fine running the container page and shindig on 
> different domains.  You can set the osapi.container.ServiceConfig.API_HOST 
> and osapi.container.ServiceConfig.API_PATH when creating your 
> osapi.container.Container object to get the right pointers in place. 
> 
> Best regards,
> -Stanton
> 
> 
> 
> From:   daviesd 
> To: shindig , 
> Date:   03/21/2012 13:04
> Subject:Shindig running on different domain than container 
> REVISITED
> 
> 
> 
> About a year ago there was a discussion about shindig running on a 
> different
> domain than the container.
> 
> http://permalink.gmane.org/gmane.comp.web.shindig.devel/6824
> 
> Up till this point we have been running our shindig servers and our
> container webapps on the same domain.  We¹d like to move away from this. 
> Is
> this possible with shindig 2.5.0?  Have there been changes since this
> discussion?  If so, is there documentation on what configuration needs to
> happen to get this to work?
> 
> Thanks,
> Doug
> 
> 

Re: Features css

[Davies,Douglas]

Thanks Paul. And if you get a chance can you check out my message about 
JsonUtil and it's use of the guava collections? I'm having issues with it.  
Thanks. 

Doug

On Mar 11, 2012, at 1:01 AM, "Paul Lindner"  wrote:

> No specific way afaik.
> 
> This js injection of css works pretty well and if you use an XHR also can
> speed up page loads.
> 
> On Thu, Mar 8, 2012 at 8:04 AM, daviesd  wrote:
> 
>> Is there a way for a feature to include css?  I noticed minimessage does
>> this, but messily through container.js.  I¹d like to have a feature.css
>> that
>> sits along side the feature.xml and feature.js.  Any ideas are appreciated.
>> 
>> Doug
>> 
> 
> 
> 
> -- 
> Paul Lindner -- lind...@inuus.com -- profiles.google.com/pmlindner

Re: Review Request: Common container currently doesnt include the siteId (moduleId) in any of it's security token processing/handling

[Davies,Douglas]

Not to throw a monkey wrench into things, but maybe this will help set 
direction too. I reported bug a few months back

https://issues.apache.org/jira/browse/SHINDIG-1557

I discovered that the security token used for rpc request (appdata, userPrefs) 
is the container security token, not the gadget's. So even if you get the 
siteId/moduleId in the token you might find you don't have access to it. 

Doug

On Dec 23, 2011, at 7:45 AM, "Jesse Ciancetta"  wrote:

> 
> 
>> On 2011-12-22 20:34:52, Dan Dumont wrote:
>>> http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.gadget/gadget_site.js,
>>>  line 419
>>> 
>>> 
>>>Do you know why this is done in the loadingGadgetHolder?
> 
> Yeah -- it ends up getting used further down the line during 
> osapi.container.GadgetHolder.prototype.render -- specifically in 
> osapi.container.GadgetHolder.prototype.getIframeUrl_ (line 346 -- 348).
> 
> Although I just noticed something else interesting that I hadn't noticed 
> before -- it looks like the original authors of CC are actually already using 
> the siteId as the moduleId...  They just (apparently) forgot to also use it 
> in the security tokens.
> 
> If you look at lines 350 and 351 in gadget_holder.js you'll see that the 
> siteId is used as the 'mid' parameter in the iframe url -- which means that 
> the gadgets JS API code that deals with moduleId's will end up using the 
> siteId as the moduleId (because the gadgets JS API parses the moduleId from 
> the 'mid' parameter in the iframe url).  However as we've been discussing the 
> moduleId in the security token gets set to 0 -- so anything on the server 
> side that pulls the moduleId from the security token will get the wrong value.
> 
> You can actually see all this play out right now in shindig head by messing 
> around with the common container sample page and adding a few gadgets.  To 
> see what I'm taking about -- using shindig head -- browse to the CC sample 
> container, add the todo and horoscope gadgets (to use up a couple of 
> siteId's) and then add the activities stream sample (to get a gadget that 
> needs a security token) -- then using firefox right click the whitespace in 
> the activities gadget and load it into its own tab (so you can easily see the 
> requests it makes in firebug and execute code against the gadgets API in the 
> context of that gadget).  Then -- if you reload that tab, watch in firebug 
> and look at the security token passed with the soacial API calls -- you'll 
> see the moduleId in it is 0 -- but if you execute this code in the console:
> 
> var prefs = new gadgets.Prefs();
> console.log(prefs.getModuleId());
> 
> You'll get back 'gadget-site-2'
> 
> So I guess this gives some precedent for using the siteId as the moduleId.  
> As I've said before I personally think this would work out fine (using siteId 
> as moduleId) and might be worth trying to start with and then changing later 
> if we run into issues -- but in the end I dont think it makes much difference 
> to me.  There's also precedent for something similar elsewhere too (in both 
> igoogle and rave and likely other places as well).  If you look at igoogle 
> for example you'll see that they wrap all their gadgets in a div which 
> includes their moduleId (and in CC we use that wrapper div ID as the siteId). 
>  Ryan and I had a discussion on this a while back which might be worth 
> looking over again -- here is the relevant piece:
> 
> http://markmail.org/message/6fqyufoynv2q5q6a
> 
> 
> - Jesse
> 
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/1632/#review4085
> ---
> 
> 
> On 2011-12-14 21:13:40, Jesse Ciancetta wrote:
>> 
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/1632/
>> ---
>> 
>> (Updated 2011-12-14 21:13:40)
>> 
>> 
>> Review request for shindig.
>> 
>> 
>> Summary
>> ---
>> 
>> Common container currently doesn't include the siteId (moduleId) in any of 
>> it's security token processing/handling (all security tokens in common 
>> container currently get minted with a moduleId of 0).
>> 
>> This patch is a first (rough) cut at getting moduleId's into security 
>> tokens.  I am posting it somewhat prematurely to solicit feedback before I 
>> invest any more time in finishing up the last bits.  Here are the things 
>> that I know are still left to do:
>> 
>> -- Update unit tests on both the JS and Java side -- currently I've been 
>> building and deploying with skipTests=true...
>> -- Figure out a strategy for dealing with preloaded gadgets.  The current 
>> auth-refresh process maintains tokens for preloa

Re: Errors with gadgets.views.requestNavigateTo

[Davies,Douglas]

Possibly. I don't know enough about what the functionality should be. I was 
surprised there wasn't a default implementation of requestNavigateToHandler 
either. I posted my implementation earlier and would be willing to submit a 
patch for that if people think its appropriate. 

Doug

Sent from my iPad

On Oct 8, 2011, at 5:19 PM, "Henry Saputra"  wrote:

> requestNavigateToHandler

Re: BlobCrypterSecurityTokenCodec relies on instanceof in the face of Proxy

[Davies,Douglas]

Stanton,

I've had exactly the same problem (in fact I think I posted an earlier question 
on this and there is also an open jira -- sorry I don't have the number 
offhand).  I have a patched version that doesn't do the instanceof check, but I 
don't like it. So I too am looking for the correct approach. Email me directly 
if you want more details.  I have a complete secure token implementation 
working both from the container and gadget. 

Doug

Sent from my iPad

On Sep 16, 2011, at 5:48 PM, "Stanton Sievers"  wrote:

> Hi everyone,
> 
> When using the default implementation of "secure" security tokens in 
> Shindig, we use BlobCrypterSecurityTokenCodec and BlobCrypterSecurityToken 
> as our SecurityTokenCodec and SecurityToken, respectively.  This is all 
> well and good until we try to generate an iframeurl with the security 
> token in it.  Security tokens are only added as an iframeurl query 
> parameter when the gadget requires the "security-token" feature, 
> explicitly or implicitly through other requires such as "opensocial". 
> 
> In short, DefaultIframeUriManager tries to generate the "st" query 
> parameter and we get into 
> BlobCrypterSecurityTokenCodec.encodeToken(SecurityToken) which checks if 
> token instanceof BlobCrypterSecurityToken.  This instanceof returns false 
> because BlobCrypterSecurityToken has been Proxied by 
> GadgetsHandlerService.convertAuthContext(AuthContext, String, String). The 
> aforementioned encodeToken method relies on being able to call 
> BlocCrypterSecurityToken.encrypt(), which is not a method that exists on 
> SecurityToken for which the Proxy was created.
> 
> The result is that the iframeurl "st" query parameter is templated.  That 
> is, we get "...&st="%25st%25"..." for the iframeurl.
> 
> Has anyone been able to get this use case working?  Any ideas on how it 
> can be fixed? I'm not an expert on how Java's Proxies work but this seems 
> critically blocked due to the use of a Proxy.  One solution would be to 
> add an "encrypt" method to the SecurityToken interface but that seems like 
> cheating. :)
> 
> Thanks,
> -Stanton
> 

Re: Review Request: Enable loading security token key from either an absolute filesystem reference or from the classpath

[Davies,Douglas]

Excellent. I had just done something similar. Thanks. 

Doug

Sent from my iPhone

On Aug 12, 2011, at 11:17 AM, "Jesse Ciancetta"  wrote:

> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/1480/
> ---
> 
> Review request for shindig.
> 
> 
> Summary
> ---
> 
> Patch to enable loading security token key from either an absolute filesystem 
> reference (as it does currently) or from the classpath.  
> 
> After I finished writing the patch I went to create a JIRA ticket for it in 
> the Shindig project and realized I should search to see if one already 
> existed -- and sure enough I found one, complete with a patch which is quite 
> similar to mine!  :)
> 
> It looks like the issues with the previous patch were formatting issues and 
> the fact that the previous patch removed the extensibility hook in 
> BlobCrypterSecurityTokenCodec (the loadCrypterFromFile method allowing 
> implementers to plug in their own BlobCrypter) -- luckily this patch does not 
> suffer from either or those issues (at least I don't think it does!).
> 
> It should be noted however that the loadCrypterFromFile method *has* been 
> renamed to loadCrypter (breaking backwards compatibility with the existing 
> API), however since we're moving from a 2.X to a 3.X version this would seem 
> acceptable.
> 
> 
> This addresses bugs RAVE-173 and SHINDIG-811.
>https://issues.apache.org/jira/browse/RAVE-173
>https://issues.apache.org/jira/browse/SHINDIG-811
> 
> 
> Diffs
> -
> 
>  
> http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/auth/BlobCrypterSecurityTokenCodec.java
>  1036287 
>  
> http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/common/crypto/BasicBlobCrypter.java
>  1067589 
>  
> http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/test/java/org/apache/shindig/auth/BlobCrypterSecurityTokenCodecTest.java
>  1036287 
>  
> http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/test/java/org/apache/shindig/auth/DefaultSecurityTokenCodecTest.java
>  1036287 
> 
> Diff: https://reviews.apache.org/r/1480/diff
> 
> 
> Testing
> ---
> 
> All tests are passing and additional testing has been done in Tomcat with the 
> different loading mechanisms (absolute file reference and classpath 
> reference).
> 
> 
> Thanks,
> 
> Jesse
> 

RE: Common container rpc request uses wrong security token

[Davies,Douglas]

Here's what I'm implementing.

 

Add a lifecycle handler for onNavigated.  It calls 

 

token = container.service_.getGadgetToken 

 

and then uses that to call 

 

var holder = gadgetSite.getActiveGadgetHolder();

gadgets.rpc.call(holder.getIframeId(), 'update_security_token',
null, token);

holder.setSecurityToken(token);

 

then in my set_pref handler I do

 

var holder =
rpcArgs[osapi.container.GadgetSite.RPC_ARG_KEY].getActiveGadgetHolder();

var token = holder.securityToken_;

gadgets.log('using token: ' + token);

var oldToken = shindig.auth.getSecurityToken();

shindig.auth.updateSecurityToken(token);

osapi.appdata.update(...)

 

Not ideal, but at least I now have a reference to the gadget security
token when set_pref calls osapi and I can use the appropriate appid.
I'm hoping what I'm doing fits in with whatever the common container
ends up doing when this is fully implemented.  I'm assuming the gadget
holder security token was meant for this purpose, but not sure.  Of
course anywhere I need the gadget security token instead of the
container one I'm gonna have to intercept the rpc call.  I'd love to
trickle this down to the jsonrpcrequest level, but I couldn't figure out
how to get access to the gadget or gadget site at that level.

 

doug

 

From: Davies,Douglas 
Sent: Monday, July 18, 2011 10:52 AM
To: 'dev@shindig.apache.org'
Subject: Common container rpc request uses wrong security token

 

I have opened https://issues.apache.org/jira/browse/SHINDIG-1557.  The
gadget security token is not being used on rpc calls.  The container one
is.  Thus calls like appdata and userprefs do not have access to the
gadget information as they need.

 

In the meantime I'm going to try to work around this in my own
container.  Does anyone have any ideas how to get a hold of the
requesting gadget inside of jsonrpctransport? 

 

Thanks,

doug

Common container rpc request uses wrong security token

[Davies,Douglas]

I have opened https://issues.apache.org/jira/browse/SHINDIG-1557.  The
gadget security token is not being used on rpc calls.  The container one
is.  Thus calls like appdata and userprefs do not have access to the
gadget information as they need.

 

In the meantime I'm going to try to work around this in my own
container.  Does anyone have any ideas how to get a hold of the
requesting gadget inside of jsonrpctransport? 

 

Thanks,

doug

RE: jsonrpctransport.js

[Davies,Douglas]

This bug

https://issues.apache.org/jira/browse/SHINDIG-1432

kind of hints at something similar.  If I could get a hold of the gadget
object within jsonrpctransport, perhaps I could swap in the correct
security token.

doug

-Original Message-
From: Davies,Douglas 
Sent: Thursday, July 14, 2011 10:28 PM
To: dev@shindig.apache.org
Cc: dev@shindig.apache.org
Subject: Re: jsonrpctransport.js

Ryan,

Thanks. Still seems strange that this is not working. I would think
anyone using the common
container for anything substantial would have hit the same issue.
Perhaps no one else cares
that their security token has the right appid, etc. I guess the viewerid
will be the same for all.

Anyway... Still gonna play with it to see if I am doing something wrong.
I logged the rpcArgs
in set_pref and the only security token is on the iframe. There is a
security token in the gadget
site but it is empty as is the token cache. I had to patch every rpc
call to apply the right
security token. 

The set_pref gets called from the common container so not sure that
swapping for the REST API
is gonna be doable. 

Maybe I'll open up a bug report for this. Hopefully Michael will see
this and have some ideas. 

Doug

Sent from my iPad

On Jul 14, 2011, at 8:28 PM, "Ryan J Baxter" 
wrote:

> Doug, like you said I assume its using the container token because
your 
> calling the API in the context of the container.  What about using the

> REST API instead?  May be more of a pain but could be a work around to
the 
> problem.
> 
> -Ryan
> 
> Email: rjbax...@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
> 
> 
> 
> From:   "Davies,Douglas" 
> To: , 
> Date:   07/13/2011 09:39 PM
> Subject:Re: jsonrpctransport.js
> 
> 
> 
> Ryan,
> 
> Thanks for responding.  Was starting to wonder if my messages were
making 
> it to
> the mail list.
> 
> Yes I'm using appdata for a userpref store. Regardless of whether that
is 
> the right
> approach or not, the rpc call still seems like it should be using the 
> gadget security token
> instead of the container one. I think I understand why it does what it

> does since the
> rpc handler is in the container context and not gadget.
> 
> Any help is appreciated. I must be doing something wrong because this
just 
> seems like too
> glaring of a bug.
> 
> Doug
> 
> Sent from my iPad
> 
> On Jul 13, 2011, at 9:01 PM, "Ryan J Baxter" 
wrote:
> 
>> Doug just try to understand  your situation, are using app data as a
way 
> 
>> to store preferences?  So your registering an RPC handler for set
pref 
> in 
>> your container and your container is calling
osapi.appdata.update(...)? 
>> 
>> -Ryan
>> 
>> Email: rjbax...@us.ibm.com
>> Phone: 978-899-3041
>> developerWorks Profile
>> 
>> 
>> 
>> From:   "Davies,Douglas" 
>> To: , 
>> Date:   07/13/2011 03:04 PM
>> Subject:RE: jsonrpctransport.js
>> 
>> 
>> 
>> I put logging in my gadget and printed out the value of
>> shindig.auth.getSecurityToken and it was the correct one from the
iframe
>> st param.  I then log the same value before the osapi.appdata call
and
>> it's the container value.  So obviously they are using different
>> instances of the shindig.auth object.  This must have to do with my
>> set_pref being registered with the container (my set_pref is the one
>> using appdata).  I'm not sure how to get the osapi calls to use the
>> gadget security token.
>> 
>> 
>> 
>> doug
>> 
>> 
>> 
>> From: Davies,Douglas 
>> Sent: Wednesday, July 13, 2011 11:05 AM
>> To: 'dev@shindig.apache.org'
>> Subject: RE: jsonrpctransport.js
>> 
>> 
>> 
>> (Piggy backing on my own thread - and I meant calling appdata, not
>> userprefs)
>> 
>> 
>> 
>> I just had a lightbulb go off (I think).  Since each gadget is in
it's
>> own iframe I'm thinking that each gadget has it's own shindig.auth
>> reference.  Thus, the security token is per gadget, right?  But the
>> gadget writer is not suppose to call updateSecurityToken (and
shouldn't
>> even know anything about it).  I'm digging through the code to find
out
>> where this is set after the metadata request is made to get the
iframe
>> url.  Does that make sense or am I on the wrong track?
>> 
>> 
>> 
>> doug
>> 
>> 
>> 
>> From: Davies,Douglas 
>> Sent: Wednesday, July 13, 2011 9:45 AM
>> To: 'dev@shindig.apache.org'
>> Subject: jsonrpctransport.js
>> 
>> 
>> 
>

Re: jsonrpctransport.js

[Davies,Douglas]

Ryan,

Thanks. Still seems strange that this is not working. I would think anyone 
using the common
container for anything substantial would have hit the same issue. Perhaps no 
one else cares
that their security token has the right appid, etc. I guess the viewerid will 
be the same for all.

Anyway... Still gonna play with it to see if I am doing something wrong. I 
logged the rpcArgs
in set_pref and the only security token is on the iframe. There is a security 
token in the gadget
site but it is empty as is the token cache. I had to patch every rpc call to 
apply the right
security token. 

The set_pref gets called from the common container so not sure that swapping 
for the REST API
is gonna be doable. 

Maybe I'll open up a bug report for this. Hopefully Michael will see this and 
have some ideas. 

Doug

Sent from my iPad

On Jul 14, 2011, at 8:28 PM, "Ryan J Baxter"  wrote:

> Doug, like you said I assume its using the container token because your 
> calling the API in the context of the container.  What about using the 
> REST API instead?  May be more of a pain but could be a work around to the 
> problem.
> 
> -Ryan
> 
> Email: rjbax...@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
> 
> 
> 
> From:   "Davies,Douglas" 
> To: , 
> Date:   07/13/2011 09:39 PM
> Subject:Re: jsonrpctransport.js
> 
> 
> 
> Ryan,
> 
> Thanks for responding.  Was starting to wonder if my messages were making 
> it to
> the mail list.
> 
> Yes I'm using appdata for a userpref store. Regardless of whether that is 
> the right
> approach or not, the rpc call still seems like it should be using the 
> gadget security token
> instead of the container one. I think I understand why it does what it 
> does since the
> rpc handler is in the container context and not gadget.
> 
> Any help is appreciated. I must be doing something wrong because this just 
> seems like too
> glaring of a bug.
> 
> Doug
> 
> Sent from my iPad
> 
> On Jul 13, 2011, at 9:01 PM, "Ryan J Baxter"  wrote:
> 
>> Doug just try to understand  your situation, are using app data as a way 
> 
>> to store preferences?  So your registering an RPC handler for set pref 
> in 
>> your container and your container is calling osapi.appdata.update(...)? 
>> 
>> -Ryan
>> 
>> Email: rjbax...@us.ibm.com
>> Phone: 978-899-3041
>> developerWorks Profile
>> 
>> 
>> 
>> From:   "Davies,Douglas" 
>> To: , 
>> Date:   07/13/2011 03:04 PM
>> Subject:RE: jsonrpctransport.js
>> 
>> 
>> 
>> I put logging in my gadget and printed out the value of
>> shindig.auth.getSecurityToken and it was the correct one from the iframe
>> st param.  I then log the same value before the osapi.appdata call and
>> it's the container value.  So obviously they are using different
>> instances of the shindig.auth object.  This must have to do with my
>> set_pref being registered with the container (my set_pref is the one
>> using appdata).  I'm not sure how to get the osapi calls to use the
>> gadget security token.
>> 
>> 
>> 
>> doug
>> 
>> 
>> 
>> From: Davies,Douglas 
>> Sent: Wednesday, July 13, 2011 11:05 AM
>> To: 'dev@shindig.apache.org'
>> Subject: RE: jsonrpctransport.js
>> 
>> 
>> 
>> (Piggy backing on my own thread - and I meant calling appdata, not
>> userprefs)
>> 
>> 
>> 
>> I just had a lightbulb go off (I think).  Since each gadget is in it's
>> own iframe I'm thinking that each gadget has it's own shindig.auth
>> reference.  Thus, the security token is per gadget, right?  But the
>> gadget writer is not suppose to call updateSecurityToken (and shouldn't
>> even know anything about it).  I'm digging through the code to find out
>> where this is set after the metadata request is made to get the iframe
>> url.  Does that make sense or am I on the wrong track?
>> 
>> 
>> 
>> doug
>> 
>> 
>> 
>> From: Davies,Douglas 
>> Sent: Wednesday, July 13, 2011 9:45 AM
>> To: 'dev@shindig.apache.org'
>> Subject: jsonrpctransport.js
>> 
>> 
>> 
>> jsonrpctransport.js is using shindig.auth.getSecurityToken().  This is
>> great if the json rpc request is coming from the container.  However,
>> not if it's coming from the gadget.  For example let's say my gadget is
>> calling userprefs
>> 
>> 
>> 
>> osapi.appdata.update({
>> 
>>   userid : '@me',
>> 
>>   groupid : '@self',
>> 
>>   appId : '@app',
>> 
>>   data : data
>> 
>>   })
>> 
>> 
>> 
>> This instruct the request to use the appid from the security token
>> passed in on the call.  But this will end up using the appid that was
>> set by the container, not by the gadget.  Should this be using the
>> security token of the gadget?
>> 
>> 
>> 
>> I've posed this as a more general usage question over in users but I
>> thought maybe the devs would have a better idea of why this is coded
>> this way.
>> 
>> 
>> 
>> Doug
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> 
> 

Re: jsonrpctransport.js

[Davies,Douglas]

Ryan,

Thanks for responding.  Was starting to wonder if my messages were making it to
the mail list.

Yes I'm using appdata for a userpref store. Regardless of whether that is the 
right
approach or not, the rpc call still seems like it should be using the gadget 
security token
instead of the container one. I think I understand why it does what it does 
since the
rpc handler is in the container context and not gadget.

Any help is appreciated. I must be doing something wrong because this just 
seems like too
glaring of a bug.

Doug

Sent from my iPad

On Jul 13, 2011, at 9:01 PM, "Ryan J Baxter"  wrote:

> Doug just try to understand  your situation, are using app data as a way 
> to store preferences?  So your registering an RPC handler for set pref in 
> your container and your container is calling osapi.appdata.update(...)? 
> 
> -Ryan
> 
> Email: rjbax...@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
> 
> 
> 
> From:   "Davies,Douglas" 
> To: , 
> Date:   07/13/2011 03:04 PM
> Subject:RE: jsonrpctransport.js
> 
> 
> 
> I put logging in my gadget and printed out the value of
> shindig.auth.getSecurityToken and it was the correct one from the iframe
> st param.  I then log the same value before the osapi.appdata call and
> it's the container value.  So obviously they are using different
> instances of the shindig.auth object.  This must have to do with my
> set_pref being registered with the container (my set_pref is the one
> using appdata).  I'm not sure how to get the osapi calls to use the
> gadget security token.
> 
> 
> 
> doug
> 
> 
> 
> From: Davies,Douglas 
> Sent: Wednesday, July 13, 2011 11:05 AM
> To: 'dev@shindig.apache.org'
> Subject: RE: jsonrpctransport.js
> 
> 
> 
> (Piggy backing on my own thread - and I meant calling appdata, not
> userprefs)
> 
> 
> 
> I just had a lightbulb go off (I think).  Since each gadget is in it's
> own iframe I'm thinking that each gadget has it's own shindig.auth
> reference.  Thus, the security token is per gadget, right?  But the
> gadget writer is not suppose to call updateSecurityToken (and shouldn't
> even know anything about it).  I'm digging through the code to find out
> where this is set after the metadata request is made to get the iframe
> url.  Does that make sense or am I on the wrong track?
> 
> 
> 
> doug
> 
> 
> 
> From: Davies,Douglas 
> Sent: Wednesday, July 13, 2011 9:45 AM
> To: 'dev@shindig.apache.org'
> Subject: jsonrpctransport.js
> 
> 
> 
> jsonrpctransport.js is using shindig.auth.getSecurityToken().  This is
> great if the json rpc request is coming from the container.  However,
> not if it's coming from the gadget.  For example let's say my gadget is
> calling userprefs
> 
> 
> 
> osapi.appdata.update({
> 
>userid : '@me',
> 
>groupid : '@self',
> 
>appId : '@app',
> 
>data : data
> 
>})
> 
> 
> 
> This instruct the request to use the appid from the security token
> passed in on the call.  But this will end up using the appid that was
> set by the container, not by the gadget.  Should this be using the
> security token of the gadget?
> 
> 
> 
> I've posed this as a more general usage question over in users but I
> thought maybe the devs would have a better idea of why this is coded
> this way.
> 
> 
> 
> Doug
> 
> 
> 
> 
> 
> 

RE: jsonrpctransport.js

[Davies,Douglas]

I put logging in my gadget and printed out the value of
shindig.auth.getSecurityToken and it was the correct one from the iframe
st param.  I then log the same value before the osapi.appdata call and
it's the container value.  So obviously they are using different
instances of the shindig.auth object.  This must have to do with my
set_pref being registered with the container (my set_pref is the one
using appdata).  I'm not sure how to get the osapi calls to use the
gadget security token.

 

doug

 

From: Davies,Douglas 
Sent: Wednesday, July 13, 2011 11:05 AM
To: 'dev@shindig.apache.org'
Subject: RE: jsonrpctransport.js

 

(Piggy backing on my own thread - and I meant calling appdata, not
userprefs)

 

I just had a lightbulb go off (I think).  Since each gadget is in it's
own iframe I'm thinking that each gadget has it's own shindig.auth
reference.  Thus, the security token is per gadget, right?  But the
gadget writer is not suppose to call updateSecurityToken (and shouldn't
even know anything about it).  I'm digging through the code to find out
where this is set after the metadata request is made to get the iframe
url.  Does that make sense or am I on the wrong track?

 

doug

 

From: Davies,Douglas 
Sent: Wednesday, July 13, 2011 9:45 AM
To: 'dev@shindig.apache.org'
Subject: jsonrpctransport.js

 

jsonrpctransport.js is using shindig.auth.getSecurityToken().  This is
great if the json rpc request is coming from the container.  However,
not if it's coming from the gadget.  For example let's say my gadget is
calling userprefs

 

osapi.appdata.update({

userid : '@me',

groupid : '@self',

appId : '@app',

data : data

})

 

This instruct the request to use the appid from the security token
passed in on the call.  But this will end up using the appid that was
set by the container, not by the gadget.  Should this be using the
security token of the gadget?

 

I've posed this as a more general usage question over in users but I
thought maybe the devs would have a better idea of why this is coded
this way.

 

Doug

 

RE: jsonrpctransport.js

[Davies,Douglas]

(Piggy backing on my own thread - and I meant calling appdata, not
userprefs)

 

I just had a lightbulb go off (I think).  Since each gadget is in it's
own iframe I'm thinking that each gadget has it's own shindig.auth
reference.  Thus, the security token is per gadget, right?  But the
gadget writer is not suppose to call updateSecurityToken (and shouldn't
even know anything about it).  I'm digging through the code to find out
where this is set after the metadata request is made to get the iframe
url.  Does that make sense or am I on the wrong track?

 

doug

 

From: Davies,Douglas 
Sent: Wednesday, July 13, 2011 9:45 AM
To: 'dev@shindig.apache.org'
Subject: jsonrpctransport.js

 

jsonrpctransport.js is using shindig.auth.getSecurityToken().  This is
great if the json rpc request is coming from the container.  However,
not if it's coming from the gadget.  For example let's say my gadget is
calling userprefs

 

osapi.appdata.update({

userid : '@me',

groupid : '@self',

appId : '@app',

data : data

})

 

This instruct the request to use the appid from the security token
passed in on the call.  But this will end up using the appid that was
set by the container, not by the gadget.  Should this be using the
security token of the gadget?

 

I've posed this as a more general usage question over in users but I
thought maybe the devs would have a better idea of why this is coded
this way.

 

Doug

 

jsonrpctransport.js

[Davies,Douglas]

jsonrpctransport.js is using shindig.auth.getSecurityToken().  This is
great if the json rpc request is coming from the container.  However,
not if it's coming from the gadget.  For example let's say my gadget is
calling userprefs

 

osapi.appdata.update({

userid : '@me',

groupid : '@self',

appId : '@app',

data : data

})

 

This instruct the request to use the appid from the security token
passed in on the call.  But this will end up using the appid that was
set by the container, not by the gadget.  Should this be using the
security token of the gadget?

 

I've posed this as a more general usage question over in users but I
thought maybe the devs would have a better idea of why this is coded
this way.

 

Doug

 

Re: Handling Certificates

[Davies,Douglas]

We had the same situation.  The osapi.http.get call is be proxied through your 
shindig server. You need to install the certificate into the cacerts file on 
your shindig host using keytool then java should be able to find it. 

Doug

On Jul 6, 2011, at 5:09 PM, "Eric Woods"  wrote:

> Fellow Shindig Developers,
> 
> I have a tough question regarding certificates.  We have a server set up that 
> requires the acceptance of a certificate to access a URL which the server 
> hosts.  If I access the URL via a web browser, the browser prompts the user 
> to trust the certificate (i.e. add an exception for the certificate in 
> Firefox) prior to using the service.  Once I trust the certificate, all is 
> well.  From a Shindig/gadget perspective, however, we don't have a pretty UI 
> to prompt the user to accept the certificate.  We request the URL within a 
> gadget using osapi.http.get() as follows:
> 
> var params = {
>   "href": "https://myhost.com/irequireacertificate";,
>   "headers": {
> "Authorization": ["Basic xYz123"],
> "User-Agent": ["Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; 
> rv:5.0) Gecko/20100101 Firefox/5.0"],
> "Accept": 
> ["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,application/json"],
> "Accept-Encoding": ["gzip, deflate"],
> "Accept-Charset": ["ISO-8859-1,utf-8;q=0.7,*;q=0.7"]
> };
> osapi.http.get(params).execute(function(resp) {
>   console.log(resp);
> });
> 
> Invoking the request throws the following exception from BasicHttpFetcher:
> 
> Caused by: org.apache.shindig.gadgets.GadgetException: 
> javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
> at 
> org.apache.shindig.gadgets.http.BasicHttpFetcher.fetch(BasicHttpFetcher.java:389)
> at 
> org.apache.shindig.gadgets.http.DefaultRequestPipeline.execute(DefaultRequestPipeline.java:104)
> at 
> org.apache.shindig.gadgets.servlet.HttpRequestHandler.execute(HttpRequestHandler.java:231)
> ... 33 more
> 
> I suspect (and a quick Google search agrees) that this is likely because the 
> server requires a certificate to be trusted, but Shindig's BasicHttpFetcher 
> is unable to handle this challenge, so things blow up.  What type of strategy 
> should we use for gadgets handling certificates?  I don't have enough 
> expertise with SSL certificates for a credible recommendation.
> 
> Thanks!
> - Eric W.

RE: Implementing userPrefs with common container

[Davies,Douglas]

I got this working.  I wasn't able to abstract it away as much as I
would have liked.  I ended up creating a new class that extends
GadgetsHandlerService and overrides the inner MetadataGadgetContext
class which implements getUserPrefs.  I then instruct Guice to use my
class instead of GadgetsHandlerService.  My metadata request is now
returning my preferences I stored via the earlier set_pref
implementation.  I think some work need to be done to
GadgetsHandlerService to really abstract this away and use the delegate.
I may tackle that at some point.

Thanks for the pointers.

doug

-Original Message-
From: Davies,Douglas 
Sent: Wednesday, June 29, 2011 1:57 PM
To: dev@shindig.apache.org; 'craig...@gmail.com'
Subject: RE: Implementing userPrefs with common container

Craig,

Thanks for the info.  I thought appdata was per person, not per gadget.
I'm probably misunderstanding something here.  I will investigate.

I'm also trying to find the correct server-side metadata plugin point.
It looks like the MetadataGadgetContext class might be the right plugin
point by implementing getUserPrefs().  But I don't see an easy way to do
this since MetadataGadgetContext is a protected class in
GadgetsHandlerService and there doesn't seem to be any Guice
configuration around this module that I can inject something different.
We build from the maven artifacts, so I don't really want to be
*patching* any code here.

Thanks,
doug

-Original Message-
From: Craig McClanahan [mailto:craig...@gmail.com] 
Sent: Wednesday, June 29, 2011 1:26 PM
To: dev@shindig.apache.org
Subject: Re: Implementing userPrefs with common container

On Wed, Jun 29, 2011 at 7:02 AM, Davies,Douglas 
wrote:

> I've implemented the set_pref rpc call and it's getting called
> appropriately from the gadgets.  I've got this sitting ontop of
appdata
> and it seems to be persisting my values fine.  I am using the gadget
url
> combined with the preference name to generate the appdata store key.
I
> had to search/replace all non appdata friendly key characters
> (AppHandler only allows alpha-numeric, dash, underscore, and period).
> Does this sound like the right way to be doing this if I want to
> leverage off of appdata?
>
> One caution on using appdata for this purpose -- all users of the same
gadget can read the appdata settings for all users, and therefore could
see
other users's preference settings in your approach.  That is not a good
idea
from a privacy perspective.

In our implementation (Jive Software), we created additional RPC calls
back
to the server and stored the privacy settings in a database table keyed
by
user, gadget, and preference name.  We go beyond the spec requirements
and
allow a gadget to define a custom view for their preferences, or default
to
constructing a generic one based on the data types.

Craig McClanahan

>
>
> I am now figuring out where to plugin to retrieve and override the
> userprefs returned from the metadata/iframe calls.  Again... any
> feedback from anyone who has been through this process is appreciated.
>
>
>
> doug
>
>
>
> From: Davies,Douglas
> Sent: Monday, June 27, 2011 9:59 AM
> To: 'dev@shindig.apache.org'
> Subject: Implementing userPrefs with common container
>
>
>
> I'm looking into implementing userPrefs with the common container, but
> I'm unclear as to what is implemented and what just needs to be
> extended.
>
>
>
> My first step is to implement set_pref and register it with rpc.  I'm
> thinking of implementing this using the appData api (as I've seen
other
> threads along those lines).  I realize appData needs to be extended to
> use a persistent store.  I'm not sure what the default implementation
is
> using (in memory?).
>
>
>
> I would then think I need to modify the server side to return these
> userPrefs (overriding the ones from the gadget spec).  I'm not sure
> where to plug into here to use my persistent store.  It seems like the
> old container way was for DefaultIframeUriManager to return this when
it
> created the iframe url.  But I'm not sure that is what common
container
> is doing.  I think I need to plug into the gadgets.metadata request.
>
>
>
> Also it appears that sites like iGoogle provide a user interface from
> within the container to set the user prefs.  Is it the containers or
the
> gadgets responsibility to do this or a little bit of both?  I can see
a
> horoscope gadget using userPrefs to store a birthdate but not
> necessarily have to have a separate settings panel like iGoogle
> provides.
>
>
>
> Has anyone been through this process that would be willing to share
what
> they did?  Is this something that the common container will eventually
> support out of the box?  How far off base am I with my thinking here?
>
>
>
> Thanks,
>
> Doug
>
>

RE: Implementing userPrefs with common container

[Davies,Douglas]

Craig,

Thanks for the info.  I thought appdata was per person, not per gadget.
I'm probably misunderstanding something here.  I will investigate.

I'm also trying to find the correct server-side metadata plugin point.
It looks like the MetadataGadgetContext class might be the right plugin
point by implementing getUserPrefs().  But I don't see an easy way to do
this since MetadataGadgetContext is a protected class in
GadgetsHandlerService and there doesn't seem to be any Guice
configuration around this module that I can inject something different.
We build from the maven artifacts, so I don't really want to be
*patching* any code here.

Thanks,
doug

-Original Message-
From: Craig McClanahan [mailto:craig...@gmail.com] 
Sent: Wednesday, June 29, 2011 1:26 PM
To: dev@shindig.apache.org
Subject: Re: Implementing userPrefs with common container

On Wed, Jun 29, 2011 at 7:02 AM, Davies,Douglas 
wrote:

> I've implemented the set_pref rpc call and it's getting called
> appropriately from the gadgets.  I've got this sitting ontop of
appdata
> and it seems to be persisting my values fine.  I am using the gadget
url
> combined with the preference name to generate the appdata store key.
I
> had to search/replace all non appdata friendly key characters
> (AppHandler only allows alpha-numeric, dash, underscore, and period).
> Does this sound like the right way to be doing this if I want to
> leverage off of appdata?
>
> One caution on using appdata for this purpose -- all users of the same
gadget can read the appdata settings for all users, and therefore could
see
other users's preference settings in your approach.  That is not a good
idea
from a privacy perspective.

In our implementation (Jive Software), we created additional RPC calls
back
to the server and stored the privacy settings in a database table keyed
by
user, gadget, and preference name.  We go beyond the spec requirements
and
allow a gadget to define a custom view for their preferences, or default
to
constructing a generic one based on the data types.

Craig McClanahan

>
>
> I am now figuring out where to plugin to retrieve and override the
> userprefs returned from the metadata/iframe calls.  Again... any
> feedback from anyone who has been through this process is appreciated.
>
>
>
> doug
>
>
>
> From: Davies,Douglas
> Sent: Monday, June 27, 2011 9:59 AM
> To: 'dev@shindig.apache.org'
> Subject: Implementing userPrefs with common container
>
>
>
> I'm looking into implementing userPrefs with the common container, but
> I'm unclear as to what is implemented and what just needs to be
> extended.
>
>
>
> My first step is to implement set_pref and register it with rpc.  I'm
> thinking of implementing this using the appData api (as I've seen
other
> threads along those lines).  I realize appData needs to be extended to
> use a persistent store.  I'm not sure what the default implementation
is
> using (in memory?).
>
>
>
> I would then think I need to modify the server side to return these
> userPrefs (overriding the ones from the gadget spec).  I'm not sure
> where to plug into here to use my persistent store.  It seems like the
> old container way was for DefaultIframeUriManager to return this when
it
> created the iframe url.  But I'm not sure that is what common
container
> is doing.  I think I need to plug into the gadgets.metadata request.
>
>
>
> Also it appears that sites like iGoogle provide a user interface from
> within the container to set the user prefs.  Is it the containers or
the
> gadgets responsibility to do this or a little bit of both?  I can see
a
> horoscope gadget using userPrefs to store a birthdate but not
> necessarily have to have a separate settings panel like iGoogle
> provides.
>
>
>
> Has anyone been through this process that would be willing to share
what
> they did?  Is this something that the common container will eventually
> support out of the box?  How far off base am I with my thinking here?
>
>
>
> Thanks,
>
> Doug
>
>

RE: Implementing userPrefs with common container

[Davies,Douglas]

I've implemented the set_pref rpc call and it's getting called
appropriately from the gadgets.  I've got this sitting ontop of appdata
and it seems to be persisting my values fine.  I am using the gadget url
combined with the preference name to generate the appdata store key.  I
had to search/replace all non appdata friendly key characters
(AppHandler only allows alpha-numeric, dash, underscore, and period).
Does this sound like the right way to be doing this if I want to
leverage off of appdata?

 

I am now figuring out where to plugin to retrieve and override the
userprefs returned from the metadata/iframe calls.  Again... any
feedback from anyone who has been through this process is appreciated.

 

doug

 

From: Davies,Douglas 
Sent: Monday, June 27, 2011 9:59 AM
To: 'dev@shindig.apache.org'
Subject: Implementing userPrefs with common container

 

I'm looking into implementing userPrefs with the common container, but
I'm unclear as to what is implemented and what just needs to be
extended.

 

My first step is to implement set_pref and register it with rpc.  I'm
thinking of implementing this using the appData api (as I've seen other
threads along those lines).  I realize appData needs to be extended to
use a persistent store.  I'm not sure what the default implementation is
using (in memory?).  

 

I would then think I need to modify the server side to return these
userPrefs (overriding the ones from the gadget spec).  I'm not sure
where to plug into here to use my persistent store.  It seems like the
old container way was for DefaultIframeUriManager to return this when it
created the iframe url.  But I'm not sure that is what common container
is doing.  I think I need to plug into the gadgets.metadata request.

 

Also it appears that sites like iGoogle provide a user interface from
within the container to set the user prefs.  Is it the containers or the
gadgets responsibility to do this or a little bit of both?  I can see a
horoscope gadget using userPrefs to store a birthdate but not
necessarily have to have a separate settings panel like iGoogle
provides.

 

Has anyone been through this process that would be willing to share what
they did?  Is this something that the common container will eventually
support out of the box?  How far off base am I with my thinking here?

 

Thanks,

Doug

Implementing userPrefs with common container

[Davies,Douglas]

(I apologize if this posted to the dev group twice. My Entourage is
acting up again and this didn't seem to post the first time)

 

I'm looking into implementing userPrefs with the common container, but
I'm unclear as to what is implemented and what just needs to be
extended.

 

My first step is to implement set_pref and register it with rpc.  I'm
thinking of implementing this using the appData api (as I've seen other
threads along those lines).  I realize appData needs to be extended to
use a persistent store.  I'm not sure what the default implementation is
using (in memory?).  

 

I would then think I need to modify the server side to return these
userPrefs (overriding the ones from the gadget spec).  I'm not sure
where to plug into here to use my persistent store.  It seems like the
old container way was for DefaultIframeUriManager to return this when it
created the iframe url.  But I'm not sure that is what common container
is doing.  I think I need to plug into the gadgets.metadata request.

 

Also it appears that sites like iGoogle provide a user interface from
within the container to set the user prefs.  Is it the containers or the
gadgets responsibility to do this or a little bit of both?  I can see a
horoscope gadget using userPrefs to store a birthdate but not
necessarily have to have a separate settings panel like iGoogle
provides.

 

Has anyone been through this process that would be willing to share what
they did?  Is this something that the common container will eventually
support out of the box?  How far off base am I with my thinking here?

 

Thanks,

Doug

SHINDIG-1465 (userprefs and common container)

[Davies,Douglas]

Excuse my ignorance.  Does the fact that SHINDIG-1456 is marked as
closed necessarily mean the code/patch was committed?

 

http://shindig-dev.markmail.org/search/?q=SHINDIG-1465#query:SHINDIG-146
5%20order%3Adate-backward+page:1+mid:y4lophpf23lkymel+state:results

 

Is anyone else experiencing issues with default user preferences not
working?  I don't think setting useTpl to false is the correct approach
here.  Just wondering what the intended functionality is here or whether
this is still a work in progress?

 

Thanks,

doug

initializeGlobalVars

[Davies,Douglas]

Could someone explain the initializeGlobalVars code?  It looks for the
last script tag and assumes it was the one doing the gadget javascript
include (why???).  I noticed issue SHINDIG-1533 addresses this by
providing __CONTAINER_SCRIPT_ID to identify the correct script tag.
However in YUI where I load dynamically (Y.Get.script) I have no control
over the id beforehand.  Is there a more fullproof way of doing this?
I'm having issues with __CONTAINER, __API_URL, etc. being initialized
properly and I'm having to override them after loading the javascript,
which makes me very uncomfortable.

 

  function initializeGlobalVars() {

window.__CONTAINER_URI = shindig.uri(window.location.href);

 

window.__API_URI = null;

var scriptEl = null;

if (window.__CONTAINER_SCRIPT_ID) {

  scriptEl = document.getElementById(window.__CONTAINER_SCRIPT_ID);

} else {

  var scriptEls = document.getElementsByTagName('script');

  if (scriptEls.length > 0) {

scriptEl = scriptEls[scriptEls.length - 1];

  }

}

 

if (scriptEl) {

  window.__API_URI = shindig.uri(scriptEl.src);

  // In case script URI is relative, resolve (make absolute) with
container.

  window.__API_URI.resolve(window.__CONTAINER_URI);

}

 

window.__CONTAINER = window.__API_URI

? window.__API_URI.getQP('container')

: 'default';

  }

 

Thanks,

Doug

 

 

 

listMethods and https

[Davies,Douglas]

Our shindig server runs under https.  It appears that the shindig server
makes a call back to itself for listMethods using

 

  "osapi" : {

"endPoints" : [ "https://%host%/opensocial/rpc"; ]

  }

 

from container.js (which I've overridden with https and our webcontext).

 

1)  Why does shindig call back into itself and not just make a
function call?  Why doesn't it just use local host?  This requires the
certificate to be installed and java made aware of it.

2)  Some of these values seem to be used client-side as well as
server-side.  If I remember right, when I changed it to
http://localhost/opensocial/rpc , then I had trouble client-side.
Unfortunate that the value is used for dual purposes.

 

Any feedback is appreciated.

 

Doug

 

Adding a new service. Should it always be wrapped by a feature?

[Davies,Douglas]

We are adding a new service to our shindig server.  After reading this
article

 

http://www.dr-chuck.com/csev-blog/2010/07/sending-data-to-a-server-side-
service-with-shindig/

 

it appears to me that the service is then exposed through osapi.
However... is this the interface we should be exposing to our clients or
is it best practice to wrap the calls in a feature?  It seems that
towards the end of the article that's exactly what he does.  We are also
thinking of extending the common container and exposing the new service
through a feature that provides those extensions.  Do we help/hinder
ourselves in either scenario?

 

Doug

 

RE: Extending common container via features

[Davies,Douglas]

Disregard. Turns out I am doing everything correctly, just had a maven
build issue.  I was trying to build a separate features project.  Moving
it into the server made it work, so I'll work out my build issue.  At
any rate... very nice how you can extend common container.

Extending common container via features

[Davies,Douglas]

I'm trying to extend the commoncontainer.  I want to add a couple of new
apis.  I'm trying to do this by introducing a feature that adds the new
functionality.

 

In shindig.properties I have

 

shindig.features.default=res://features/features.txt,res://features/oclc
features.txt

 

referencing my new oclcfeatures.

 

In oclcfeatures.txt I have

 

features/oclccontainer/feature.xml

 

referencing the new feature.

 

In features/oclccontainer/feature.xml I have

 





  oclccontainer

  container

  

  

  



 

And finally in features/oclcontainer/oclccontainer.js I have

 

osapi.container.Container.addMixin("oclc", function(context) {

return {

"installGadget" : function() {

alert('installGadget');

}

};

});

 

In my client I'm doing the following (adding the oclccontainer feature)

 





 

var config = {};

var container = new osapi.container.Container(config);

 

container.oclc.installGadget('test');

 

However I get osapi undefined.  If I remove the
res://features/oclcfeatures.txt reference from shindig.properties, then
I get past the osapi.container call but then of course container.oclc is
not defined.

 

So two questions.  Am I adding the feature correctly and am I extending
the common container correctly?

 

Any help is appreciated.

 

Thanks,

Doug Davies

OCLC

 

RE: HTTP / HTTPS question

[Davies,Douglas]

Thanks Doug/John.

I revisited this and got it working.  In our case we do not build shindig from 
source.  We just pull down the maven artifacts and supply our own container.js. 
 I managed to find the correct values the get us up and running with https.  
The following are the container.js values I needed to override to get https to 
work.

"gadgets.jsUriTemplate" : "https://%host%/opensocial/gadgets/js/%js%";
"gadgets.uri.iframe.unlockedDomain" : "https://myhost";
"gadgets.uri.js.host" : "https://myhost";
"path" : "https://%host%/opensocial/rpc";
"invalidatePath" : "https://%host%/opensocial/rpc";
"endPoints" : [ "https://%host%/opensocial/rpc"; ]

No java code patched so far.  So apparently for my needs I'm not hitting the 
code paths you had to patch in java code.  We also run our shindig server on a 
different domain from the container client and a different web context 
(/opensocial), so we override some of those values in container.js as well. 

Thanks,
doug

-Original Message-
From: Doug Ellison [mailto:doug.elli...@gmail.com] 
Sent: Thursday, April 21, 2011 10:37 AM
To: Davies,Douglas
Cc: dev@shindig.apache.org; John Hjelmstad; Niels van Dijk
Subject: Re: HTTP / HTTPS question

So I think you've missed a point suggested by John.  There are certain
code paths that are simply not coded to be schema relative.  Meaning
certain parts of the code do not know the difference between http and
https.  You would need to implement those parts of the code that do
not support it at this time.  So unless I'm not taking your statement
of "I've tried most of the suggestions on this thread" to its full
conclusion meaning you have went in and implemented at least the one
portion that John mentioned for changing the code to be schema
relative.  Its just not going to work.  I don't know all the various
portions that need to be changed hence why I just did a find replace
all since my webapp it https only anways.

On Thu, Apr 21, 2011 at 7:48 AM, Davies,Douglas  wrote:
> I am hitting this issue as well. I've tried most of the suggestions on this 
> thread (except for the complete replacement of http for https).
>
> I had everything working great as http and had patched things to run as a 
> non-root webcontext (/opensocial).  The metadata call on the http version does
>
> POST http://myserver.org:8443/opensocial/rpc?st=-1%3A-1%3A*%3A%3A*%3A0%3Aoclc
>
> My https version does this at the same spot
>
> OPTIONS https://myserver.org:9443/api/rpc/cs?st=-1%3A-1%3A*%3A%3A*%3A0%3Aoclc
>
> And doesn't proceed any further.  Not sure why it's taking another path.  It 
> looks like I might need to patch service.js 
> (shindig.container.ServiceConfig.API_PATH).
>
> We will really need https support, so anyone that's gotten this to work 
> beyond the global search and replace I'd be interested to know what you did.
>
> Thanks,
> doug
>
>
>
> -Original Message-
> From: Doug Ellison [mailto:doug.elli...@gmail.com]
> Sent: Monday, March 28, 2011 4:42 PM
> To: John Hjelmstad
> Cc: Niels van Dijk; dev@shindig.apache.org
> Subject: Re: HTTP / HTTPS question
>
> So just thought I'd send this out to let people know where I went with
> this.  I didn't feel confident in my ability to write up a code patch
> to change everything from hard coded to relative but I did find a sort
> of "hacky" way around it.
> I did a full checkout of trunk and then ran the below command:
>  find . -exec grep -l 'http://[%]' {} \; | xargs sed -i
> 's/http:\/\/%/https:\/\/%/g'
> It breaks the tests which I'm then going to go back and work to fix
> but it does successfully take everything from http to https and the
> code "seems" to run just fine.  I realize this is not the best
> approach for everyone but this allowed me to do what I was wanting to
> do.
>
> Once again thank you soo much for the help John and everyone else
> who responded.
>
>
>
> On Fri, Mar 25, 2011 at 5:56 PM, John Hjelmstad  wrote:
>> That makes sense -- that's essentially what I mean when I say there are some
>> places where config and URL validation could use some cleanup to be
>> schema-agnostic. Best is schema-relative, but the difficulty w/ that is that
>> you need (in server code) to inject schema in various places.
>> --j
>>
>> On Fri, Mar 25, 2011 at 4:49 PM, Doug Ellison 
>> wrote:
>>>
>>> I guess what I'm referring to for transitions is I access servlets from
>>> https and they are accessible.  But checking chrome javascript logs there
>>> are still references to http and those references are 

RE: HTTP / HTTPS question

[Davies,Douglas]

I am hitting this issue as well. I've tried most of the suggestions on this 
thread (except for the complete replacement of http for https).

I had everything working great as http and had patched things to run as a 
non-root webcontext (/opensocial).  The metadata call on the http version does

POST http://myserver.org:8443/opensocial/rpc?st=-1%3A-1%3A*%3A%3A*%3A0%3Aoclc

My https version does this at the same spot

OPTIONS https://myserver.org:9443/api/rpc/cs?st=-1%3A-1%3A*%3A%3A*%3A0%3Aoclc

And doesn't proceed any further.  Not sure why it's taking another path.  It 
looks like I might need to patch service.js 
(shindig.container.ServiceConfig.API_PATH).

We will really need https support, so anyone that's gotten this to work beyond 
the global search and replace I'd be interested to know what you did.

Thanks,
doug



-Original Message-
From: Doug Ellison [mailto:doug.elli...@gmail.com] 
Sent: Monday, March 28, 2011 4:42 PM
To: John Hjelmstad
Cc: Niels van Dijk; dev@shindig.apache.org
Subject: Re: HTTP / HTTPS question

So just thought I'd send this out to let people know where I went with
this.  I didn't feel confident in my ability to write up a code patch
to change everything from hard coded to relative but I did find a sort
of "hacky" way around it.
I did a full checkout of trunk and then ran the below command:
 find . -exec grep -l 'http://[%]' {} \; | xargs sed -i
's/http:\/\/%/https:\/\/%/g'
It breaks the tests which I'm then going to go back and work to fix
but it does successfully take everything from http to https and the
code "seems" to run just fine.  I realize this is not the best
approach for everyone but this allowed me to do what I was wanting to
do.

Once again thank you soo much for the help John and everyone else
who responded.



On Fri, Mar 25, 2011 at 5:56 PM, John Hjelmstad  wrote:
> That makes sense -- that's essentially what I mean when I say there are some
> places where config and URL validation could use some cleanup to be
> schema-agnostic. Best is schema-relative, but the difficulty w/ that is that
> you need (in server code) to inject schema in various places.
> --j
>
> On Fri, Mar 25, 2011 at 4:49 PM, Doug Ellison 
> wrote:
>>
>> I guess what I'm referring to for transitions is I access servlets from
>> https and they are accessible.  But checking chrome javascript logs there
>> are still references to http and those references are what seem to break.
>> So transition is probably not the right word.  It doesn't always detect from
>> where it came http or https and always use the correct pathing.  Does that
>> make sense?  I guess I wilk try doing a replace all from http to https and
>> see what happens.
>>
>> On Mar 25, 2011 5:37 PM, "John Hjelmstad"  wrote:
>>
>> You can still host gadgets on an HTTP server -- that's an orthogonal issue
>> to the way that you access your Shindig-hosted server. Shindig acts as an
>> HTTP client when fetching gadgets, and can fetch via HTTP or HTTPS.
>> What do you refer to when you say http/https transitions? For the most
>> part Shindig supports HTTPS -- we @ Google use it extensively for this
>> purpose. But there are a few bits and pieces of config/verification around
>> that look like they could use some cleanup in the "default" installation to
>> ensure HTTP/HTTPS agnosticism.
>> --j
>>
>> On Fri, Mar 25, 2011 at 4:27 PM, Doug Ellison 
>> wrote: > > Thanks for all t...
>

RE: Shindig and webapp on same host/domain or not?

[Davies,Douglas]

Thanks Jesse, Isaiah, and everyone else that chimed in.

We've successfully got this working using urlrewrite.

Correct... I did not have the proxy type setup correcty (my co-worker
mentioned this to me too).  We also found we needed version 3.2.0 of
urlrewritefilter for the proxy type to work.

Our rule looks like this


/shindig/**
http://www.shindigserver.com/shindig/$1


So now we have a webapp/container running in one domain and using
shindig server running in another.  Exactly what we need.

Thanks for all the input.  I'm sure I'll be back soon with my next
stumbling block, but this gets us moving in the right direction.

Doug

RE: Shindig and webapp on same host/domain or not?

[Davies,Douglas]

Isaiah,

Were you successful on getting this to work?  I tried a similar approach
today using urlrewritefilter with the mapping:

/shindig/**
http://myshindigserver/shindig/$1

I see the request now changing using firebug

http://myshindigserver/shindig/rpc?st=-1%3A-1%3A*%3A%3A*%3A0%3Aoclc

but it returns a 400 (Bad Request) because there is NO post data.  There
should be a JSON post data with the gadgets to return info about (at
least that's what I see on the request when they are on the same
domain).  This is EXACTLY the same symptom I saw if I just hardcoded the
fully qualified dns name of in container.js.

I'm wondering if Michael Hermanto's idea to use an iframe is going to
behave any differently.

So for now we are stuck running our shindig server and webapp on the
same domain.

doug

-Original Message-
From: Isaiah Billingsley [mailto:isaiah.billings...@caseware.com] 
Sent: Tuesday, March 29, 2011 3:56 PM
To: dev@shindig.apache.org
Subject: Re: Shindig and webapp on same host/domain or not?

Hi Doug,

I was the one asking this same question earlier in the thread you
linked.

What I ended up doing (or rather, what I am still in the process of
implementing) was to run my webapp on a separate server from Shindig,
but with a rewrite rule on my webapp server to my Shindig server.

e.g. http://www.mywebapp.com/shindig/(.*)$  -->
http://www.myshindig.com/$1

This allows my container page to make requests to the shindig server,
since the request is to the same domain. It also gives me the security
of scenario 3, because the gadget iframes are still rendered on
www.myshindig.com as per container config.


Isaiah

Re: Shindig and webapp on same host/domain or not?

[Davies,Douglas]

Can you expound on that?  What do you mean you made the metadata call server 
side? What did you modify to do this? Won't I still have issues making other 
calls. Won't the web app on my localhost still use the relative path to make 
gadget API calls? I'm not sure I understand how the %host% substitution happens 
for the entries in container.js.

Sent from my iPad

On Mar 30, 2011, at 4:34 AM, "Christiaan Hees"  wrote:

> I ended up doing the metadata call on the server side instead of the
> client to avoid this issue and it works. But this is still using the
> old container code, so I'm not sure if it's the best solution for you.
> 
> On Wed, Mar 30, 2011 at 3:50 AM, Davies,Douglas  wrote:
>> I'm pretty sure it's just using one of the relative urls from container.js, 
>> because I know that if I modified all the urls on the server side I then saw 
>> it making the request to the shindig server correctly. However that request 
>> fails because there is no post data in the request for gadget metadata. Not 
>> sure if that is a cross domain issue or something else. Hopefully someone 
>> will have an idea. Thanks.
>> 
>> Doug
>> 
>> Sent from my iPhone
>> 
>> On Mar 29, 2011, at 9:18 PM, "Ryan J Baxter"  wrote:
>> 
>>> Hi Doug, I think you are right you should be striving for situation 3, at
>>> least that is my understanding.  We have not yet tried to separate Shindig
>>> and the web app so they are running on two different domains.  The only
>>> thing I can suggest is just diving into the common container code and
>>> figure out how it is figuring out the domain to use.  Off the top of my
>>> head I cannot recall how the common container is doing this.  Mike
>>> Hermanto may know more
>>> 
>>> -Ryan
>>> 
>>> Email: rjbax...@us.ibm.com
>>> Phone: 978-899-3041
>>> developerWorks Profile
>>> 
>>> 
>>> 
>>> From:   "Davies,Douglas" 
>>> To: Kris Vishwanathan/Fairfax/IBM@IBMUS, ,
>>> Date:   03/29/2011 04:35 PM
>>> Subject:RE: Shindig and webapp on same host/domain or not?
>>> 
>>> 
>>> 
>>> Hmmm... Now I am seriously confused.  I'm not sure we are both using the
>>> same terminology here.
>>> 
>>> I want this
>>> 
>>> Server 1 (domain x)
>>> --
>>> Shindig Server
>>> 
>>> Server 2 (domain y)
>>> --
>>> A webapp that uses javascript gadget api to communicate with shindig
>>> server and render gadgets into iframes
>>> 
>>> The problem is that server 2 is trying to call itself for the gadget api
>>> calls, since the container javascript is using relative paths.
>>> 
>>> As Isaiah then mentions, he is trying to do a rewrite rule on server 2
>>> to redirect the requests to the shindig server, however I suspect he'll
>>> run into cross-domain issues here (as suggested by the common container
>>> issue thread I referred to earlier).
>>> 
>>> I'm sure there is just some configuration or concept I am missing here.
>>> 
>>> doug
>>> 
>>> -Original Message-
>>> From: Kris Vishwanathan [mailto:v2k...@us.ibm.com]
>>> Sent: Tuesday, March 29, 2011 3:27 PM
>>> To: dev@shindig.apache.org
>>> Cc: Davies,Douglas; dev@shindig.apache.org
>>> Subject: Re: Shindig and webapp on same host/domain or not?
>>> 
>>> Scenario three is a reasonable approach and that's how most of the
>>> Social
>>> networking sites run.
>>> 
>>> Your deployment can look as below:
>>> 
>>> Server1  (Domain X)
>>> 
>>> 
>>> Shindig Server
>>> Common Container
>>> index.html or your webpage that bootstraps container and your page etc..
>>> 
>>> 
>>> Server 2 (Domain Y)
>>> -
>>> Your custom webapp
>>> Other gadget apps
>>> 
>>> 
>>> Hope it helps.
>>> 
>>> Thanks and regards
>>> 
>>> Kris Vishwanathan
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 

Re: Shindig and webapp on same host/domain or not?

[Davies,Douglas]

I'm pretty sure it's just using one of the relative urls from container.js, 
because I know that if I modified all the urls on the server side I then saw it 
making the request to the shindig server correctly. However that request fails 
because there is no post data in the request for gadget metadata. Not sure if 
that is a cross domain issue or something else. Hopefully someone will have an 
idea. Thanks. 

Doug

Sent from my iPhone

On Mar 29, 2011, at 9:18 PM, "Ryan J Baxter"  wrote:

> Hi Doug, I think you are right you should be striving for situation 3, at 
> least that is my understanding.  We have not yet tried to separate Shindig 
> and the web app so they are running on two different domains.  The only 
> thing I can suggest is just diving into the common container code and 
> figure out how it is figuring out the domain to use.  Off the top of my 
> head I cannot recall how the common container is doing this.  Mike 
> Hermanto may know more
> 
> -Ryan
> 
> Email: rjbax...@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
> 
> 
> 
> From:   "Davies,Douglas" 
> To: Kris Vishwanathan/Fairfax/IBM@IBMUS, , 
> Date:   03/29/2011 04:35 PM
> Subject:RE: Shindig and webapp on same host/domain or not?
> 
> 
> 
> Hmmm... Now I am seriously confused.  I'm not sure we are both using the
> same terminology here.
> 
> I want this
> 
> Server 1 (domain x)
> --
> Shindig Server
> 
> Server 2 (domain y)
> --
> A webapp that uses javascript gadget api to communicate with shindig
> server and render gadgets into iframes
> 
> The problem is that server 2 is trying to call itself for the gadget api
> calls, since the container javascript is using relative paths.
> 
> As Isaiah then mentions, he is trying to do a rewrite rule on server 2
> to redirect the requests to the shindig server, however I suspect he'll
> run into cross-domain issues here (as suggested by the common container
> issue thread I referred to earlier).
> 
> I'm sure there is just some configuration or concept I am missing here.
> 
> doug
> 
> -Original Message-
> From: Kris Vishwanathan [mailto:v2k...@us.ibm.com] 
> Sent: Tuesday, March 29, 2011 3:27 PM
> To: dev@shindig.apache.org
> Cc: Davies,Douglas; dev@shindig.apache.org
> Subject: Re: Shindig and webapp on same host/domain or not?
> 
> Scenario three is a reasonable approach and that's how most of the
> Social
> networking sites run.
> 
> Your deployment can look as below:
> 
> Server1  (Domain X)
> 
> 
> Shindig Server
> Common Container
> index.html or your webpage that bootstraps container and your page etc..
> 
> 
> Server 2 (Domain Y)
> -
> Your custom webapp
> Other gadget apps
> 
> 
> Hope it helps.
> 
> Thanks and regards
> 
> Kris Vishwanathan
> 
> 
> 
> 
> 
> 

RE: Shindig and webapp on same host/domain or not?

[Davies,Douglas]

Hmmm... Now I am seriously confused.  I'm not sure we are both using the
same terminology here.

I want this

Server 1 (domain x)
--
Shindig Server

Server 2 (domain y)
--
A webapp that uses javascript gadget api to communicate with shindig
server and render gadgets into iframes

The problem is that server 2 is trying to call itself for the gadget api
calls, since the container javascript is using relative paths.

As Isaiah then mentions, he is trying to do a rewrite rule on server 2
to redirect the requests to the shindig server, however I suspect he'll
run into cross-domain issues here (as suggested by the common container
issue thread I referred to earlier).

I'm sure there is just some configuration or concept I am missing here.

doug

-Original Message-
From: Kris Vishwanathan [mailto:v2k...@us.ibm.com] 
Sent: Tuesday, March 29, 2011 3:27 PM
To: dev@shindig.apache.org
Cc: Davies,Douglas; dev@shindig.apache.org
Subject: Re: Shindig and webapp on same host/domain or not?

Scenario three is a reasonable approach and that's how most of the
Social
networking sites run.

Your deployment can look as below:

Server1  (Domain X)


Shindig Server
Common Container
index.html or your webpage that bootstraps container and your page etc..


Server 2 (Domain Y)
-
Your custom webapp
Other gadget apps


Hope it helps.

Thanks and regards

Kris Vishwanathan

Shindig and webapp on same host/domain or not?

[Davies,Douglas]

I want to follow up with an earlier thread I had about webroot that has
taken me a different direction.  Sorry for starting a new thread, but
the listserv (or stupid entourage on the mac) is making it so that my
messages have been posted as 'daviesd' and not 'davi...@oclc.org' and
this seems to be affecting the delivery and even the web view of the
archive.  Anyway...

 

I need some assistance as far as how shindig and the application webapp
using shindig to render embedded gadgets should be deployed.  I've
successfully gotten shindig running along-side my application webapp
that uses it.  Both projects are their own war file and deployed to the
same server (and thus same fully qualified domain name).  The shindig
war has been patched to use the /shindig web context and the application
war runs as root.  So /index.html is the page that includes the common
container javascript and references /shindig/gadgets, etc.

 

Is the desired deployment architecture:

 

1.   Add shindig as part of an existing webapp 

2.   As a separate webapp on the same host/domain (as I've done) 

3.   Or as a separate webapp on a totally different host/domain (so
the application runs at www.mydomain.com and shindig runs at
www.myshindig.com).

 

I'm able to get things to work fine with scenario 1 and 2.  Scenario 3
is where I have problems.  The common container doesn't seem to support
shindig on a different host/domain then the webapp using it.  If I
deploy shindig to a different host and run my webapp locally, I see it
trying to use http://localhost:8080/shindig/rpc instead of
http://www.myshindig.com/shindig/rpc).  It appears the javascript apis
are using relatives paths based on the current browser host.

 

On top of all this I've seen various threads about security concerns as
to where the gadget is running.  In scenarios 1 and 2 it possibly has
access to private information in the webapp that is using it.  In
scenario 3 it's running in an isolated shindig farm and any malicious
activity would only affect those servers but not the main application.

 

As I've said in the previous thread... I might be totally
misunderstanding this.  I really want to push for scenario 3, but if
it's not supported in the common container (or in shindig at all) as
this thread suggests

 

http://mail-archives.apache.org/mod_mbox/shindig-dev/201102.mbox/%3cAANL
ktingsx79sqagrjfa4npdhh4xgkswoun4mf_eh...@mail.gmail.com%3e

 

then I'm willing to at least settle for scenario 2, assuming there are
not security concerns there.

 

Thanks,

Doug Davies

OCLC, Online Computer Library Catalog

Root webapp?

[Davies,Douglas]

Hello. I’m new to this listserv, so please correct any protocol/etiquette 
mistakes I might make.

I’m pretty new to opensocial and shindig.  I’ve played around with bringing the 
war file down and renaming it ROOT.war.  I’ve also played around with creating 
a new webapp application archetype and just pulling down the maven artifacts.  
The issue I’m struggling with (and I’ve seen references to it on this group) is 
the root web app v.s. non-root webapp approach.  It would appear to me that 
since through 1.0, 2.0, and now 3.0 the root deployment nature of shindig 
hasn’t changed, that this is the desired approach.  However I see many 
references to people patching container.js and shindig.properties to get it to 
run in a different web context.  I would think the later is the more common 
case, but I might be missing something.  The fact that there isn’t just 1 
location to change the context (and besides the fact that localhost is 
referenced all over the place) steers me into thinking the architects did not 
intend for this scenario however.  But then again, this is a reference 
implementation for us to change as required.

Then a co-worker pointed me to this article

http://www.freesoftwaremagazine.com/columns/opensocial_overview_how_opensocial_works_and_integrate_with_cms

And asked if I inferred from this that the javascript container code should be 
installed on one server while the shindig server should be installed on another 
(for security reasons???).  My thought was is I’d build a shindig.war that was 
specific to our needs and allow anyone to drop this into there current 
environment.  I was envisioning it on the same host so that the javascript and 
server were both deployed together and the webapp could just reference 
/shindig/gadgets, etc.  All the hosting webapp would have to do is define the 
DIV elements that want to render into and provide some database setup for 
persistence.  What is the drawback of this approach?  What is the preferred 
approach?  I hope this makes sense.

One other thing... If anyone is aware of consultants/contractors that are 
shindig experts, I’d be interested in talking to them about a possible stint at 
our company to help steer us in the right direction.

Thanks,

Doug Davies
OCLC, Online Computer Library Catalog