[Authentication] Problem: Multiple sessions per application

[Michael Leupold]

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
>
> stuff
>
> > 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.

Regards,
Michael