How does this affect the duration of the granted access?
I’m currently using the login buttons on the dashboard, and refreshes this regular.
Propably not a good thing to do.
Would be best to let node-red have everlasting access for some cases.
I feel this Oauth2V2 node has a solution for this.
Will have if/when its complete…
If you use authorization code or password as credentials a refresh token is issued.
But password “may” disappear from the oauth2 specification in future, currently it is “not recommended” and it is planned to be removed from the oath2 module that farmOS uses by its maintainers, there have been some discussions in dev meetings / the chatroom as to whether or not the farmOS team should create a plugin to add that feature back when they migrate to the newer version, I guess that will be up to @mstenta and co.
If the password authentication is removed then “client credentials” would become the recommended alternative, in most cases this will probably be fairly similar to password authentication except the client will have its own password instead of the user password. However this does not return a refresh token, it is considered unnecessary as the authentication can be achieved unattended unlike “authorization code” (or “password” when implemented correctly)
So… Long story short, its fine to authenticate each time, but to reduce unnecessary authentication requests when a token is issued, so also is an integer representing how long the token will live, you can create a flow to only re-authenticate if the token has expired with a simple timer.
Refresh tokens are used to avoid storing user passwords in an application so only authentication flows that require user passwords produce them, by right that way the application should only ask for passwords once then forget them and reauthenticate only with the refresh token.
Ah. Thanks for another understandable explanation. Another piece to the puzzle.
I will read up on this, and experiment with it. Useful knowledge of using any api.
Only getting my head around this properly myself.
Maybe the refresh should be handled by a dedicated node, that can be dropped into any flow and handle a reauthenticate request if the token has expired or just be handled by the API node.
That sounds like a good idea and could simplify a bit.
I was thinking if it could be a setting in the OAuth2V2, but it must be better with a refresh node.
Possibly easier to understand too.
Yea, I’ll go with a refresh node for now, it will stand out in the flow as to what it is.
Perhaps a minuet or 2 should be shaved off of the expiry time incase there are a few API requests in the one flow.
Should be. I guess the farmos instance can be asked for an expiration time?
Is there any point letting the user adjust this value? Propably not.
It issues a time in seconds with the tokens.
I can adjust the times on my self hosted instance, I don’t know exactly what you have access to in Farmier but I’d suspect not. Probably a good security argument for not making them longer and maybe performance for not being shorter. But once handled correctly it won’t matter.
Right, I can’t adjust this.
Isn’t 3600 a bit low?
But refresh 2 minutes before expiry should be fine in most cases i’d say.
Well it’s an hour, its probably reasonable enough, when the refresh is implemented.
My example above is 1 day, but that is just a dev server on local network.
One strategy is to always refresh the access token with every request and have a cron job that makes a simple request once a week to keep the refresh token alive.
OK, so added the following to the Oauth2v2 node to save an expiry time stamp (- 2 min)
var expiry = Date.now() + (msg.payload.expires_in * 1000) - 120000;
global.set('farmos_token_expiry', expiry);
Then the new Refresh Node checks the current time against that and refreshes only if needed. The refresh node requires no configuration, so you can use one Oauth2V2 node to create a web style login on the dashboard then use the refresh node at the start of flows.
Arsenal of tools building up
Cool.
As a Iron Maiden fan I would say up the FarmOS rather than up the irons… 
@Farmer-Ed
Just a thought…
Is it somehow possible to send multiple POSTS in one FarmOS api node?
farmOS comes with the Subrequests module, which enables packaging multiple API requests into a single HTTP request. The project page has some docs/examples.
I haven’t worked with it myself, but I believe others on this forum have! (@paul121? @jgaehring? @Symbioquine? @Farmer-Ed?)
I’ll just leave this here… Automatically group requests via subrequests · symbioquine/farmOS_asset_link@412fec2 · GitHub 
The plan is for a subrequests node, I haven’t looked too closely yet but I got a few pointers from @Symbioquine and @paul121. It hasn’t been very high up on on my todo list purely because I don’t have a very large number of animals and therefore don’t generate very large batches of logs or assets via the API. Plus I use a lot of group actions anyway so often one log per group does the job.
I will get to it eventually, I guess @Symbioquine’s last post is worth a read, which I’ll have a good look at that after I recover from what’s been a long day hauling cattle to the home farm and trying to convince 700kg+ cows to stand relatively still on a 1.5M scales. 
Ok. It’s not a problem. I was just curious.
And it probably makes my path less bumpy this way 
If it was possible, I figured it was worth trying to implement it from the start.
Hopefully there’s a 
or two for the farmer in the end