From: <rsbecker@nexbridge.com>
To: "'Junio C Hamano'" <gitster@pobox.com>,
"'M Hickford via GitGitGadget'" <gitgitgadget@gmail.com>
Cc: <git@vger.kernel.org>, <sandals@crustytoothpaste.net>,
<derrickstolee@github.com>, <stolee@gmail.com>,
<Johannes.Schindelin@gmx.de>, <peff@peff.net>,
"'M Hickford'" <mirth.hickford@gmail.com>
Subject: RE: [PATCH] docs: discuss caching personal access tokens
Date: Fri, 10 Jan 2025 14:11:40 -0500 [thread overview]
Message-ID: <017f01db6393$7e3fe2e0$7abfa8a0$@nexbridge.com> (raw)
In-Reply-To: <xmqqwmf27cvv.fsf@gitster.g>
On January 10, 2025 1:17 PM, Junio C Hamano wrote:
>Subject: Re: [PATCH] docs: discuss caching personal access tokens
>
>"M Hickford via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> From: M Hickford <mirth.hickford@gmail.com>
>>
>> Describe problems storing personal access tokens in
>> git-credential-cache and suggest alternatives.
>
>> +PERSONAL ACCESS TOKENS
>> +----------------------
>> +
>> +Some remotes accept personal access tokens, which are randomly
>> +generated and hard to memorise. They typically have a lifetime of
>> +weeks or months.
>> +
>> +git-credential-cache is inherently unsuitable for persistent storage
>> +of personal access tokens. The credential will be forgotten after the
>> +cache timeout. Even if you configure a long timeout, credentials will
>> +be forgotten if the daemon dies.
>
>Very true.
>
>> +To avoid frequently regenerating personal access tokens, configure a
>> +credential helper with persistent storage.
>
>Like libsecret and osxkeychain, you mean? I am wondering if we want to be
a bit
>more helpful by being explicit. I think there is a section in a maual page
that has a
>list of known and often-used credential backends, so referring the readers
to that
>section may be helpful.
>
>> Alternatively, configure an
>> +OAuth credential helper to generate credentials automatically. See
>> +linkgit:gitcredentials[7].
>
>Indeed.
My solution for this is to write a custom credential manager that is PAT
aware. The one I built
does not support OAuth or OAuth2. This is non-trivial when dealing with a
CLI. Integrating
with something like MS Authenticator might be a reasonable option for some.
next prev parent reply other threads:[~2025-01-10 19:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-09 21:26 [PATCH] docs: discuss caching personal access tokens M Hickford via GitGitGadget
2025-01-10 18:16 ` Junio C Hamano
2025-01-10 19:11 ` rsbecker [this message]
2025-01-10 21:25 ` M Hickford
2025-01-10 22:54 ` [PATCH v2 0/2] " M Hickford via GitGitGadget
2025-01-10 22:54 ` [PATCH v2 1/2] docs: list popular credential helpers M Hickford via GitGitGadget
2025-01-10 22:54 ` [PATCH v2 2/2] docs: discuss caching personal access tokens M Hickford via GitGitGadget
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='017f01db6393$7e3fe2e0$7abfa8a0$@nexbridge.com' \
--to=rsbecker@nexbridge.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=derrickstolee@github.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=mirth.hickford@gmail.com \
--cc=peff@peff.net \
--cc=sandals@crustytoothpaste.net \
--cc=stolee@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).