cache the access token in the system environement

[PietrH]

Maybe store the access token for a bit, similar to etn and rgbif

[PietrH]

We could also store the login credentials as a system variable (hashed i suppose!), as this is what rgbif actually does in the backend. Then we could keep calling get_access_token() as a helper in functions without the need to keep prompting the user all the time.

What do you think @SanderDevisscher ?

• Store the access token itself locally
• Store the access credentials locally

On second thought, the access token itself is probably safer, in case users reuse their password somewhere.

Ideally we'd want to use something like keyring for the authentication credentials. Something for the future perhaps.

[SanderDevisscher]

I have no clear preference. I personally would go with the easiest method to use/implement for now and look into more secure options in the future.

[PietrH]

I have checked if access tokes eventually get invalidated on the iAsset side without a request to do so (logout api post request), and it seems this is indeed the case.

So you can't just keep using the same access token forever, good.

[SanderDevisscher]

related but not a fix is to add password as a function parameter of get_access_token this allows for storing your password in the .renviron file just like rgbif. Unless you think this is a bad idea.

[PietrH]

I think we're best off caching the access_token itself, rather than the password. This will mean that users will probably need to login once in a while, which is not a bad thing. We can write get_access_token() to check for a local cached token, to try it, and if it doesn't work, to try to regenerate one prompting the user for a username and password.

[SanderDevisscher]

1 question though I'm looking into automating retrieval of vespawatch nests using github actions and I was just wondering if this will work if we cache the token instead of being able to provide a password as environment variable.

[PietrH]

1 question though I'm looking into automating retrieval of vespawatch nests using github actions and I was just wondering if this will work if we cache the token instead of being able to provide a password as environment variable.

This is an important design decision to keep in mind, can you make an issue for further discussion?

If we retrieve personal information via the API, we might need to make sure no data is stored unencrypted on the runner or in artefacts, and we might be obliged to process data in the EU only. I'm not sure on the specifics but we need to thread lightly. We are capable of using our own custom runners via AWS in a EU region, but it'll take a bit of doing and have a slight cost.

[PietrH]

I think we should probably allow passing the credentials as environmental variables. With this in mind I still think it could be useful to cache the token for a bit.

It's unclear how long a token remains valid. Any ideas? I'll send an email to support

[PietrH]

System tokens are valid for 24h