[GH-ISSUE #9] token expiration (http backend) #3

Closed
opened 2026-02-27 15:45:55 +03:00 by kerem · 10 comments
Owner

Originally created by @CompileNix on GitHub (Jan 24, 2020).
Original GitHub issue: https://github.com/proxmoxer/proxmoxer/issues/9

Originally assigned to: @jhollowe on GitHub.

I'm writing a tool which may run for several hours. It seems that the api access token times out at some point.

Do you think proxmoxer should detect that and try to aquire a new api access token by itself?

This would require that proxmoxer would need to keep username and password in memory permanently, while the instance of proxmoxer exists.

Originally created by @CompileNix on GitHub (Jan 24, 2020). Original GitHub issue: https://github.com/proxmoxer/proxmoxer/issues/9 Originally assigned to: @jhollowe on GitHub. I'm writing a tool which may run for several hours. It seems that the api access token times out at some point. Do you think proxmoxer should detect that and try to aquire a new api access token by itself? This would require that proxmoxer would need to keep username and password in memory permanently, while the instance of proxmoxer exists.
kerem 2026-02-27 15:45:55 +03:00
Author
Owner

@elurex commented on GitHub (Feb 12, 2020):

this is a much needed feature or otherwise the process need to be killed and started like every 2 hours or so which cause chaos when there are process are actually calling api gets killed as well

<!-- gh-comment-id:585017932 --> @elurex commented on GitHub (Feb 12, 2020): this is a much needed feature or otherwise the process need to be killed and started like every 2 hours or so which cause chaos when there are process are actually calling api gets killed as well
Author
Owner

@CompileNix commented on GitHub (Feb 12, 2020):

I've already implemented this in an internal fork and is working well for me.

I'll create a PR for this soon.

<!-- gh-comment-id:585150593 --> @CompileNix commented on GitHub (Feb 12, 2020): I've already implemented this in an internal fork and is working well for me. I'll create a PR for this soon.
Author
Owner

@CompileNix commented on GitHub (Apr 16, 2020):

PR has been created: #12

<!-- gh-comment-id:614848689 --> @CompileNix commented on GitHub (Apr 16, 2020): PR has been created: #12
Author
Owner

@jhollowe commented on GitHub (Apr 21, 2020):

@compilenix @elurex Are your scripts consistently using the connection (at least once every 2 hours) or are they sitting idle most of the time?

<!-- gh-comment-id:617470923 --> @jhollowe commented on GitHub (Apr 21, 2020): @compilenix @elurex Are your scripts consistently using the connection (at least once every 2 hours) or are they sitting idle most of the time?
Author
Owner

@CompileNix commented on GitHub (Apr 22, 2020):

My script is using the connection between 1 - 8 times a day, Idle time between requests can range from 1 to 24 hours.

Regarding #16: While i like the aproach of recreating the access token without the password, this would currently not resolve the original issue i had.

Suppose you have a service running which only performs requests to the proxmox api couple times a day, the access token / cookie would expire between two api calls and the service would need to recreate the proxmoxer object instance or restarting the whole service.

Two further ideas i have to add:

  1. Maybe we could save the password only if the caller explicitly requests it, and do no save it by default.
  2. We could spawn a worker thread that renews the access token independent of the caller.
<!-- gh-comment-id:617613360 --> @CompileNix commented on GitHub (Apr 22, 2020): My script is using the connection between 1 - 8 times a day, Idle time between requests can range from 1 to 24 hours. Regarding #16: While i like the aproach of recreating the access token without the password, this would currently not resolve the original issue i had. Suppose you have a service running which only performs requests to the proxmox api couple times a day, the access token / cookie would expire between two api calls and the service would need to recreate the proxmoxer object instance or restarting the whole service. Two further ideas i have to add: 1. Maybe we could save the password only if the caller explicitly requests it, and do no save it by default. 2. We could spawn a worker thread that renews the access token independent of the caller.
Author
Owner

@jhollowe commented on GitHub (Apr 22, 2020):

Yeah, I like the prospects of the first idea. I'll add that to #16 in a bit.

<!-- gh-comment-id:617815679 --> @jhollowe commented on GitHub (Apr 22, 2020): Yeah, I like the prospects of the first idea. I'll add that to #16 in a bit.
Author
Owner

@jhollowe commented on GitHub (Apr 22, 2020):

@compilenix can you try out the PR for a few days with the long_running flag and see if it works for your use case?

<!-- gh-comment-id:617832652 --> @jhollowe commented on GitHub (Apr 22, 2020): @compilenix can you try out the PR for a few days with the long_running flag and see if it works for your use case?
Author
Owner

@CompileNix commented on GitHub (May 3, 2020):

I'm really busy lately, i'm trying to test this by next week :)

<!-- gh-comment-id:623175309 --> @CompileNix commented on GitHub (May 3, 2020): I'm really busy lately, i'm trying to test this by next week :)
Author
Owner

@jhollowe commented on GitHub (May 15, 2020):

would using the api tokens (#10) fill the need for this? It seems like that would be better than storing the password and is designed to have better access control.

<!-- gh-comment-id:629487997 --> @jhollowe commented on GitHub (May 15, 2020): would using the api tokens (#10) fill the need for this? It seems like that would be better than storing the password and is designed to have better access control.
Author
Owner

@CompileNix commented on GitHub (May 15, 2020):

It seems like it, if api tokens are working as i think they will be this issue, #12 and #16 would be obsolete and could be closed.

<!-- gh-comment-id:629502435 --> @CompileNix commented on GitHub (May 15, 2020): It seems like it, if api tokens are working as i think they will be this issue, #12 and #16 would be obsolete and could be closed.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/proxmoxer#3
No description provided.