You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by daviesd <da...@oclc.org> on 2011/11/22 20:13:34 UTC
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"
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
RE: SecurityTokenKeyFile
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
>-----Original Message-----
>From: daviesd [mailto:daviesd@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...
>
>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
RE: SecurityTokenKeyFile
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
Done!
>-----Original Message-----
>From: Stanton Sievers [mailto:ssievers@us.ibm.com]
>Sent: Tuesday, November 22, 2011 3:58 PM
>To: dev@shindig.apache.org
>Subject: Re: SecurityTokenKeyFile
>
>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: rjbaxter@us.ibm.com
>Phone: 978-899-3041
>developerWorks Profile
>
>
>
>From: Henry Saputra <he...@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:ssievers@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 <he...@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 <da...@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:daviesd@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
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
>
>
Re: SecurityTokenKeyFile
Posted by Stanton Sievers <ss...@us.ibm.com>.
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: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: Henry Saputra <he...@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:ssievers@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 <he...@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 <da...@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:daviesd@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
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
Re: SecurityTokenKeyFile
Posted by Ryan J Baxter <rj...@us.ibm.com>.
+1
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: Henry Saputra <he...@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:ssievers@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 <he...@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 <da...@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:daviesd@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
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
Re: SecurityTokenKeyFile
Posted by Henry Saputra <he...@gmail.com>.
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:ssievers@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 <he...@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 <da...@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:daviesd@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
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
RE: SecurityTokenKeyFile
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
>-----Original Message-----
>From: Stanton Sievers [mailto:ssievers@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 <he...@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 <da...@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:daviesd@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
>>>
>>
>>
>>
>
>
>
Re: SecurityTokenKeyFile
Posted by Stanton Sievers <ss...@us.ibm.com>.
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?
Thanks,
-Stanton
From: Henry Saputra <he...@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 <da...@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:daviesd@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
>>
>
>
>
Re: SecurityTokenKeyFile
Posted by Henry Saputra <he...@gmail.com>.
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 <da...@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:daviesd@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
>>
>
>
>
Re: SecurityTokenKeyFile
Posted by daviesd <da...@oclc.org>.
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:daviesd@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
>
RE: SecurityTokenKeyFile
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
>-----Original Message-----
>From: Ciancetta, Jesse E.
>Sent: Tuesday, November 22, 2011 2:24 PM
>To: shindig
>Subject: RE: SecurityTokenKeyFile
>
>>-----Original Message-----
>>From: daviesd [mailto:daviesd@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