How to manage the lifetime limit of GitLab access tokens?

From May 2024 GitLab stopped supporting access tokens with no expiry date, so the token we had been using since 2018 stopped working and created a serious problem in our plugins for WordPress and in our plugins for WooCommerce that manage their updates from our private repository, since they stopped connecting with the old access token and they do not do so by making the repository public either.

The problem is that we cannot leave a token configured in the code of the plugin that is going to end up disappearing within a maximum period of 365, so we have had to build a small piece of PHP code that takes care of regenerating the lifetime of the new access token using the GitLab rotation API.

How have we solved it?

On our website we have created a scheduled event that runs every six months, since, as we have verified, the rotation generates a maximum date of eleven months despite telling it one year. The PHP code we have had to build is very similar to this one:

Basically what the apg_regenera_token event does is read the original token that we have previously saved in the fichero_que_contiene_el_token.ext file, make a GET query to obtain the complete list of the access tokens we have configured in GitLab and look for one whose name is Plugins and which is active, which is the one we are interested in updating; in your case you must put the name you have used.

Once the internal ID of this token has been located, it generates a new POST query to add an expiry date of one year to the token; on doing so a new token is automatically generated, which we store again in fichero_que_contiene_el_token.ext so that it can be used the next time. Should any error have occurred, it will send us an email with the information it received in the first query so that we can correct whatever we need before losing the connection for good.

We can read the token stored in the fichero_que_contiene_el_token.ext file whenever we need to with the following PHP code:

In this very simple way we can regenerate the access token automatically every six months and we can read it as many times as we need, always obtaining the last stored token to guarantee ourselves permanent access.

And how do I use it in a downloadable WooCommerce product?

In our case the premium plugins are downloaded directly from the private GitLab repository. The download URL of the files have a structure similar to this one: https://gitlab.com/api/v4/projects/xxxx/repository/archive.zip/?private_token=yyyy

The problem is that the private token is now not always the same and we need to read it from the file that stores it; furthermore, the download URL indicated in the downloadable WooCommerce product has to have a valid extension such as .zip, .pdf, .jpg, .mp3 or similar, but under no circumstances is it going to accept a .php extension, for example.

To solve this new problem we have created another piece of PHP code similar to this one:

Thanks to this new code we can indicate a download URL with this structure: https://dominio.ext/fichero.zip?plugin=APG-WCES.

Basically what is going to happen when this dynamic URL is opened is that the original ZIP file is going to be downloaded temporarily from the GitLab repository and it is going to return the downloaded file to make its direct download from the browser easier. It must be remembered that WooCommerce masks this dynamic URL, so the customer never has direct access to it, but does have access to the direct download of the ZIP file.

Conclusion

After the problem generated by GitLab’s new expiry date policy for access tokens, we have had no choice but to give it another turn of the screw in order to find the best solution. Thanks to the use of the GitLab rotation API and a little ingenuity we have solved a problem that at first seemed quite complicated to us.

We hope you find this code useful for your own developments and we look forward to your comments.