In extension to below information, we have some related questions, springing from my colleagues’ attempts to create a replacement for the web asset server:
When a request to view an attachment is sent to the web asset server, it does not contain any token with information on the user making the request. Without this, we can’t use the permissions information to decide whether to serve the asset or not. How would we possibly be able to get this kind of information? In other words, is there anything in the headers being passed that can be used to identify the user session?
Can we perhaps use the audit log or some other log to determine the user making a request?
I imagine you wish to house some sensitive attachments on the Web Asset Server that should only be accessible to some users?
Unfortunately, there is not an easy way with the current Web Asset Server to facilitate user identification for GET requests (i.e., viewing an attachment); there inherently is no user-identifiable information expected in requests made to the Web Asset Server.
I would imagine the closest thing the Web Asset Server natively has for this is the REQUIRE_KEY_FOR_GET setting, which if enabled universally requires GET requests to include a token parameter (similar to requests with side-effects).
Ultimately it depends on your security requirements, but if you are implementing your own asset server, or a middleware to sit “in-front” of the Web Asset Server and extend its functionality, then there may be some options available to you.
Is the intuition behind utilizing the Audit Log to check whether the requesting user created (or modified) the associated attachment (and/or related record)? In theory, such an approach is possible (though might be susceptible to impersonation). Could you expand on this suggestion?
If you are utilizing the Specify API, perhaps an implementation could leverage the session cookie set by Django’s PermissionMiddleware? Each request made from an authenticated client will have a cookie (which by default is called sessionid).
Server-side, Django stores session information (like the logged-in user) within a session which uses the sessionid as an identifier. Naively, I would suggest a similar framework could be implemented in a replacement/middleware for the Web Asset Server: perhaps even directly using this sessionid in whichever implementation (though authentication might still be necessary to ensure the request(s) originated from a verified and authenticated Specify 7 API session).
Otherwise (or in conjunction with the previous suggestion), I would suggest utilizing a standard authentication approach with OAuth 2.0 and/or JSON Web Tokens.
I’d be happy to discuss possible further implementation ideas! Are there any additional questions you have?