[Authentication] Problem: Multiple sessions per application
lemma at confuego.org
Wed Aug 19 01:55:07 PDT 2009
Am Mittwoch, 19. August 2009 06:07:22 schrieb Stef Walter:
> Michael Leupold wrote:
> > I'm perfectly fine with that. But I guess then the locking/unlocking
> > should be moved to session as well (so it can be associated with a
> > session), specifically:
> > - Service.BeginAuthenticate
> > - Service.CompleteAuthenticate
> > - Service.Authenticated
> I think the unlocking stuff is envisioned as per application (or DBus
> peer rather), not per session. Especially if multiple sessions are
> present for a single application.
Should be alright. After all multiple-sessions per client using one DBus
connection are just a corner-case. If the client wants to implement it
differently it would just have to either open multiple connections or use a
central mechanism of accessing the session as stated before.
I just thought I'd bring it up so we can get clear on it.
> > If that stays in Service I don't see a way to keep track of what's
> > unlocked per session.
> FWIW, an client application should never try and be smart and keep track
> of what is unlocked. Every time it does a search, it should be ready for
> locked items/collections. This is because at any point in time that were
> unlocked. A service implementation could do this (and in many cases
> should do this) on events like:
> * The user via a UI of some sort.
> * Hibernate of sleeping of a laptop.
> * An idle timeout.
> * Locking the desktop.
> Or am I missing something?
No, that's alright.
More information about the Authentication