I would be conservative and say only alphanumeric characters are allowed.
On Mon, Dec 16, 2013 at 9:37 AM, Ryan Baxter <[email protected]> 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 <[email protected]> > 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" <[email protected]> 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 > >> >
