[Fusionforge-general] Sessions and URLs redirections... aka "logout doesn't work"

Vincent Caron vcaron at bearstech.com
Tue Feb 8 16:46:26 CET 2011


On Tue, 2011-02-08 at 15:08 +0100, Olivier Berger wrote:
> 
> OK, my guess is that the session mechanism is storing the session
> according to 192.168.122.90 (the URL of the login.php invocation), but
> logging out from forge.local doesn't resolve the IP, only removing
> sessions associated to 'forge.local'...
> 
> Bug, feature ?

  I think it's mostly an adminsys issue.

  When a web server is properly configured, it will make sure that only
*one* DNS name will map to a given application - that's the "canonical"
name (eg: http://fusionfore.org/). It should redirect all attempts to
reach the application via similar {sub}domains early, at the HTTP level,
without the application noticing it, in Apache-speak:

  <VirtualHost>
    # The www. prefix is sooo web 1.0, redirect people to 2.0 world
    ServerName www.fusionforge.org
    Redirect / http://fusionforge.org/
  </VirtualHost>

  This way the application *and* the client does not have to live with
different URLs wich has implications for:

  - cookies, especially if they're not tied to wildcard subdomains (eg:
Domain=.fusionforge.org); so many app in the wild have mysterious
"ghost" session problems which comes from the fact that one application
might be mapped by several URLs...

  - password wallets in browsers, which are easily confused

  - SSL certs if they're note wildcards one...


  Now in a perfect world, the application would be sure that the
adminsys did his job properly, and would simply emit redirects using
the hostname of incoming requests: it would be always the same, the
canonical one. It would not be needed to define a 'web_host' param.
But...

  - This is a real world, the application can make up for the adminsys
lazyness and handle this "redirect to the canical host"; but they also
often do it wrong, they handle any incoming requests for any hostname,
*then* redirect. They should have a very early logic, as soon as
configuration is parsed, and refuse to handle non-canonical URLs and
first redirect them, without setting any cookie (which is a bit
non-trivial with PHP). Eg: "Nice try login in via
http://www.fusionforge.org/account/login.php, but please try again at
http://fusionforge.org/account/login.php". Obviously that means
rejecting POSTs to non-canonical URLs, but if your application generate
forms which POST in the non-canonical domain it's broken in the first
place.

  - Out of the HTTP context, eg. in command line mode, there is no
hostname. This is the main reason why we want to define a canonical
hostname in the web app configuration. IMHO the only one.

  Sometimes the web server and web app sloppiness don't overlap and it
"just works" :). Most of the time it exhibits "strange" and
painful-to-trace behaviours like the one you just encountered.


> Ain't there some security implication here ? 

  I don't think so, unless you're on a mutualized host you don't
control, and some "hostname stealing" could occur.





More information about the Fusionforge-general mailing list