Sorry for the re-post, but from looking at the mail archive, it seems to me that my question got attached to the wrong thread. Here is the original post:
------------------------------------------------------------------------ ------------------------------------------------------------------------ --------------------------------------- Hello, We are having trouble getting gadgets.rpc - based remoting to work in scenarios that involve OAuth and Single Sign-on. I wonder if I can get any help finding a solution here. We are developing an enterprise application portal using Shindig as a gadget renderer. The portal serves as a single entry point, so that the user can login once, and then work with gadgets representing data from multiple applications. We are using a company standard single sign-on solution, which requires SSO tokens to be sent to the application in a form. The workflow is: 1. A lightweight, HTML -style gadget loads and posts a request (through makeRequest) to Shindig-based Portal server to build OAuth tokens. 2. Once the portal server receives the request, it builds the OAuth tokens and posts them to the service provider component. 3. The service provider verifies the tokens and replies with a form containing SSO tokens. 4. The form is sent back to the lightweight gadget, which submits the form to the appropriate application. 5. As a result, the entire contents of the gadget-hosting iframe is completely replaced with an application page (JSP or ASP.NET) containing actual data from the application the user wants to work with. This page establishes a session with its application, and the user is ready to interact with the application directly. As part of the workflow, the gadget must be able to communicate with the portal page (for example, to display a popup window in the context of the page). The obvious choice here would be gadgets.rpc, which takes care of the involved cross-domain issues in a browser-independent way (we support IE6 and up, Firefox 3. and Safari). However, in the scenario explained above, the iframe content is no longer rendered by Shindig, which results in gadget-to-container communication failing (container-to-gadget still works). While playing with both legacy (ifpc) and windows.postMessage communications, we traced the ifpc failure to the way target frame is determined in rpc_relay.html; this failure results in a cross-domain security exception. It's not yet clear what is causing the HTML5 channel to fail in gadgets.rpc. As a quick workaround, I built a channel for gadget-to-container communications using an invisible iFrame technique (the lowest common denominator, because we have to support browsers that are not HTML5-compliant). But it seems wrong that I have to build a workaround rather than simply use a channel that is part of the Gadget specification (gadgets.rpc). So the question is: Is gadgets.rpc broken? After all, its purpose is to facilitate *cross-domain* communications according to the Gadget spec; the spec doesn't impose any limitations on what its endpoints may be. Any suggestions regarding how to make this work? Any ideas are appreciated! Thanks in advance! Ilya Shtein _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________
