Use Archive Token from requests instead of setting

[LTDakin]

Archive Token from Request

• add token capture middleware that grabs the authorization header from the request to store in a cache and use it when making archive requests in get_archive_url
• update readme now that manual setting no longer needed for local dev
• remove ARCHIVE_TOKEN from settings since its no longer needed

bonus:

• moved api paths to api group, since they also are under the api/ tree

Warning: When deploying this PR remember to remove the ARCHIVE TOKEN setting from the helm charts or wherever we populate settings

[mgdaily]

I think if we want to pass through the user's API token we need to think about it a bit more carefully. I don't think setting a global cache key is going to scale, unfortunately.

[mgdaily]

So this cache doesn't differentiate between users. What happens if one user sends a request to the backend, the token gets set, and then another user overwrites the token by sending a request? It seems hard/impossible to guarantee that the token will be set correctly per user, per request with possibly hundreds or thousands of requests coming in at once.

[LTDakin]

I looked into it a bit and it seems like threading().local might be an option to store it? I read online some people store the request in the local thread so its accessible throughout the app. Wondering on your thoughts if this could be a solution?

[jnation3406]

Rather than caching it, you can just place it in the request object so the things using it downstream have access to it. You can also just ignore using a middleware and get it out when you need it from the headers in the request.

[LTDakin]

thing is, I use it in a util function called get_fits thats called basically everywhere, so we'd have to pass the request object to every function as an argument. So I was looking for a global scope to store it in, unless theres a way to access the request object from anywhere already? Putting it in local() seems like a common thing people do

[jnation3406]

I think I would just pass it where it needs to go... I haven't used local stuff before but maybe that is okay too?

[mgdaily]

I think it's fine to have a super user archive token here. I don't think we necessarily need to set it per-user, as the UI will only be requesting images that the user has access to.

[jnation3406]

The point of doing this is to have the users own token passed in so the permissions they have is enforced. Right now using a superuser token, anyone could manually make a datalab api request for data they don't have permissions for and get it, so its a security issue.

[LTDakin]

tested out threading local but its a little too much just to take care of having an auth token for archive requests. Theres going to a refactor of the data to create an ImageData class so this is better added to that as introducing that class will change a lot about how images are fetched and data worked on.