[Feature]: Store Trakt.tv authentication details outside of config.yml

Is your feature request related to a problem? Please elaborate.

I have an Ansible playbook to deploy a Docker container for Plex Meta Manager which includes all my configuration YAML files (i.e. config.yml, and other metadata and collection YAML files). When I want to make a change to my configuration, I change the source files, and re-deploy with Ansible. This will rewrite whatever it’s on my server.

You can see how this is problematic for Trakt.tv authentication, which is written to the config.yml by PMM. Every time I re-deploy my Ansible playbooks, the authentication: section for Trakt.tv will be gone, losing the authentication and refresh tokens, thus losing access to my Trakt.tv data.

Describe the solution you’d like

Split the Trakt.tv static configuration from dynamic configuration into different files:

config.yml

trakt:
  client_id:
  client_secret:
  pin:

auth.yml

trakt:
  authorization:
    access_token:
    token_type:
    expires_in:
    refresh_token:
    scope:
    created_at:

This way, I could keep overwriting config.yml without worrying that the Trakt.tv authentication details are going to be overwritten and lost.

Additional Information

No response

[chazlarson]

But, like you said, I’m just trying to offer workarounds for something that is unlikely to be implemented.

The use cases suggested when this has been discussed previously have basically been this very same use case, so it’s unlikely that plans will change. I’ll bow out, though.

[meisnate12]

When I run my Ansible playbook, this file contents be copied to the remote server, and fully replace the config.yml in the remote server (where I have PMM running, not the same machine where I’m running the Ansible script).

I then run PMM on the remote server (by logging into the machine with SSH), and it will authenticate against Trakt with the provided client ID and secret. Once that process is done, the config.yml in the remote server will be changed to this:

I would recommend authenticating locally and saving that trakt info and push it just like you do for tmdb. Like chaz described above.

The access token expires after 3 months (this is on Trakt’s documentation), and when that happens, the refresh token is then used to regenerate a new access token. Once the refresh token is used on one of the installs it should expire, and not be usable in the other two installs.

In my experience working with the trakt api is that their info on the documentation and what actually happens sometimes differ. I’ve definitely used access tokens longer then every 3 months

Ultimately im working on other features that would make this change meaningless so theres that too.