[haiku-web] Re: Authentication with Drupal
- From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
- To: haiku-web@xxxxxxxxxxxxx
- Date: Wed, 25 Nov 2009 18:18:18 +0100
On 2009-11-25 at 15:51:30 [+0100], Niels Reedijk <niels.reedijk@xxxxxxxxx>
wrote:
> Hi Oliver,
>
> 2009/11/25 Oliver Tappe <zooey@xxxxxxxxxxxxxxx>:
> > - According to a discussion on drupal.org, the securesite module does not
> > yet
> > allow to specify which pages it protects, so it seems that *all* pages would
> > require authentication. We'd have to check, but if this really is the case,
> > then method 1 is no solution, I guess.
> > If we would be able to require authentication just for restricted pages, the
> > new method of authentication would require all users to change their
> > password.
>
> Are you sure about that?
As I tried to indicate in my mail, no, I'm *not* sure ;-)
> What happens for example with Trac is that
> the code behind the /login URL checks for a parameter that Apache
> passes if authentication is succesfull. It then sets a session cookie
> so that the user is logged in. It does not require checking the login
> credentials for every request.
Hm, if that is indeed the case it means that a man-in-the-middle can still
hijack trac sessions - oops! I will check if hijacking one of our trac sessions
(by reusing the cookie in another browser) is possible.
> I looked at the securesite documentation and its code, and it seems to
> me that if we set up securesite to for example block the /user part of
> our installation, it will then force authentication for that URL, and
> if users go there (like they go there now to log in), they will get a
> session cookie and they can access the rest of the site without any
> problems.
>
> The only thing is that registration is also hidden behind /user, so
> maybe we should try to make an alias like /login and let securesite
> 'catch' that URL.
Sounds ok, except for the same potential session-hijacking problem.
cheers,
Oliver
-----------------------------------------------------------------------
haiku-web@xxxxxxxxxxxxx - Haiku Web & Developer Support Discussion List
Other related posts:
