[Seaside] Re: Authentication task and https

[Bill Schwab]

Julian Fitzell
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Julian,

What scares me is that it does make some sense :)  Not that I really
understand it, but from "the" book (too lazy to look up the title), some
of it sounds familiar.  It sure makes more sense than the proxy/location
directives that mention only the one protocol and yet somehow seem to
rewrite the URLs.

I will be happy to help sort it out.  The first thing that comes to mind
is that despite many different sources stating how easy it is to proxy
Seaside with Apache, it is in fact not all that easy.  Given the nature
of Apache, I doubt it can ever be made trivial, but we should be able to
make it less daunting.  I have the beginnings of something that can
sniff around for Seaside apps and propose parts of configuration files. 
I have avoided rewrites on advice from Pinesoft, but we could "easily"
support either approach.

Bill





==============================
Julian Fitzell jfitzell at gmail.com
Thu Oct 23 07:07:05 UTC 2008

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




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