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 >>
