On 29 Oct 2011, at 00:13, Hoang Minh Tien wrote: > On 28/10/11 17:11, Ross Gardler wrote: >> On 28 October 2011 14:55, Jean-Noël Colin<[email protected]> >> wrote: >> Another issue with this approach is that if in the reply from the remote >> service there are links, those won't be proxified, thus when I click on a >> button, it will invoke directly the remote site, without going through >> wookie, Aren't we facing the same-origin limitation? >> >> I'm not sure I understand the problem here. Can you give a concrete >> example of where same-origin would be a problem in this case. >> >> Ross > Sorry for interrupting your discussion, I think one example could be: I build > a widget that displays my gmail messages. When loading for the 1st time, the > widget instance proxify the URL to google authentication server (e.g: > https://accounts.google.com) the login page then returned and displayed on > widget, all the elements in this page refer directly to google, so even when > I put the correct username and password and then click on the link "login", > the iframe still be empty because of xxs protection, isn't it ? Could we > overcome the problem if the link "login" on the page is proxified ? Thanks. > Tien.
The "proxify" method is provided as a workaround for widgets that need to access services and feeds via AJAX from server/browser combinations that don't support CORS. Its not really intended as a way of inserting complete external websites into widgets. To be honest I'm quite glad this doesn't work, as it would make it into a tempting phishing mechanism. If you do need access to pages at other origins, such as login screens, I think its best to launch it in a new window with that origin rather than to try to spoof it by injecting the content into the widget origin using Proxify. -S
