[Seaside] Re: Authentication task and https
BSchwab at anest.ufl.edu
Fri Oct 17 22:38:32 UTC 2008
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:
| userComponent |
user := SeasideUserAuthentication new.
userComponent := SeasideUserAuthenticationComponent new
[ user authenticate ] whileFalse:[
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
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
Life starts out with https, but with inactivity, (I assume) on session
timeout, the browser gets bounced back to
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?
From: Julian Fitzell <jfitzell <at> gmail.com>
Subject: Re: Authentication task and https
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
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?
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
More information about the seaside