Hi Wouter They'd have to be logged into the site with the site's authentication mechanism to get the token injected. So we assume that if we are happy for them to access the site we are happy for them to have the token. Once they are logged in they can view the Security Token on the iframes' source anyway, or on the url of each RPC request made by the gadget, so I don't think we are any more insecure by virtue of doing this. Re. owner changing. We have a simple setup where this can't happen. The owner is always the viewer. I see your problem. But can you not just get a new token with an AJAX call? Pass the owner as a param, you know the viewer from your main site session - and construct and return a new token? Though owner here could be forged so it may be a bit more complex? hth Justin
> Date: Wed, 16 Feb 2011 12:33:02 +0100 > Subject: Re: Leverage AJAX driven website to social with Shindig > From: [email protected] > To: [email protected] > > Hi Justin, thanks for sharing your experience. > How did you handle changes in the security token? > For example, during the session, the viewer doesn't change, but the owner > can be different. For example, if you want to view the profile of user1, the > token will be different from if you want to view the profile of user2. > (Correct me if I'm wrong...) > Also, is this safe? Since a very evil hacker may just "steal" the security > token and use it as long as the token hasn't expired. > > Thanks again > Wouter > > On Wed, Feb 16, 2011 at 11:46 AM, Justin Wyllie > <[email protected]>wrote: > > > > > Hi > > We were just using the Security Token and not oAuth. > > We just copied the files that come with Shindig that do the encryption of > > the token to our web server (which is different from our Shindig server) and > > created a token with BasicSecurityToken::createFromValues using the same > > config params as in Shindig that is the same token_cipher_key and same > > expiry period as in the config etc in the code that built our container > > page and just put the SecurityToken into the page as a JS variable so it > > could be submitted in the non gadget AJAX calls to the Shindig server. You > > could do the same thing with AJAX of course. The only thing we had to be > > careful of was if the Security Token session ends before the web site > > session. > > If you are authenticating with oAuth I'm afraid I can't help. (The dev list > > people no doubt can). > > regards > > Justin Wyllie > > > > > > > > > Date: Wed, 16 Feb 2011 11:28:55 +0100 > > > Subject: Leverage AJAX driven website to social with Shindig > > > From: [email protected] > > > To: [email protected] > > > > > > Hi > > > > > > I'm building a website that is not primarly a social networking site, but > > I > > > want to enable the social and app stuff by using Shindig (which seems > > > perfeclty suited for that purpose). An odd thing about my website is that > > it > > > may never be refreshed completely, since this would interrupt the user's > > > activities and experience. Hence, I need to do everything with AJAX calls > > to > > > some server endpoint. Now, off course, since Shindig provides me with > > both > > > an RPC and REST server, I want to address the calls to the Shindig server > > > endpoints. I already managed to extend Shindig to pull information from > > it > > > that is specific for my website. The thing I'm stuck on now is the > > > following: > > > > > > I want to do RPC requests to the Shindig endpoint from my website using > > > JavaScript. The script is not running inside an app or something that was > > > rendered by Shindig. However, I need to provide owner, viewer, app, ... > > keys > > > to Shindig that are encrypted in a specific way. Hence my question: How > > can > > > I use Shindig in a safe way as the general RPC server to my website's > > > backend that can be queried from my front end (!= app)? > > > > > > Many many thanks for help! > > > >
