FA Pro in Python/Django projects - Security concerns of token being versioned as part of requirements.txt or poetry configuration because the of the FA token being part of the URL as opposed to using Basic authentication or the likes

[devraj]

I am using FontAwesome Pro in a Python project. I started configuring it using the guide published here and adapting it to using poetry. In principle my project is a Django project running in a container. My broad outlines for security and streamlined deployments are as follows:

• Use poetry to install fontawesome and configuring it as described in the guide
• Pass the token as an environment variable to the container

Assuming my token is in the environment variable FONT_AWESOME_TOKEN from what I can tell, the security model for the private reposistory is that the token (which is part of the URL) is dynamically queried for validity i.e

https://dl.fontawesome.com/$FONT_AWESOME_TOKEN/fontawesome-pro/python/simple/

will resolve and render a list of wheels if the FONT_AWESOME_TOKEN is currently valid (I have tested this and it works as expected).

In both instances I can't really find a way around not versioning the token into the repostiory (which is not ideal at all). From what I understand this is primarily because the authentication of private repositories is handled via Basic authentication and not a token that is part of the URL (which makes sense).

Using requirements.txt

Typically requirements.txt would be versioned into the repository of the project, and it's quite typical to use this is for the build process. According to the recommendation way we should provide the token as part of the url as the value to the --extra-index-url parameter.

Using poetry

You would typically add a source for a private repository e.g

poetry source add --priority=primary fontawesome https://dl.fontawesome.com/$FONT_AWESOME_TOKEN/fontawesome-pro/python/simple/

In the above example the FONT_AWESOME_TOKEN would be resovled from the environment variable and the pyproject.toml file would have a section appended with the value of the token placed inline

[[tool.poetry.source]]
name = "fontawesome"
url = "https://dl.fontawesome.com/ACTUAL_TOKEN_VALUE/fontawesome-pro/python/simple/"
priority = "primary"

following this you can install fontawesomepro via poetry add fontawesomepro and all works well.

In the case of poetry I am still exploring if add repository to the configuration is a solution:

poetry config repositories.fontawesome https://dl.fontawesome.com/$FONT_AWESOME_TOKEN/fontawesome-pro/python/simple

This obviosly add the URL to the configuration and since it's a command I could in theory inject this as part of the build process for the container (and thus not have to version the token). The configuration also allows for setting http-basic authentication via:

poetry config http-basic.fontawesome <your-fontawesome-username> $FONT_AWESOME_TOKEN

I have not been able to get basic authentication working with the FA private repositories

Questions

I wanted to reach out and see if there's anyone else that is using FA Pro and is able to securely provide the token to the project without versioning it.

Is there another package manager that works better at this in the Python world (not that I really want to switch a package manager at the moment).

Have I missed something completely in terms of being able to dynamically inject the token in requirements.txt or poetry?

Appreciate you taking the time to read.

I could get the wheel files and keep it in a private location of our own (web server etc) and work around the security requirements of poetry, would this break the license terms of FA?