usethis::create_github_token()9 Token de acceso personal para HTTPS
Cuando interactuamos con un servidor Git remoto, como GitHub, debemos incluir credenciales en la solicitud. Esto demuestra que somos un usuario específico de GitHub, al que se le permite hacer cualquier cosa que le pidamos.
Git puede comunicarse con un servidor remoto utilizando uno de dos protocolos, HTTPS o SSH, y los diferentes protocolos utilizan diferentes credenciales.
Aquí describimos la configuración de credenciales para el protocolo HTTPS, que es lo que recomendamos si no tiene ningún motivo importante para elegir SSH. Con HTTPS, usaremos un token de acceso personal (PAT). Dirígete al capítulo Capítulo 10 si realmente quieres configurar claves SSH.
Tenga en cuenta que la contraseña que utiliza para iniciar sesión en el sitio web de GitHub NO es una credencial aceptable cuando se habla con GitHub como servidor Git. Esto fue posible en el pasado (y puede que aún sea cierto para otros servidores Git), pero esos días quedaron atrás en GitHub. Puede obtener más información en la publicación de su blog Requisitos de autenticación de tokens para operaciones de Git.
Este es el error que verá si intenta hacer eso ahora:
remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead.
remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information.
fatal: Authentication failed for 'https://github.com/OWNER/REPO.git/'La recomendación de utilizar un token de acceso personal (PAT) es exactamente lo que cubrimos en este capítulo.
9.1 TL;DR
Esta es una descripción mínima de cómo obtener y almacenar un PAT. Esto podría ser todo lo que necesita cuando se esté configurando por primera vez. Siempre puedes volver más tarde y leer otras partes de este capítulo.
Vaya a https://github.com/settings/tokens y haga clic en “Generar token”.
O, desde R, ejecute:
Mire los ámbitos; Recomiendo encarecidamente seleccionar “repo”, “user” y “workflow”. Los alcances recomendados serán preseleccionados si utilizó create_github_token().
Haga click en “Generar token”.
CCopie el PAT generado a su portapapeles. O deje la ventana del navegador abierta y disponible por un momento, para que pueda volver a copiar el PAT.
Proporcione esta PAT la próxima vez que una operación de Git solicite su contraseña1.
Incluso podrías adelantarte a esto y almacenar el PAT explícitamente ahora mismo. En R, llame gitcreds::gitcreds_set() para recibir un mensaje donde puedes pegar tu PAT:
> gitcreds::gitcreds_set()Pegue el PAT en respuesta al diálogo en la consola:
? Enter password or token: ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-> Adding new credentials...
-> Removing credentials from cache...
-> Done.Debería poder trabajar con GitHub ahora. Si todavía estás realizando la configuración inicial, ahora es un buen momento para pasar a Conectarse a GitHub.
Continúe leyendo para obtener más información sobre:
9.2 HTTPS contra SSH
Encuentro que HTTPS es más fácil de hacer funcionar rápidamente y lo recomiendo encarecidamente cuando comienzas a trabajar con Git/GitHub. HTTPS es lo que recomienda GitHub, presumiblemente exactamente por las mismas razones. El argumento de la “facilidad de uso” a favor de HTTPS es especialmente cierto para los usuarios de Windows. Comencé con HTTPS, preferí SSH por un tiempo y volví a HTTPS. Lo principal que debe saber es que esta no es una decisión de todo o nada y es una decisión relativamente fácil de revisar más adelante.
Otra ventaja de HTTPS es que el PAT que configuraremos también se puede usar con la API REST de GitHub. Puede que eso no signifique nada para usted (todavía), pero hay muchos paquetes R que llaman a la API de GitHub en su nombre (devtools+usethis, remotes, pak, gh, etc.). Configurar su PAT mata dos pájaros de un tiro: esta credencial única se puede usar para autenticarse en GitHub como un servidor Git normal y para su API REST. Si se autentica a través de SSH para el trabajo “normal” de Git, aún tendrá que configurar un PAT para el trabajo que utiliza la API REST.
Un PAT configurada correctamente significa que todo esto “simplemente funcionará”:
- Operaciones HTTPS remotas a través de la línea de comandos de Git y, por tanto, a través de RStudio
- Operaciones HTTPS remotas a través del paquete gert R y, por lo tanto, usethis
- Operaciones de API de GitHub a través del paquete gh R y, por lo tanto, usethis
9.2.1 La URL determina el protocolo
Aunque sugiero que adoptes HTTPS como estilo de vida, es bueno saber que en realidad tienes un control muy granular sobre el protocolo. Está determinado por la URL utilizada para acceder a un repositorio remoto. No dudes en saltarte esta sección si eres nuevo en Git (mencionamos algunos conceptos y comandos que no tendrán mucho sentido hasta que hayas usado un poco Git).
Las URL remotas HTTPS se ven así https://github.com/<OWNER>/<REPO>.git.
Las URL remotas SSH se ven así git@github.com:<OWNER>/<REPO>.git.
Cuando ejecutas un comando como git push origin my-cool-feature-branch, Git busca la URL que has almacenado para el control remoto origin y usa el protocolo implícito en el formato de la URL. El protocolo es una decisión en el momento del juego.
Esto implica que:
- Está bien usar HTTPS para un control remoto en un repositorio y SSH para otro.
- Está bien usar HTTPS en un repositorio y SSH en otro.
- Está bien interactuar con un repositorio de GitHub mediante HTTPS desde una computadora y mediante SSH desde otra.
- Está bien adoptar HTTPS para trabajos nuevos, incluso si algunos de sus repositorios preexistentes usan SSH.
Sólo debes tener en cuenta que el uso mixto de HTTPS y SSH significa que tendrás que configurar ambos tipos de credenciales.
Cambiar un control remoto específico de HTTPS a SSH (y viceversa) es una operación sencilla con git remote set-url REMOTE_NAME DESIRED_URL:
~/rrr/happy-git-with-r % git remote -v
origin https://github.com/jennybc/happy-git-with-r.git (fetch)
origin https://github.com/jennybc/happy-git-with-r.git (push)
~/rrr/happy-git-with-r % git remote set-url origin git@github.com:jennybc/happy-git-with-r.git
~/rrr/happy-git-with-r % git remote -v
origin git@github.com:jennybc/happy-git-with-r.git (fetch)
origin git@github.com:jennybc/happy-git-with-r.git (push)
~/rrr/happy-git-with-r % git remote set-url origin https://github.com/jennybc/happy-git-with-r.gitPodemos hacer lo mismo desde R usando las funciones de usethis:
usethis::git_remotes()
#> $origin
#> [1] "https://github.com/jennybc/happy-git-with-r.git"
usethis::use_git_remote(
"origin",
"git@github.com:jennybc/happy-git-with-r.git",
overwrite = TRUE
)
usethis::git_remotes()
#> $origin
#> [1] "git@github.com:jennybc/happy-git-with-r.git"
usethis::use_git_remote(
"origin",
"https://github.com/jennybc/happy-git-with-r.git",
overwrite = TRUE
)9.3 Generar un token de acceso personal (PAT)
En github.com, suponiendo que haya iniciado sesión, puede administrar sus tokens de acceso personales desde https://github.com/settings/tokens, también accesible a través de Configuración > Configuración de desarrollador > Tokens de acceso personal. Puedes hacer clic en “Generar nuevo token” aquí o, quizás incluso mejor, puedes ejecutar en R el siguiente código usethis::create_github_token():
usethis::create_github_token()El usethis enfoque lo lleva a un formulario precargado donde hemos preseleccionado algunos alcances recomendados, que puede revisar y ajustar antes de hacer clic en “Generar token”. Al momento de escribir este artículo, los alcances recomendados por este uso son “repo”, “user”, “gist” y “workflow”.
Es una muy buena idea describir el propósito del token en el campo Note, porque algún día podría tener varios PAT. Recomendamos nombrar cada token según su caso de uso, como la computadora o el proyecto para el que lo está usando, por ejemplo. “personal-macbook-air” o “vm-for-project-xyz”. En el futuro, te encontrarás mirando esta lista de tokens, porque inevitablemente necesitarás volver a generar o eliminar uno de ellos. Haz que sea fácil descubrir con qué token has venido a jugar.
GitHub fomenta el uso de tokens perecederos, con un período de Caducidad predeterminado de 30 días. A menos que tenga una razón específica para luchar contra esto, le recomiendo aceptar este valor predeterminado. Supongo que la gente de seguridad de GitHub tiene buenas razones para su recomendación. Pero, por supuesto, puede ajustar el comportamiento de Vencimiento como mejor le parezca, incluido “Sin vencimiento”.
Una vez que esté satisfecho con la Note, Expiration y Scope del token, haga clic en “Generar token”.
No podrá volver a ver este token, así que no cierre ni salga de esta ventana del navegador hasta que almacene el PAT localmente. Copie el PAT al portapapeles, anticipando lo que haremos a continuación: activar un mensaje que nos permita almacenar el PAT en el almacén de credenciales de Git.
¡Trate este PAT como una contraseña! ¡Nunca conectes tu PAT a tu código! Una PAT siempre debe recuperarse implícitamente, por ejemplo, del almacén de credenciales de Git. Estamos a punto de ayudarle a almacenar el PAT en un lugar seguro, donde los paquetes de línea de comandos Git, RStudio y R puedan descubrirlo.
Si usa una aplicación de administración de contraseñas, como 1Password (¡muy recomendable!), es posible que desee agregar también esta PAT (y su Nota) a la entrada de GitHub, donde ya está almacenando su nombre de usuario y contraseña. Almacenar su PAT en el almacén de credenciales de Git es una conveniencia semipersistente, algo así como un caché del navegador o “recordarme” en un sitio web2 y es posible que necesite volver a ingresar su PAT en el futuro. Podrías decidir aceptar la impermanencia de tu PAT y, si de alguna manera se pierde, simplemente regenerarás el PAT y lo restaurarás. Si acepta el período de vencimiento predeterminado de 30 días, este es un flujo de trabajo que utilizará con frecuencia de todos modos. Pero si crea tokens duraderos o quiere jugar con las funciones para configurar o borrar sus credenciales de Git, puede resultar útil tener su propio registro de su PAT en un lugar seguro, como 1Password.
9.4 Guarde su PAT
En este punto, asumo que generó una PAT y la tiene disponible, en una o ambas de estas maneras:
- En un sistema seguro y a largo plazo para almacenar secretos, como 1Password
- Durante los próximos minutos, en una ventana del navegador o en el portapapeles
Hay un par de formas de ingresar su PAT en la tienda de credenciales de Git:
- Llame a una función de R para almacenar (o actualizar) explícitamente sus credenciales.
- Haga algo en la línea de comando de Git o RStudio que desencadene un desafío de credenciales.
9.4.1 Llame a una función R para almacenar sus credenciales
Hay dos paquetes de R para acceder al almacén de credenciales de Git:
Es probable que estos paquetes eventualmente se combinen en uno solo e, incluso ahora, son en gran medida interoperables. No es necesario que sigas las instrucciones de ambos paquetes: ¡elige uno!
9.4.1.1 Paquete gitcreds
Si no tiene gitcreds instalado, instálelo a través de install.packages("gitcreds"). Si ha instalado usethis, ya tendrá gitcreds, porque usethis usa gh y gh usa gitcreds.
Llame a gitcreds::gitcreds_set(). Si aún no tiene una PAT almacenada, se le pedirá que la ingrese. ¡Pegar!
> gitcreds::gitcreds_set()
? Enter password or token: ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-> Adding new credentials...
-> Removing credentials from cache...
-> Done.Si ya tiene una credencial almacenada, gitcreds::gitcreds_set() la revela e incluso le permitirá inspeccionarla. Esto le ayuda a decidir si desea conservar la credencial existente o reemplazarla. En caso de duda, opte por una credencial nueva y de buena reputación en lugar de una antigua de origen dudoso.
> gitcreds::gitcreds_set()
-> Your current credentials for 'https://github.com':
protocol: https
host : github.com
username: PersonalAccessToken
password: <-- hidden -->
-> What would you like to do?
1: Keep these credentials
2: Replace these credentials
3: See the password / token
Selection: 2
-> Removing current credentials...
? Enter new password or token: ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-> Adding new credentials...
-> Removing credentials from cache...
-> Done.Puede comprobar que ha almacenado una credencial con gitcreds_get():
gitcreds_get()
#> <gitcreds>
#> protocol: https
#> host : github.com
#> username: PersonalAccessToken
#> password: <-- hidden -->Otras funciones que pueden ayudarle a sentirse seguro acerca de su configuración PAT incluyen:
usethis::gh_token_help()
usethis::git_sitrep()
gh::gh_whoami()9.4.1.2 Paquete credentials
Si no tiene las credenciales instaladas, instálelas a través de install.packages("credentials"). Si ha instalado usethis, ya tendrá credenciales, porque usethis usa gert y gert usa credenciales.
Llame a set_github_pat(). Si aún no tiene una PAT almacenada, se le pedirá que la ingrese. ¡Pegar!
credentials::set_github_pat()Si tiene éxito, sus llamadas iniciales (y posteriores) se verán así:
credentials::set_github_pat()
#> If prompted for GitHub credentials, enter your PAT in the password field
#> Using GITHUB_PAT from Jennifer (Jenny) Bryan (credential helper: osxkeychain)Otras funciones que pueden ayudarle a sentirse seguro acerca de su configuración PAT incluyen:
usethis::gh_token_help()
usethis::git_sitrep()
gh::gh_whoami()9.4.2 Almacene credenciales mediante el uso orgánico de Git
Antes de que existieran gitcreds y credenciales (ver arriba), teníamos que orquestar un desafío de credenciales configurando (y luego derribando) un repositorio de juguetes. Esto todavía ocurre naturalmente en el ejercicio guiado en Conectarse a GitHub. Pero recomiendo encarecidamente administrar su PAT de manera más directa y explícita con gitcreds::gitcreds_set() y funciones relacionadas en gitcreds.
9.5 Problemas y soluciones de HTTPS PAT
Esta sección es para personas que necesitan saber aún más sobre la administración de PAT porque se encuentran en una situación no estándar o sobre la resolución de problemas.
9.5.1 Se almacena el PAT válido, pero luego se le dice que el PAT no es válido
Supongamos que genera un PAT nuevo y lo almacena correctamente como se describe anteriormente. Quizás incluso lo uses con éxito. ¡Pero luego te dicen que tu PAT no es válido! ¿Cómo puede ser esto?
Aquí hay algunas explicaciones probables:
- Su PAT realmente no es válido. De forma predeterminada, los PAT ahora tienen una fecha de vencimiento. Un día realmente te despertarás y descubrirás que el PAT se ha estropeado durante la noche y necesitas volver a generarlo y almacenarlo.
- Tienes un PAT no válido almacenado en otro lugar, que has olvidado, probablemente en
.Renviron. Esta PAT antiguo e inválido impide que los paquetes R incluso descubran su PAT nuevo y válido.
9.5.1.1 PAT ha expirado
Vas a regenerar y restaurar tu PAT según un cronograma dictado por su período de vencimiento. Por defecto, una vez al mes.
Cuando el PAT caduque, regrese a https://github.com/settings/tokens y haga clic en su Nota. (Etiquetas muy bien tus tokens por caso de uso, ¿verdad? ¿Verdad?) En este punto, opcionalmente puedes ajustar los alcances y luego hacer clic en “Regenerar token”. Opcionalmente, puedes modificar su Caducidad y luego hacer clic en “Regenerar token” (nuevamente). Como antes, copie el PAT al portapapeles, llame a gitcreds::gitcreds_set() y péguelo.
Con suerte, cada vez está más claro por qué la Nota de cada token es tan importante. El token real puede cambiar, por ejemplo, una vez al mes, pero su caso de uso (y alcances) son mucho más persistentes y estables.
9.5.1.2 GITHUB_PAT antiguo en .Renviron
Estas funciones de usethis diagnosticarán este problema:
usethis::gh_token_help()
usethis::git_sitrep()En el pasado, era común almacenar un PAT como la variable de entorno GITHUB_PAT en .Renviron. Pero ahora, gracias a gitcreds y credenciales, podemos almacenar y recuperar un PAT, desde R, de la misma manera que lo hace la línea de comandos Git.
Si tiene alguna duda sobre sus prácticas anteriores, abra .Renviron, busque una línea que configure la variable de entorno GITHUB_PAT y elimínela. usethis::edit_r_environ() puede ser útil para abrir .Renviron para editarlo. No olvide reiniciar R para que este cambio surta efecto.
9.5.2 PAT no persiste en macOS o Windows
Los asistentes de credenciales utilizados por Git aprovechan los almacenes de credenciales oficiales proporcionados por el sistema operativo, siempre que sea posible, como macOS Keychain y Windows Credential Manager.
Si está intentando seguir los consejos aquí y su PAT nunca persiste, considere que es posible que necesite actualizar Git para obtener sus asistentes de credenciales más modernos. Esta es absolutamente un área de Git que ha mejorado rápidamente en los últimos años y el paquete gitcreds y credentials funcionan mejor con las versiones recientes de Git. No he necesitado activar explícitamente un asistente de credenciales en macOS o Windows con ninguna versión reciente de Git.
Aquí hay un comando para revelar el asistente de credenciales actual y lo que veo estos días.
macOS
$ git config --show-origin --get credential.helper
file:/Users/jenny/.gitconfig osxkeychainWindows
$ git config --show-origin --get credential.helper
file:C:/Program Files/Git/mingw64/etc/gitconfig managerSi desea saber más sobre cómo gitcreds y credenciales administran su PAT, obtenga información sobre git credential <fill|approve|reject>. Para los entusiastas, esa documentación les brinda detalles sobre cómo se almacenan y recuperan las credenciales:
Git tiene una interfaz interna para almacenar y recuperar credenciales de ayudantes específicos del sistema, además de solicitar al usuario nombres de usuario y contraseñas. El comando
git-credentialexpone esta interfaz a scripts que pueden querer recuperar, almacenar o solicitar credenciales de la misma manera que Git.
En Windows, sus credenciales de Git probablemente se almacenen a través del Administrador de credenciales.
En macOS, sus credenciales de Git probablemente estén almacenadas en el Keychain.
Si realmente desea husmear directamente para explorar o limpiar sus credenciales de GitHub, inicie Credential Manager (Windows) o Keychain Access (macOS) y busque “github.com”.
9.5.3 PAT no persiste en Linux
Los asistentes de credenciales utilizados por Git aprovechan los almacenes de credenciales oficiales proporcionados por el sistema operativo en macOS y Windows, pero lamentablemente no existe un equivalente exacto en Linux.
Lo más fácil es configurar Git para “almacenar en caché” sus credenciales (frente a “almacenar”), que tiene un tiempo más limitado. Luego establezca el tiempo de espera de la caché en un período de tiempo suficientemente largo. Aquí fijamos el tiempo de espera en diez millones de segundos o alrededor de 16 semanas, suficiente para un semestre.
git config --global credential.helper 'cache --timeout=10000000'Es posible que esto aún no haga que su PAT esté disponible para los paquetes R. En este caso, es posible que necesite utilizar el método más antiguo y menos seguro de almacenar su PAT en .Renviron. usethis::edit_r_environ() abre ese archivo para editarlo.
usethis::edit_r_environ()Agrega una línea como esta, pero sustituye tu PAT:
GITHUB_PAT=ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx¡Asegúrese de que este archivo termine en una nueva línea! La falta de una nueva línea puede provocar una falla silenciosa al cargar los archivos de inicio, lo que puede ser complicado de depurar. Tenga cuidado de que este archivo no se envíe accidentalmente a la nube, p. Google Drive o GitHub.
Reinicie R para que los cambios en .Renviron surtan efecto.