Re: [Bodington-developers] Abolute URLs - Bug or Bug Fix?

[Matthew B. <mat...@ou...>]

Jon Maber wrote:
> I've found a feature in 2.6 which for me is a bug but may be a bug fix 
> from someone else's point of view!

I saw it as a feature but I can see why you miss it.

> The login templates need to use absolute URLs at various points and 
> these are built in methods of Facility.  They used to use the server 
> name and the port numbers in bodington.properties but now they seem to 
> always use the server name found in the HTTP request and only use the 
> port numbers for the jump between http and https and back.  I don't 
> really understand what the advantages of all this are but I can see 
> several disadvantages, one of which is preventing me setting up 
> Bodington the way I want.

The primary advantage is that you no longer have to configure Bodington 
to get it running. This makes the quickstart just work. It also means if 
you decide to change the hostname that Bodington is deployed under you 
don't have to perform any reconfiguration other than to your servlet 
container.

The properties are still used by the EventMailer as it doesn't have a 
request object to pull the values from.

> 1) Many servers have multiple IP name aliases and this is not a problem 
> with Bodington when non-secure connections are made. However, when a 
> secure connection is made the server name really needs to match the IP 
> name in the server's digital certificate to prevent worrying error 
> messages about the security popping up in the user's browser.  This 
> seems to be broken - the correct port is used but not the correct IP name.

Why would you want to serve a Website up under several names?
I can see this may have been an argument 5 years ago when there where 
clients that didn't support HTTP/1.0 and so didn't work with virtual 
hosts but this is 2006. Hosting a website under multiple domains leaves 
you a little exposed to spoofing attacks as users no longer rely on 
looking at the URL bar to determine if they are at the correct site.

I can see that you may have your HTTPS connection served under a 
completly different hostname to your HTTP connections 
(http://www.server.name/ and https://secure.server.name/) but the old 
method didn't support this (it only allowed one hostname).

> 2) I'm using a single Apache installation to front end multiple 
> Tomcats.  This is done with virtual hosting in Apache, URL rewriting and 
> proxying.  So Apache accepts requests on port 80 and uses the server 
> name in the request to identify which tomcat installation to use.  Each 
> Tomcat listens on its own network ports on the localhost device only and 
> Apache operates like a proxy - the URL is transformed by mapping the 
> server name to localhost and the port number corresponding to the right 
> Tomcat installation. Apache fetches the page and sends it to the client.

I can see that this is a valid use of the old setup and hadn't though of it.

It should be reasonably easy to support using the bodington.properties 
if they are set and if not falling back the request properties.

Have you considered using AJP rather than mod_proxy which will preserve 
the orginal URLs (I believe) so you don't hit this problem.

http://tomcat.apache.org/tomcat-5.5-doc/connectors.html

> This is now broken by Bodington - you can log in O.K. (because tomcat 
> and Apache are on the same server) but when you follow the link to the 
> originally requested URL it's on the wrong port because it is 
> constructed from the request headers formed by the proxy instead of from 
> bodington.properties.  E.g. the user asks for 
> http://myserver.com/bodington/site/ but Apache connects to tomcat using 
> http://myserver.com:8080/bodington/site/ so after logging the later link 
> is present on the page when it should be the former.
> 
> So, is this a bug or is it a bug fix?

It was previously an undocumented feature ;-)

-- 
  -- Matthew Buckett, VLE Developer
  -- Learning Technologies Group, Oxford University Computing Services
  -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/