steep domeBOT
Welcome @iron blade!
Someone from <@&938443185347244033> will assist when they're available.
Including meta.log from the beginning is a huge help. Type !logs for more information.
After attaching your log, do not forget to hit the green check boxes when prompted by our bot.
You can press the "Close Post" button above or type /close at any time to close this post.
turbid tiger
Anything to do here?
iron blade
Well, ya....I'm not really sure a meta.log is related to this issue though
turbid tiger
what issue?
iron blade
I wrote a long message and I guess it got deleted because I did not include a meta.log. Give me a second and I'll try to explain
Kometa Secrets is great for allowing a user to share their entire config.yml while concealing API keys and such.
But some credentials, specifically Refresh_Token and Access_Token are temporary and expire/refresh at intervals. When they do refresh, Kometa overwrites the Kometa Secrets variables in the config.yml file with the new true credential values
steep domeBOT
The following was shared by @iron blade and was automatically redacted by Luma as it may have contained sensitive information.
If you feel this message should not have been redacted, resend it with !noredact in your message to avoid redaction.
trakt:
client_id: (redacted by Luma)
client_secret: (redacted by Luma)
authorization:
access_token: (redacted by Luma)
token_type: Bearer
expires_in: 7889238
refresh_token: (redacted by Luma)
scope: public
created_at: 1723463021
pin:
So for example......here....Trakt access_token and refresh_token......those actual values are referenced in my docker compose.....but those values have expiration dates and kometa/trakt will have to refresh them after some time. When it does...it overwrites these kometa secret variables in my config.yml. That isn't good.
Have you experienced this behavior or are familiar with it?
The following was shared by @iron blade and was automatically redacted by Luma as it may have contained sensitive information.
If you feel this message should not have been redacted, resend it with !noredact in your message to avoid redaction.
haha...your bot autmatically concealed the kometa secret variables...they weren't true values. They were just:
access_token: (redacted by Luma)
ok, I'll stop trying to write that, sorry
turbid tiger
That's what I would expect to happen. Everything besides the three top-level values are maintained and updated by Kometa in the config.yml. There's no provision for writing them off in some arbitrary location.
iron blade
So then how can I easily publically share my entire config.yml in a systematic approach without leaking my access_token and refresh_token?
what do you mean by the "Three top-level values"? Sorry, which are those?
turbid tiger
client_id, client_secret, pin
turbid tiger
So then how can I easily publically share my entire config.yml in a systematic a...
Don't share your active config with secrets in place. Share a template.
iron blade
In short, it seems kometa secrets variable feature is only useful for static values........
turbid tiger
In short, it seems kometa secrets variable feature is only useful for static val...
That is true. I don't see a practical way to make it work for ephemeral values since there's no fixed place to update such things.
iron blade
One potential solution/feature_request that would allow for more robust secrets concealment - A separate "secrets.yml" which the config.yml calls/references
turbid tiger
Sure. there's a feature request for that I believe.
iron blade
Is that something anyone has considered?
iron blade
I have files in my kometa directory linked to a github repo. It makes it extremely easy to share my ENTIRE setup. Config, image files, custom this, custom that. The whole thing.
I of course am not sharing the docker compose file which holds my credentials...but this whole approach allows me to easily show what my setup is for others interested
And github is nice just for version tracking and such as well...revert if problem, etc
turbid tiger
I would probably have a template config and not check in the active config.yml.
iron blade
but also....having a clean config.yml is something I would think would be nice for the Kometa dev team as well.....no more needing bots monitoring all our messages and deleting them when we expose creds. There would be no creds to expose in a config.yml if you have a separate secrets.yml
Hmmmm......I need to look into the template config function you are referencing. That sounds like it might be a solution for me
You're saying I could have a separate template.yml or some kind in my config.yml that references these credentials/secrets?
Ah, I misunderstood. I think I understand now.
You're referring to managing two separate config.yml files now instead of just one.......ehhhh
So when I make a change to my config, I have to make that change twice - Once to my active config and again to my public "template" config
turbid tiger
that's a job for a script.
iron blade
Mmmmm.....yes, I agree
Alright alright. While I do think the secrets.yml is an excellent feature request, I now see an altnerate option I can pursue. Thanks for discussing this with me
small gulch
but also....having a *clean* config.yml is something I would think would be nice...
people dont even need to share config.ymls with us
the log contains this
and then the bot recreates the config