Sounds good to me. +1
From: Ryan J Baxter/Westford/IBM@Lotus To: dev@shindig.apache.org, Date: 11/22/2011 15:23 Subject: Re: SecurityTokenKeyFile +1 -Ryan Email: rjbax...@us.ibm.com Phone: 978-899-3041 developerWorks Profile From: Henry Saputra <henry.sapu...@gmail.com> To: dev@shindig.apache.org, Date: 11/22/2011 03:17 PM Subject: Re: SecurityTokenKeyFile I could live with updating the UPGRADING file. +1 - Henry On Tue, Nov 22, 2011 at 12:04 PM, Ciancetta, Jesse E. <jc...@mitre.org> wrote: >>-----Original Message----- >>From: Stanton Sievers [mailto:ssiev...@us.ibm.com] >>Sent: Tuesday, November 22, 2011 2:56 PM >>To: dev@shindig.apache.org >>Subject: Re: SecurityTokenKeyFile >> >>I thought the code was backwards compatible. Jesse, did your recent >>change remove the securityTokenKeyFile or did I do that by accident when I >>made my changes and introduced securityTokenKey? > > It was my change that removed the securityTokenKeyFile property entirely in favor of the one more flexible securityTokenKey property. > > Since we'd said previously that 2.x to 3.x could introduce breaking changes, and since we haven't actually done a full 3.x release yet I thought it would be alright to go ahead and cleanup the config and remove the old property. > > Would an entry in the UPGRADING file for this property name change suffice? I'd really rather keep the configuration clean if we can... > >>Thanks, >>-Stanton >> >> >> >>From: Henry Saputra <henry.sapu...@gmail.com> >>To: dev@shindig.apache.org, >>Date: 11/22/2011 14:51 >>Subject: Re: SecurityTokenKeyFile >> >> >> >>Thanks Jesse, >> >>Hmm maybe we should add code for old config compatibility for 3.0? >>Need to also check for "securityTokenKeyFile" config. >> >>Stanton, Ryan? >> >>- Henry >> >>On Tue, Nov 22, 2011 at 11:42 AM, daviesd <davi...@oclc.org> wrote: >>> Ah, I didn't catch that. Sorry. Yes, changing to just securityTokenKey >>> works. Thanks a lot! >>> >>> doug >>> >>> >>> On 11/22/11 2:36 PM, "Ciancetta, Jesse E." <jc...@mitre.org> wrote: >>> >>>>> -----Original Message----- >>>>> From: Ciancetta, Jesse E. >>>>> Sent: Tuesday, November 22, 2011 2:24 PM >>>>> To: shindig >>>>> Subject: RE: SecurityTokenKeyFile >>>>> >>>>>> -----Original Message----- >>>>>> From: daviesd [mailto:davi...@oclc.org] >>>>>> Sent: Tuesday, November 22, 2011 2:14 PM >>>>>> To: shindig >>>>>> Subject: SecurityTokenKeyFile >>>>>> >>>>>> I know there was a change recently (SHINDIG-1636) that changed the >>way >>>>> the >>>>>> token encryption key was loaded. I use to have >>>>>> >>>>>> "gadgets.securityTokenKeyFile" : "res://tokenkey.txt" >>>>> >>>>> Hmm -- I believe this should have worked and I tested this case when I >>was >>>>> testing the recent changes you referred to locally. I'll give it >>another try >>>>> in a >>>>> few minutes and report back what I find... >>>> >>>> Actually -- sorry -- that wouldn't have worked. The property name >>changed to >>>> just gadgets.securityTokenKey as you mentioned below but now that one >>property >>>> can be configured using either the key directly, a resource reference >>or a >>>> file-system reference. The default container.js should have samples of >>the >>>> three different ways it can be used now -- so for loading from the >>classpath >>>> it should be: >>>> >>>> "gadgets.securityTokenKey" : "res:// tokenkey.txt ", >>>> >>>> That actually applies to any property in container.js now -- not just >>the >>>> security token key (the ability to pull the value from a classpath >>resource or >>>> file-system reference that is). >>>> >>>> Please let me know if this resolves the issue for you. >>>> >>>>> >>>>>> >>>>>> But this appears to be broken now. tokenkey.txt would be in the root >>of my >>>>>> classes directory. I was able to get this to work by providing the >>key >>>>>> directly >>>>>> >>>>>> "gadgets.securityTokenKey" : "xxxxxxxxxx=" >>>>>> >>>>>> What is the correct way to refer to the file now? >>>>>> >>>>>> Doug >>>> >>> >>> >>> >> >> >> > >
