Tying a session to a domain

[abeverley]

Hi,

I'd like to be able to tie a session to the domain it originated from. E.g. if a user accesses an app using domain1.com (subsequently generating a session for that site), and then uses domain2.com to access the same site but using the cookie from domain1.com, I'd like that to fail.

The reason is that I am hosting multiple sites at the same app, and would like to prevent "strange" behaviour that results in the above (e.g. a user from the wrong site is returned when using Plugin::Auth::Extensible)

The best way I can see to do this would be to add an additional domain parameter to _flush and _retrieve in Dancer2::Core::Role::SessionFactory, and then (optionally) set and check the domain when interacting with sessions.

I've got most of the above working as a proof of concept, but it's occurred to me that it's quite a big change. So, I'd just like to request some feedback, before I spend any more time on this.

Thanks,

Andy

[abeverley]

This is actually worse than I thought. With the above and DPAE, it's possible for a user to authenticate with one site, and then use the cookie from that site to access the second site, even if he has no credentials in the second site (although it does need the username to be the same).

I could patch DPAE, but that would be a hack; I think the correct place would be the next level up in Dancer itself.

Thanks,

Andy

[abeverley]

Okay, I've got a workaround for the time being (see below), but I still think this would be a nice feature.

hook 'engine.session.after_retrieve' => sub {
    my $session = shift;
    my $realm   = $session->data->{logged_in_user_realm};
    my $domain  = request->base->host;
    unless ($realm eq $domain)
    {
        warning __"Attempt to cross domain authenticate. Logging out.";
        undef $session->data->{logged_in_user};
    }
};

[rleir]

I suggest using JWT tokens. Actually, use them for all secure sites! IMHO

[szabgab]

I just tried JWT and so far could not make it work ambs/Dancer2-Plugin-JWT#2