[Seaside] Re: Authentication task and https

Bill Schwab BSchwab at anest.ufl.edu
Fri Oct 17 22:38:32 UTC 2008


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



More information about the seaside mailing list