Skip to Content.
Sympa Menu

shibboleth-dev - RE: The parameter formerly known as shireURL

Subject: Shibboleth Developers

List archive

RE: The parameter formerly known as shireURL


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Subject: RE: The parameter formerly known as shireURL
  • Date: Thu, 18 Aug 2005 01:14:59 -0400
  • Organization: The Ohio State University

> Although I could map the relative forms to use the RM-Context URL, this
will
> only work reliably if the resource request came in over SSL so I have a
> usable port number to work with.

Why wouldn't the port number just come from the getPort() method? I'm
missing something here, but I think I'm getting closer. The port shouldn't
be based on what ports the container *might* be listening on, but the port
used for the current request.

If I hit a resource on port 8443, the redirect should include a shire value
that points at port 8443 (in fact it must, since in general the cookie will
be private to that port). Same for any other port.

> If I had to guess an SSL port number, I would have to try 443 which is the
> wrong answer in the example configuration and is often the wrong answer in
> many Java servers (8443 being just as common a choice).

I can't imagine that being common in actual deployment, but that's
immaterial, I'm certainly not saying we should *guess* the port. I just
don't know what's happening internally here, I guess.

> So rather than take a chance on sending the Assertion to
> some other Web Server that is sitting on the default port, it seems safer
to
> strongly urge the fully qualified version in the documentation.

There's nothing wrong with that (and I certainly allow it). In practice,
it's not clear to me whether the hostname "expansion" Derek added to support
vhosting is really important since most of the time you don't want a single
set of resources to be made available simultaneously on all the vhosts. With
an absolute handler, the deployer is forced to create multiple <Application>
elements containing a distinct handlerURL for each vhost, but I would guess
in most cases the resources are different anyway, and calling them separate
applications might be a good thing.

I realize now this isn't what Tomcat does, but then I don't know if Tomcat's
model makes a lot of sense or not.

Anyway, supporting the relative syntax(es) should not be a priority if it
takes significant effort. It didn't in the old SP and reduced the number of
places the hostname had to appear in the file, which was the real purpose. I
suspect the Java SP will be installed somewhat like the IdP is now, and so
people can enter the hostname and we can plug it right in anyway.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page