[Seaside] Re: Authentication task and https

[Julian Fitzell]

Hi Bill,

I took a quick look at the code. I'm pretty sure the problem is likely
to be in WARegistry>>handleExpiredRequest: because it isn't using
#baseUrl anywhere while generating the code. It's trying to take the
everything from the incoming request URL but that might not work,
particularly if you're behind Apache.

This code is a mess... it's cleaned up quite a bit in 2.9 but still
has calls to #takeServerParametersFromRequest: which I'm a little
unsure of.

So... I would try either overriding that method on WAApplication or
modifying it directly. I would start by using "self baseUrl" instead
of "WAUrl new" but you might then have to strip off the path or
something because the whole path from the incoming request then gets
added. I'm also not even sure if *that* part makes sense when the
request is being rewritten. It seems like you'd really need to keep
the path from #baseUrl (which takes into account the config settings),
subtract #basePath (the actual path on the squeak image) from the path
in the incoming request, and then apply what's left of the incoming
request's path to the redirection.

I hope that makes any kind of sense. It's muddling my head just
thinking about it so if it doesn't, I can try to explain again.
Hopefully you can sort it out with only a little bit of muddling and
let us know the answer... we should probably try to roll some kind of
a fix out for that at some point.

And yes, by "internal" and "external" I meant "the URL of the squeak
image" and the "URL visible outside Apache".

Julian

On Sat, Oct 18, 2008 at 12:38 AM, Bill Schwab <BSchwab at anest.ufl.edu> wrote:
> Julian,
>
> My goal is to keep things simple and safe.  Sending sensitive data in
> the clear is a big mistake; the less that changes between my testing and
> production environments, the better.  Between moving to a domain
> certificate and the ease of self-signing in transition and on test
> machines, I have decided to use SSL for everything for the forseeable
> future.  I will also default to requiring authentication, so I created a
> task in hope of doing the hard part once.  The best I could think to do
> is to have an abstract task that looks something like this:
>
>      go
>                | userComponent |
>        user := SeasideUserAuthentication new.
>        userComponent := SeasideUserAuthenticationComponent new
> user:user; yourself.
>
>        [ user authenticate ] whileFalse:[
>                self call:userComponent.
>                user authenticate
>                        ifTrue:[
>                                self session login:user.
>                                self call:self startingComponent.
>                        ].
>        ].
>
>        self session logout.
>
> where #startingComponent is defined for each subclass/application.
> There might be a completely pluggable solution to the problem, but it
> escaped me.
>
> A subclass is registered something like
>
>    application := self registerAsApplication: 'hal9000'.
>    application preferenceAt: #deploymentMode put: true.
>    application preferenceAt: #resourceBaseUrl put: '/'.
>    application preferenceAt: #serverPath put: '/'.
>    application preferenceAt: #serverPort put: 443.
>    application preferenceAt: #serverProtocol put: #https.
>
> Apache is configured to not even listen on 80, and I am happy to
> require a user to start with a URL such as
>
>  https://here.there.net/seaside/hal9000
>
>
> Life starts out with https, but with inactivity, (I assume) on session
> timeout, the browser gets bounced back to
>
>  http://here.there.net/seaside/hal9000
>
>
> If only rhetorically, why does it work on the first pass?  I am not
> sure what you mean by internal and external URLs.  So far, searches turn
> up hits, but not anything that tells me how to grab them.  Are you
> referring to outside and inside Comanche, or on either side of Apache?
>
> Thanks!
>
> Bill
>
>
>
>
>
> =============================
> From: Julian Fitzell <jfitzell <at> gmail.com>
> Subject: Re: Authentication task and https
> Newsgroups: gmane.comp.lang.smalltalk.squeak.seaside
> Date: 2008-10-17 18:17:20 GMT
>
> No, as you surmise, it's only a preference and only used by
> applications (all entry points in 2.9) and is therefore
> application-wide. It's basically supposed to represent the "external
> base url" of the application, when that is not the same as the base
> url of the application within the squeak image.
>
> If you're talking about wanting some part of your application to force
> the use of SSL then that doesn't help but I think in most cases (if
> you don't specify values for those parameters) it should just be
> generating URLs like "/seaside/foo", which will maintain the hostname,
> protocol, and port and should therefore keep using SSL until you
> manually send it to an HTTP URL. When the session expires, you'd get
> redirected back to the application entry point, which would be HTTP
> again.
>
> I think perhaps I don't quite understand what you're trying to
> accomplish. Maybe you could give a more concrete example with what the
> external and internal URLs are at various points?
>
> Julian
>
>
> Wilhelm K. Schwab, Ph.D.
> University of Florida
> Department of Anesthesiology
> PO Box 100254
> Gainesville, FL 32610-0254
>
> Email: bschwab at anest.ufl.edu
> Tel: (352) 273-6785
> FAX: (352) 392-7029
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>