Github API token - where is it stored

[urskaufmann]

This behaviour is not very userfriendly.

I get this warning today also after I have generated a token which expires on Nov 13 2025.
Means I have a token, but it is not used

Our virtual PC are reset every day. Is this token-code stored in the TMMT settings in a file, that is reset if the PC is reset? -> Not happy like this...

[sjib]

@urskaufmann You have to create a token, that does not expire too quickly. You can choose how long a token should be valid.

[urskaufmann]

You have to create a token, that does not expire too quickly. You can choose how long a token should be valid.

I know. But my token is still valid... Does not matter if it expires tomorrow or in two years - if I have a valid token and TMMT does not use it.

[sjib]

@urskaufmann Did you add the token into the settings?

@domi4484

Our virtual PC are reset every day. Is this token-code stored in the TMMT settings in a file, that is reset if the PC is reset? -> Not happy like this...

Any way that the token can be read from somewhere in this scenario? Where is the token stored?

[w0pr]

@urskaufmann Did you add the token into the settings?

@domi4484

Our virtual PC are reset every day. Is this token-code stored in the TMMT settings in a file, that is reset if the PC is reset? -> Not happy like this...

Any way that the token can be read from somewhere in this scenario? Where is the token stored?

It is stored in [oqtopus] INI section in QGIS.ini below the chosen QGIS profile (here: "SWBSA TEKSI WW 2025.0.2rc8") in %APPDATA%

QGIS.ini

If daily virtual PC reset nukes the profile, then you are out of luck and you will need to set this again each morning (need to also store it somewhere else, because github won't show it after creation).

[sjib]

Maybe a defined QGIS3.ini could be restored where the token is integrated.

[sjib]

But not very user friendly, I agree !

@ponceta @tproduit @domi4484 Any ideas to improve this handling of API tokens? We now have a straight forward TMMT User interface and then we have a quite challening API token process that makes the whole thing tricky again. I suggest to integrate some thinking on that in phase 3.

[urskaufmann]

thanks for this info. Now it's clear: I have more than one profile and today I worked with another profile... Good to know.

[urskaufmann]

PS: the profiles are not reset

[ponceta]

Tip

Concerning the current issue, it appears to be linked to the QGIS profile where a plugin is installed once per profile. In that case my best advice is to have ONE administrator profile where these tools are installed and the token configured.

With @3nids we will aim to enhance the file caching plugin side to avoid many requests using TMMT which could prevent this token necessity to appear too quickly.

A manual override could be provided to download the full zip and deploy from a zip for people finding this too complicated.

We can document better the GitHub token creation procedure if you feel it is not well presented? If so please ask and I will remove the bug label of this issue. The installation documentation part will have to be rewritten soon.

Important

TMMT is an administrator tool which replace the python/shell command line for installation and upgrade providing a visual interface identical for every module. Some admin configuration can be expected as it is not aimed to be used by any users EVEN if it is very easy to use. As we want it to work for ANY module, pull request, ... , it comes with technical constraints that were not present on the older datamodel tool approach which was based on static and manual links created by hand with a risk of error.

[w0pr]

Then again, storing secret access token unencrypted in the open in QGIS.ini isn't perfect; it should really be stored in authdb via QgsAuthManager; implementation should be straightforward, I think I'll give it a try.

[domi4484]

it should really be stored in authdb via QgsAuthManager

Oqtopus can be run as a standalone app, in that case all QGIS classes are not available.
As issues of this kind arise more and more, maybe we should consider dropping support for the standalone variant as an edge case