The access token mechanism is there for future use when I add calls
to change information and to keep a session state between requests.
Neither is needed for the currently implemented requests, but I
didn't want to have a different system for different requests.
I'll change to sending expires_at. I doubt if anyone is actually
using the existing field but if someone has a problem? I could send
both.
73,
John
On 04/10/2024 11:07, Rik M7GMT wrote:
toggle quoted message
Show quoted text
Sure. One thing I am a bit concerned about is the access_token
process. For public information (such as the node list), this
doesn't seem necessary at all, and as anyone can simply request
a token without any authentication, doesn't actually provide any
security, while adding an extra layer of complexity. It would
be required when it comes to configuration data that's normally
behind a login though (both getting and setting).
?
The other point is the expires_in
key. I believe this should instead be expires_at,
otherwise it's a bit confusing - does it mean 300 minutes from
when the request was made, from when the response was sent, or
when the response was received? This should also probably use
UNIX epoch rather than minutes, e.g. { "access_token":
"ABC123", "expires_at": 1728050700000 }. This would
make the logic on the client much simpler as you would just
check if the expires_at
value is greater than the current time, to know if the token is
still valid.
