From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/74077 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.gnus.general Subject: Re: auth-source tokens Date: Sun, 14 Nov 2010 18:24:50 +0100 Message-ID: <87pqu795st.fsf@gmx.de> References: <87d3qylr29.fsf@marauder.physik.uni-ulm.de> <87fwvu5ele.fsf_-_@lifelogs.com> <87wrp4yjtk.fsf@lifelogs.com> <87eiarj0eu.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1289755601 12071 80.91.229.12 (14 Nov 2010 17:26:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 14 Nov 2010 17:26:41 +0000 (UTC) Cc: ding@gnus.org, tramp-devel@gnu.org To: Ted Zlatanov Original-X-From: ding-owner+M22445@lists.math.uh.edu Sun Nov 14 18:26:37 2010 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PHgLG-0004Lu-PL for ding-account@gmane.org; Sun, 14 Nov 2010 18:26:15 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1PHgKg-000694-Sl; Sun, 14 Nov 2010 11:25:38 -0600 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1PHgKf-00068v-Re for ding@lists.math.uh.edu; Sun, 14 Nov 2010 11:25:37 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1PHgKS-0002TP-Tt for ding@lists.math.uh.edu; Sun, 14 Nov 2010 11:25:37 -0600 Original-Received: from mailout-de.gmx.net ([213.165.64.22] helo=mail.gmx.net) by quimby.gnus.org with smtp (Exim 3.36 #1 (Debian)) id 1PHgKS-0007cL-00 for ; Sun, 14 Nov 2010 18:25:24 +0100 Original-Received: (qmail invoked by alias); 14 Nov 2010 17:24:53 -0000 Original-Received: from p4FC19568.dip0.t-ipconnect.de (EHLO detlef.gmx.de) [79.193.149.104] by mail.gmx.net (mp022) with SMTP; 14 Nov 2010 18:24:53 +0100 X-Authenticated: #3708877 X-Provags-ID: V01U2FsdGVkX1/msSAOSLLmdS4thBQTWCyY93nG+ht8+LKms9IMcy lxrC26JYp85SJA In-Reply-To: <87eiarj0eu.fsf@lifelogs.com> (Ted Zlatanov's message of "Thu, 11 Nov 2010 10:22:01 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:74077 Archived-At: Ted Zlatanov writes: > On Fri, 29 Oct 2010 10:04:59 +0200 Michael Albinus 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.