Setting up forge tokens using the MacOS keychain auth-source backend
Closed this issue · 15 comments
I'm using MacOS keychain as auth-source backend. It works well with ghub for the github forge. However I couldn't make it work for gitlab forges:
ghub--token: Required Gitlab token ("user^forge" for "gitlab.com/api/v4") does not exist.
Tracking down the issue, it looks like it wouldn't work with all forges having an API url containing slashes (basically all supported forges except github).
The command below finds the entry in MacOS keychain:
(auth-source-search :host "api.github.com")
But this one returns nothing (although it exists, I created it):
(auth-source-search :host "gitlab.com/api/v4")
Looking at the MacOS keychain backend code, this is explained by :host parsing the server attribute in the corresponding keychain entry, which only contains gitlab.com.
This problem happens when creating a new Keychain item with Keychain Access app.
Fortunately, the server attribute is not modified when creating the item using the command line:
security add-internet-password -a "user^forge" -r "htps" -s "gitlab.com/api/v4"
I'm sharing this here and hope someone else will find this useful. It took me a while to figure this out!
Thanks!
@tarsius maybe put this magic command at this page? https://magit.vc/manual/ghub/Storing-a-Token.html#Storing-a-Token
Would the following correctly summarize this advice?
If you use the MacOS Keychain auth-source backend, then do not use the
Keychain Access app to store the token because that silently changes a
host like "gitlab.com/api/v4" to just "gitlab.com". Instead run a
command like:
#+BEGIN_SRC example
security add-internet-password -a "ziggy^forge" \
-r "https" -s "gitlab.com/api/v4"
#+END_SRC
@tarsius a few remarks.
- Maybe add
api.github.comas example? - protocol aka
-rshould behtpsotherwise it complainsError: four-character types must be exactly 4 characters long..
Everything another is quite clear. Thanks!
- If I understood @benbovy correctly, then
api.github.comis stored as expected. Are you observing something else? - Yikes.
@tarsius I have the same issue with github. It hadn't access to github token until I added it via security add-internet-password ....
Please check what the gui substituted for api.github.com, github.com I assume.
@tarsius I've used a command:
security add-internet-password -a 'catap^forge' -r 'htps' -s "api.github.com"
until I run it, I have the same issue but for github.
Okay, but could you please also provide an answer that takes my question/instruction literally? Let me rephrase it a bit:
Please check what the gui substituted for api.github.com. I assume that it replaces that with github.com. Is that so or not? If not, then what is it replaced with instead?
I would like to be sure about this in order to avoid making false claims in the documentation.
@tarsius domain should be api.github.com at least on macOS when password is kept inside system's keychain.
The current draft is:
If you use the MacOS Keychain auth-source backend, then do not use the
Keychain Access app to store the token because that silently changes a
value like "gitlab.com/api/v4" to just "gitlab.com", and a host like
"api.github.com" to a value that is unknown to me because despite
several attempts I could not get the person who reported that the
value was modified to disclose what incorrect value the correct value
was replaced with. Instead run a command like:
#+BEGIN_SRC example
security add-internet-password -a "ziggy^forge" \
-r "htps" -s "gitlab.com/api/v4"
#+END_SRC
a command
security add-internet-password -a 'catap^forge' -r 'htps' -s "api.github.com"
produced record inside keychanin like this:
which works very well.
So, I just do not understand that you would like to change here.
To paraphrase the initial report was this "Using the Keychain Access app results in an invalid entry. This can be fixed by using the security add-internet-password ... command instead."
When you then said
Maybe add api.github.com as example?
I assumed that you wanted me to do this because the Keychain Access app is also failing to store that value. But I realize now that this most like is not the reason why you wanted me to add a second example, this one for Github. Instead your reasoning appears to be "if you add an example for Gitlab, then you should also add an example for Github".
But that misunderstands why I am adding the Gitlab "example". Generally speaking documenting how to use the MacOS keychain as auth-source backend is beyond the scope of this manual. The same applies to all other alternative backends.
The only reason why I am adding this example is because that backend allegedly has a fatal bug and I want to save affected users the time needed to figure out that issue, by informing them about the issue and by providing simple instructions on how to fix it.
This is not necessary for Github because here using the GUI works just fine. I though you were telling me that Github was infact affected to, but that turned out to not be the case.
(I assume that /api/v4 is stripped because of the /. A hostname does not contain any /, so the GUI "helpfully" strips everything after the first /. api.github.com does not contain any /, which is why I found it very surprising when you appeared to claim that that string had a similar issue.)