[Seaside] Avi, why did the semantics for #urlForAction: change?

Nevin Pratt nevin at bountifulbaby.com
Thu Nov 23 09:23:11 UTC 2006


Nevin Pratt wrote:
> Why did the semantics for #urlForAction: change?
>
> In Seaside 2.3, as flow advanced to the next Seaside page/component, I 
> could wrap that page easily for SSL using Stunnel thus:
>
>   url := html urlForAction: [self call: MySecureComponent new].
>   self session returnResponse: (WARedirectResponse location: 
> 'https://mylocalhostname', url).
>
> When the user's browser got this redirect, it would redirect to 
> "https" (port 443) instead of "http" (port 80), but would otherwise 
> use the complete session URL, and would connect right back to the same 
> machine.  Then, stunnel would be listening on port 443, do it's SSL 
> thing, and forward to port 80, where Seaside would be listening.
>
> In Seaside 2.6, at first there seemed to be just a minor change, and 
> the following code looked like it would do the same thing as above did 
> in 2.3:
>
>   url := html urlForAction: [self call: MySecureComponent new].
>   self session returnResponse: (WAResponse redirectTo: 
> 'https://mylocalhostname', url).
>
> But it doesn't work.
> There are multiple reasons why it no longer works, but one of those 
> reasons is that #urlForAction: now returns the fully qualified host 
> URL (including the leading 'http://') rather than just the path 
> (everything from '/seaside' on).
>
> Playing string games with the url seems to be pointless, too, because 
> it *looks* like if the session keys (everything from '/seaside' 
> onward) are reused, Seaside will insist that the url comes from the 
> same original source.
>
> In other words, I can change the "http" to an "https" in the redirect 
> string all I want, and Seaside will put it right back to an "http" 
> when the request comes back, if I am using session keys that were 
> originally generated from the "http" location.
>
> Hmm, come to think of it, maybe you've done something to eliminate 
> session hijacking, and your "fix" is causing this issue, too?
>
> In any case, it looks like Seaside/Comanche/stunnel is no longer 
> sufficient, and it is beginning to look like I'm going to need to use 
> Apache and mod_ssl with Seaside, instead of just using 
> Comanche/stunnel without Apache.
>
> And again, the reason I can no longer just use Seaside/Comanche with 
> stunnel (without Apache) is because I can no longer get Seaside to 
> redirect to the "https" location.  It just puts it right back to an 
> "http".  Or so it appears.
>
> Comments?
>
> Nevin
>

This issue looks to be related to the problem Ramon Leon posted about on 
4/28/06 11:01 AM (titled "[Seaside] SSL"), wherein he says:

   "All the generated url's are fully qualified, so though it'll respond 
to SSL, as soon as I click something I'm thrown back into standard http"

**********
And Avi responded thus:

Here's how I deal with this.  It's a bit hackish but it works.  In my 
:80 vhost, I have
ProxyVia Block

And then in the :443 vhost, I have
ProxyVia On

I can then check at the Seaside level whether the initial request was 
SSL or not simply by testing for the presence of the Via header, and 
generating URLs accordingly.

These are from my WASession subclass:

actionUrlForKey: aString
    | url |
    url := super actionUrlForKey: aString.
    self useSSL ifTrue: [url scheme: #https; port: 443].
    ^ url
    
useSSL
    ^ (currentRequest headers includesKey: 'via')

Avi
*********

That works when you are using Apache, but in my case I would like to 
only use Comanche, without Apache, and also use stunnel.

It appears that the problem is that all subsequent URL's are fully 
qualified in Seaside, and tied to the session keys.  So, if I reuse 
those keys, the subsequent URL's are generated for http.

I don't know if I'm making any sense.  It's time to go to bed.

Nevin


More information about the Seaside mailing list