Wookie Profixy feature

[Jean-Noël Colin <je...@fundp.ac.be>]

Hi Scott,

To overcome the same-origin limitation, a widget has to proxify urls it wants to access so that they are served by the Wookie server. 

From what we saw, proxify 'simply' calls the Wookie Proxy servlet with the target url as parameter. Wookie than handles the connection with the server and returns the content. 

What about cookies? If the remote url I want to reach relies on cookie, those won't be sent, and thus, the remote service won't work properly. It is by design or by default that this is not handled? 

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?

Thanks for sharing your views on this

Cheers

Jean-Noël

Re: Wookie Profixy feature

[Scott Wilson <sc...@gmail.com>]

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<je...@fundp.ac.be>  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

Re: Wookie Profixy feature

[Hoang Minh Tien <ti...@gmail.com>]

On 28/10/11 17:11, Ross Gardler wrote:
> On 28 October 2011 14:55, Jean-Noël Colin<je...@fundp.ac.be>  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.

Re: Wookie Profixy feature

[Ross Gardler <rg...@opendirective.com>]

On 28 October 2011 14:55, Jean-Noël Colin <je...@fundp.ac.be> wrote:
> To overcome the same-origin limitation, a widget has to proxify urls it wants to access so that they are served by the Wookie server.
>
> From what we saw, proxify 'simply' calls the Wookie Proxy servlet with the target url as parameter. Wookie than handles the connection with the server and returns the content.
>
> What about cookies? If the remote url I want to reach relies on cookie, those won't be sent, and thus, the remote service won't work properly. It is by design or by default that this is not handled?
>

This is an issue I bumped up against recently and reported at
https://issues.apache.org/jira/browse/WOOKIE-251

I've not had the time to think of a solution to this problem yet,
suggestions are welcome.

> 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