Store access token for migration #12509

Open
opened 2025-11-02 10:12:12 -06:00 by GiteaMirror · 3 comments
Owner

Originally created by @Kirill on GitHub (Feb 20, 2024).

Feature Description

I up local version of gitea for store (and sync) some interesting repositories from gitlab, guthub, etc...
Each time when I want create migration, I must put access token. Why you can't store my access token?
image

Screenshots

In gitlab I can create auth token witch stored and I don't set it each time
image

Originally created by @Kirill on GitHub (Feb 20, 2024). ### Feature Description I up local version of gitea for store (and sync) some interesting repositories from gitlab, guthub, etc... Each time when I want create migration, I must put access token. Why you can't store my access token? ![image](https://github.com/go-gitea/gitea/assets/302940/b61a51b8-f8b7-4266-ba41-2e60472eeafc) ### Screenshots In gitlab I can create auth token witch stored and I don't set it each time ![image](https://github.com/go-gitea/gitea/assets/302940/859e37a0-aecb-4262-bd65-26ecc460549b)
GiteaMirror added the type/proposal label 2025-11-02 10:12:12 -06:00
Author
Owner

@OPerepadia commented on GitHub (Sep 3, 2024):

I have the same use case. It would be really convenient to store an access token and not have to enter it every time a new migration is added.
Additionally, it would be great if we could update the token when it expires, rather than having to delete and re-add every affected repository again.
EDIT:
It turns out that it's already possible to update the access token without deleting and cloning every repository.
You need to go to your repository settings, and under Mirror Settings, there is Authorization section where you can paste the new token in a Password field (see below image).
It's a bit confusing that they call it a password though, because when you add a new migration, they still refer to it as an Access Token.
image

@OPerepadia commented on GitHub (Sep 3, 2024): I have the same use case. It would be really convenient to store an access token and not have to enter it every time a new migration is added. ~~Additionally, it would be great if we could update the token when it expires, rather than having to delete and re-add every affected repository again.~~ EDIT: It turns out that it's already possible to update the access token without deleting and cloning every repository. You need to go to your repository settings, and under Mirror Settings, there is Authorization section where you can paste the new token in a Password field (see below image). It's a bit confusing that they call it a password though, because when you add a new migration, they still refer to it as an Access Token. ![image](https://github.com/user-attachments/assets/e50a70cf-0058-4477-abed-4b933e54237a)
Author
Owner

@tobiashochguertel commented on GitHub (Nov 10, 2024):

I had the same need, and solved it for the moment with Chrome / Firefox Extension Tapermonkey (http://tampermonkey.net/) with the following UserScript for Tampermonkey written in JavaScript:

// ==UserScript==
// @name         gitea-migrate-from-github-autofill
// @namespace    http://tampermonkey.net/
// @version      2024-11-10
// @description  try to take over the world!
// @author       You
// @match        https://gitea.hochguertel.work/repo/migrate*
// @icon         https://about.gitea.com/gitea-text.svg
// @grant        none
// ==/UserScript==

(function() {
    'use strict';

    console.log('Tampermonkey added `gitea-migrate-from-github-autofill` script.');

    document.getElementById('auth_token').value = "github_pat_....";
    document.getElementById('mirror').click();
    document.getElementById('lfs').click();
    document.querySelector('input[name="wiki"]').click();
    document.querySelector('input[name="labels"]').click();
    document.querySelector('input[name="issues"]').click();
    document.querySelector('input[name="pull_requests"]').click();
    document.querySelector('input[name="releases"]').click();
    document.querySelector('input[name="milestones"]').click();

})();

Important is the line // @match https://gitea.hochguertel.work/repo/migrate*, with that, you define where this UserScript will be activated.

Have a look in the Tampermonkey Documentation about the property match.

@tobiashochguertel commented on GitHub (Nov 10, 2024): I had the same need, and solved it for the moment with Chrome / Firefox Extension `Tapermonkey` (http://tampermonkey.net/) with the following UserScript for Tampermonkey written in JavaScript: ```js // ==UserScript== // @name gitea-migrate-from-github-autofill // @namespace http://tampermonkey.net/ // @version 2024-11-10 // @description try to take over the world! // @author You // @match https://gitea.hochguertel.work/repo/migrate* // @icon https://about.gitea.com/gitea-text.svg // @grant none // ==/UserScript== (function() { 'use strict'; console.log('Tampermonkey added `gitea-migrate-from-github-autofill` script.'); document.getElementById('auth_token').value = "github_pat_...."; document.getElementById('mirror').click(); document.getElementById('lfs').click(); document.querySelector('input[name="wiki"]').click(); document.querySelector('input[name="labels"]').click(); document.querySelector('input[name="issues"]').click(); document.querySelector('input[name="pull_requests"]').click(); document.querySelector('input[name="releases"]').click(); document.querySelector('input[name="milestones"]').click(); })(); ``` Important is the line `// @match https://gitea.hochguertel.work/repo/migrate*`, with that, you define where this UserScript will be activated. Have a look in the Tampermonkey Documentation about the property [`match`](https://www.tampermonkey.net/documentation.php?locale=en#meta:match).
Author
Owner

@JokerQyou commented on GitHub (Apr 8, 2025):

Would also like to store GitHub PAT at account level (and tokens for other mirror sources as well).

When migrating repo A I create a PAT. A month later I'd like to mirror repo B and have to create another PAT, since Gitea only stores the token at repository level. The user have to either store their tokens somewhere else (PAT is only displayed once, after creation) - which is insecure, or create different token per repo - which is hard to manage.

I think it's good to offer an option to store the token at account level:

  • Add a "save this token" checkbox under "Access token" input, when it is checked, show another input field "Token name", allowing user to name it. If no name is provided, name it "Token for REPO_URL".
  • Store the token with its name and link to current user, also link to current repo if it's a mirror.
  • When user is migrating another repo, show stored tokens as selectable list in "Access token" input. User can choose to select one of the existing tokens, or type in a new value.
  • Additionally, user can update stored token (name and/or token value) in personal settings page. The page lists all stored tokens of current user. For each token, linked repositories are also shown in the list. A token can only be deleted if no repo is using it.
@JokerQyou commented on GitHub (Apr 8, 2025): Would also like to store GitHub PAT at account level (and tokens for other mirror sources as well). When migrating repo A I create a PAT. A month later I'd like to mirror repo B and have to create another PAT, since Gitea only stores the token at repository level. The user have to either store their tokens somewhere else (PAT is only displayed once, after creation) - which is insecure, or create different token per repo - which is hard to manage. I think it's good to offer an option to store the token at account level: - Add a "save this token" checkbox under "Access token" input, when it is checked, show another input field "Token name", allowing user to name it. If no name is provided, name it "Token for REPO_URL". - Store the token with its name and link to current user, also link to current repo if it's a mirror. - When user is migrating another repo, show stored tokens as selectable list in "Access token" input. User can choose to select one of the existing tokens, or type in a new value. - Additionally, user can update stored token (name and/or token value) in personal settings page. The page lists all stored tokens of current user. For each token, linked repositories are also shown in the list. A token can only be deleted if no repo is using it.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#12509