[Authentication] Aliases

[Michael Leupold]

Am Samstag, 12. Dezember 2009 17:13:32 schrieb Stef Walter:
> Michael Leupold wrote:
> > Am Freitag, 11. Dezember 2009 22:59:04 schrieb Stef Walter:
> >> Attached is a patch which I'm proposing to handle stuff like the
> >> 'default' collection or the 'network' collection proposed by Guillaume.
> >>
> >> The collection aliases are present under:
> >>
> >> /org/freedesktop/secrets/aliases/xxxx
> >>
> >> So the default and network collections would be usable via the object
> >> path, in addition to their normal object paths:
> >>
> >> /org/freedesktop/secrets/aliases/default
> >> /org/freedesktop/secrets/aliases/network
> >>
> >> To manage the aliases, two new methods are added to the Service
> >> interface: ReadAlias() and SetAlias(). BTW, These are not properties on
> >> Collection because a collection can be have multiple aliases pointing to
> >>  it.
> >>
> >> This is somewhat implemented in gnome-keyring's dbus-api branch, but
> >> only the 'default' alias is implemented for now.
> >
> > I'd prefer to handle aliases more in the manner of hardlinks implementing
> > the Collection interface as well. Like that clients could save 1 call per
> > operation getting the aliased collection (alias may change at any time).
> 
> I assume you mean symlinks. Either way, yes, that's the case... Unless
> I'm misunderstanding you. Please see above, where I noted "in addition
> to their normal object paths".
> 
> The alias paths would act like a full collection implementing the
> Collection interface and have items under them etc...
> 
> The ReadAlias() and SetAlias() methods are for more for management
> applications to be able to tell what an alias points to. In the symlink
> metaphor, these methods equate roughly with the readlink() and symlink()
> libc calls.

My mistake then. I read what you wrote but got confused by the management 
calls wondering if ReadAlias() was meant to be called before accessing the 
aliased wallet. Of course the way you describe it made sense.

> > If we do it like that we'd have to decide if they signal open/close as
> > well (and I'd say they should).
> >
> > What do you think?
> 
> My initial inclination is not to have signals be emitted from the aliases.
> 
>  * This would significantly complicate service implementations.
>  * In addition I think that clients desiring signals are doing
>    password management, and should be aware of what an alias
>    points to.
>  * Two signals would be sent out for one collection or item
>    modification that happened. So these would need to be filtered
>    out by interested clients.
> 
> Does that make sense? Or did I not understand your reasons.

Well, for a start I confused the secrets and the wallet API for a moment (the 
latter supplying open/close signals), sorry for that. And I agree that a 
password management application should be aware of aliases.

But won't the signals be advertised on the bus anyway if aliases implement the 
Collection interface? That seems to imply that they are there but serve no 
use. Don't get me wrong, you convinced be that they are not needed - but can 
they be hidden?

Regards,
Michael