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 <[email protected]> wrote: > 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 >> >> >>
