You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Ryan Baxter <rb...@apache.org> on 2013/12/16 01:40:26 UTC
Valid Container IDs
Does anyone know if Shindig is doing any validation of container IDs?
There are two problems I have noticed.
1. Container IDs cannot have colons ":" in them. This causes errors
in the authentication filter which I think is having trouble parsing
the parts of the security token because it is using a colon as a
separator. Having additional colons causes errors in the AuthFilter.
2. Container IDs need to be safe enough to be placed within a URL.
Specifically in DefaultServiceFetcher.retrieveServices we create a
security token which typically takes the form container:encodedToken.
If the container id has a space in it for example this will cause
Uri.parse to throw an exception. There may be other places like this
in the code, I have't looked.
For #1 I think we should be validating there are no colons in the IDs
and throwing an exception when a container with a colon is
contributed.
For #2 we could encode the ST part of the URL, but I am not sure if
that could cause problems with the ST itself, I don't think it should
though.
Anyone have any thoughts on this?
-Ryan
Re: Valid Container IDs
Posted by Ryan Baxter <rb...@gmail.com>.
Yeah, I have done a little testing with URL encoded strings as IDs and
that seems to work (as long as there are no colons).
On Mon, Dec 16, 2013 at 10:07 AM, Stanton Sievers <ss...@apache.org> wrote:
> I would be conservative and say only alphanumeric characters are allowed.
>
>
> On Mon, Dec 16, 2013 at 9:37 AM, Ryan Baxter <rb...@apache.org> wrote:
>
>> Yeah, imagine a service running on an application server that allows
>> developers building apps to add containers to their apps without
>> having to really know all the nitty gritty details of Shindig to do
>> so. They just implement a few interfaces and they are good to do.
>> The developer of the app would define the id of their own container,
>> since in some cases they need to know what that is. My code has no
>> way of knowing what they may use, so I have validate it to make sure
>> they are not going to run into problems, but I want to make sure I
>> have a firm grasp on what makes a valid container id.
>>
>> On Sun, Dec 15, 2013 at 8:02 PM, Stanton Sievers <ss...@apache.org>
>> wrote:
>> > I've never seen validation of container IDs. I've also never seen a
>> > container ID that wasn't a single alphanumeric word. It's not as if the
>> > container ID format is spec'd.
>> >
>> > Do you have use cases for more complex container IDs?
>> >
>> > - Stanton
>> > On Dec 15, 2013 7:40 PM, "Ryan Baxter" <rb...@apache.org> wrote:
>> >
>> >> Does anyone know if Shindig is doing any validation of container IDs?
>> >> There are two problems I have noticed.
>> >>
>> >> 1. Container IDs cannot have colons ":" in them. This causes errors
>> >> in the authentication filter which I think is having trouble parsing
>> >> the parts of the security token because it is using a colon as a
>> >> separator. Having additional colons causes errors in the AuthFilter.
>> >>
>> >> 2. Container IDs need to be safe enough to be placed within a URL.
>> >> Specifically in DefaultServiceFetcher.retrieveServices we create a
>> >> security token which typically takes the form container:encodedToken.
>> >> If the container id has a space in it for example this will cause
>> >> Uri.parse to throw an exception. There may be other places like this
>> >> in the code, I have't looked.
>> >>
>> >> For #1 I think we should be validating there are no colons in the IDs
>> >> and throwing an exception when a container with a colon is
>> >> contributed.
>> >>
>> >> For #2 we could encode the ST part of the URL, but I am not sure if
>> >> that could cause problems with the ST itself, I don't think it should
>> >> though.
>> >>
>> >> Anyone have any thoughts on this?
>> >>
>> >> -Ryan
>> >>
>>
Re: Valid Container IDs
Posted by Stanton Sievers <ss...@apache.org>.
I would be conservative and say only alphanumeric characters are allowed.
On Mon, Dec 16, 2013 at 9:37 AM, Ryan Baxter <rb...@apache.org> wrote:
> Yeah, imagine a service running on an application server that allows
> developers building apps to add containers to their apps without
> having to really know all the nitty gritty details of Shindig to do
> so. They just implement a few interfaces and they are good to do.
> The developer of the app would define the id of their own container,
> since in some cases they need to know what that is. My code has no
> way of knowing what they may use, so I have validate it to make sure
> they are not going to run into problems, but I want to make sure I
> have a firm grasp on what makes a valid container id.
>
> On Sun, Dec 15, 2013 at 8:02 PM, Stanton Sievers <ss...@apache.org>
> wrote:
> > I've never seen validation of container IDs. I've also never seen a
> > container ID that wasn't a single alphanumeric word. It's not as if the
> > container ID format is spec'd.
> >
> > Do you have use cases for more complex container IDs?
> >
> > - Stanton
> > On Dec 15, 2013 7:40 PM, "Ryan Baxter" <rb...@apache.org> wrote:
> >
> >> Does anyone know if Shindig is doing any validation of container IDs?
> >> There are two problems I have noticed.
> >>
> >> 1. Container IDs cannot have colons ":" in them. This causes errors
> >> in the authentication filter which I think is having trouble parsing
> >> the parts of the security token because it is using a colon as a
> >> separator. Having additional colons causes errors in the AuthFilter.
> >>
> >> 2. Container IDs need to be safe enough to be placed within a URL.
> >> Specifically in DefaultServiceFetcher.retrieveServices we create a
> >> security token which typically takes the form container:encodedToken.
> >> If the container id has a space in it for example this will cause
> >> Uri.parse to throw an exception. There may be other places like this
> >> in the code, I have't looked.
> >>
> >> For #1 I think we should be validating there are no colons in the IDs
> >> and throwing an exception when a container with a colon is
> >> contributed.
> >>
> >> For #2 we could encode the ST part of the URL, but I am not sure if
> >> that could cause problems with the ST itself, I don't think it should
> >> though.
> >>
> >> Anyone have any thoughts on this?
> >>
> >> -Ryan
> >>
>
Re: Valid Container IDs
Posted by Ryan Baxter <rb...@apache.org>.
Yeah, imagine a service running on an application server that allows
developers building apps to add containers to their apps without
having to really know all the nitty gritty details of Shindig to do
so. They just implement a few interfaces and they are good to do.
The developer of the app would define the id of their own container,
since in some cases they need to know what that is. My code has no
way of knowing what they may use, so I have validate it to make sure
they are not going to run into problems, but I want to make sure I
have a firm grasp on what makes a valid container id.
On Sun, Dec 15, 2013 at 8:02 PM, Stanton Sievers <ss...@apache.org> wrote:
> I've never seen validation of container IDs. I've also never seen a
> container ID that wasn't a single alphanumeric word. It's not as if the
> container ID format is spec'd.
>
> Do you have use cases for more complex container IDs?
>
> - Stanton
> On Dec 15, 2013 7:40 PM, "Ryan Baxter" <rb...@apache.org> wrote:
>
>> Does anyone know if Shindig is doing any validation of container IDs?
>> There are two problems I have noticed.
>>
>> 1. Container IDs cannot have colons ":" in them. This causes errors
>> in the authentication filter which I think is having trouble parsing
>> the parts of the security token because it is using a colon as a
>> separator. Having additional colons causes errors in the AuthFilter.
>>
>> 2. Container IDs need to be safe enough to be placed within a URL.
>> Specifically in DefaultServiceFetcher.retrieveServices we create a
>> security token which typically takes the form container:encodedToken.
>> If the container id has a space in it for example this will cause
>> Uri.parse to throw an exception. There may be other places like this
>> in the code, I have't looked.
>>
>> For #1 I think we should be validating there are no colons in the IDs
>> and throwing an exception when a container with a colon is
>> contributed.
>>
>> For #2 we could encode the ST part of the URL, but I am not sure if
>> that could cause problems with the ST itself, I don't think it should
>> though.
>>
>> Anyone have any thoughts on this?
>>
>> -Ryan
>>
Re: Valid Container IDs
Posted by Stanton Sievers <ss...@apache.org>.
I've never seen validation of container IDs. I've also never seen a
container ID that wasn't a single alphanumeric word. It's not as if the
container ID format is spec'd.
Do you have use cases for more complex container IDs?
- Stanton
On Dec 15, 2013 7:40 PM, "Ryan Baxter" <rb...@apache.org> wrote:
> Does anyone know if Shindig is doing any validation of container IDs?
> There are two problems I have noticed.
>
> 1. Container IDs cannot have colons ":" in them. This causes errors
> in the authentication filter which I think is having trouble parsing
> the parts of the security token because it is using a colon as a
> separator. Having additional colons causes errors in the AuthFilter.
>
> 2. Container IDs need to be safe enough to be placed within a URL.
> Specifically in DefaultServiceFetcher.retrieveServices we create a
> security token which typically takes the form container:encodedToken.
> If the container id has a space in it for example this will cause
> Uri.parse to throw an exception. There may be other places like this
> in the code, I have't looked.
>
> For #1 I think we should be validating there are no colons in the IDs
> and throwing an exception when a container with a colon is
> contributed.
>
> For #2 we could encode the ST part of the URL, but I am not sure if
> that could cause problems with the ST itself, I don't think it should
> though.
>
> Anyone have any thoughts on this?
>
> -Ryan
>