(I’m not sure this ever posted yesterday… so pardon me if it comes through twice)
I’m looking into implementing container token refresh using the container.config_[osapi.container.ContainerConfig.GET_CONTAINER_TOKEN] mechanism. This function would then either call back to my application or to shindig to fetch a new token. Ideally I want to have the first updateContainerSecurityToken call start the refresh process. However if I do that and I want to go with the approach of having shindig provide the endpoint for generating the token (by adding an osapi rpc service) then I’d already need a valid token to make the call to shindig. If I provide the endpoint in my own application then I have to work out my own security scheme. And I still have concerns with the token being exposed via network traffic or introspection on the javascript. I guess that’s why they are short-lived. Has anyone else implemented a server-side solution? How did you handle securing the call (if at all)? Any suggestions welcome. UPDATE: It would be nice is there was someway to set allowUnauthenticated on a per method basis. I know even our listMethods call requires a token (which would be nice if it didn’t). Thanks, doug
