Re: auth-source tokens

[Michael Albinus <michael.albinus@gmx.de>]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Fri, 29 Oct 2010 10:04:59 +0200 Michael Albinus <michael.albinus@gmx.de> wrote: 
>
>>> A string value is matched as a regex for the
>>> file (netrc) backend and literally by the Secrets API.  A symbol
>>> is matched as its string value.  All the SPEC values can be
>>> single values or lists.
>
> MA> Hmm, maybe we shall extend secrets.el to support also regexp search?
>
> It would be nice to make the interface consistent.

OK. I'll check next days whether secrets.el can be extended this
way. The Secrets API doesn't support it, it checks the attribute values
"... via case-sensitive string equality". That means all token must be
retrieved using only attribute matches which are *not* a regex. From the
resulting tokens those must be removed, whose attributes with regex do
not match.

I still have a comment:

> (defun auth-source-search (&rest spec)
>   "Search or modify authentication backends according to SPEC.
>
> :create t means to create a token if possible.  When it is
> 'rewrite-existing, any matching existing token will be copied
> into the new token and deleted.  This defaults to nil and will
> generate an error if used with :max greater than 1.  Any
> specified parameters except :max will be used in the new token,
> so if you searched for :host X you would create a token with that
> parameter.  When multiple parameters are specified in the search,
> the last one is used, so :host (X Y Z) would create a token for
> host Z.  This can fail if the search was not specific enough to
> create a new token (it's up to the backend to decide that).

How do you handle attributes which have a regex as value in SPEC? They
shouldn't be created with that value.

Best regards, Michael.