You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the live recording mode uses a CORS proxy running on cloudflare for manual browser-based recording.
This is less than ideal, as the proxy needs to be given permissions for each origin that ReproZip is running on.
This also results in extra CORS headers being sent to the proxy for every request.
Instead, ReproServer should implement its own proxy.
The endpoint could be: https://staging.server.reprozip.org/results/<id>/proxy/https://example.com/
or just https://staging.server.reprozip.org/proxy/https://example.com/
as its not tied to the results, which would fetch the response for https://example.com/ and return the response.
For extra protection, the proxy should require some auth token to work, so that it doesn't become just a public proxy.
Maybe for that reason, it should be scoped to results/ and pass an individualized token to that is passed with each request, eg. like Authorization: Bearer <token> but maybe more custom, to avoid conflicts with real sites.
The same mechanism can then also be used for restricting access to port/<port>/.
@remram44 do you have any thoughts on this approach, for proxy and/or auth header?
The text was updated successfully, but these errors were encountered:
Yes I think we should do this. We should probably have some sort of short-lived token to protect it... do you use something like this to protect your CloudFlare account?
Currently, the live recording mode uses a CORS proxy running on cloudflare for manual browser-based recording.
This is less than ideal, as the proxy needs to be given permissions for each origin that ReproZip is running on.
This also results in extra CORS headers being sent to the proxy for every request.
Instead, ReproServer should implement its own proxy.
The endpoint could be:
https://staging.server.reprozip.org/results/<id>/proxy/https://example.com/
or just
https://staging.server.reprozip.org/proxy/https://example.com/
as its not tied to the results, which would fetch the response for
https://example.com/
and return the response.The proxy handler should behave similar to: https://github.com/webrecorder/wabac-cors-proxy/blob/main/index.js#L212
but simpler, as don't need to handle CORS, but do need to wrap 3xx responses as 200 for fetch
For extra protection, the proxy should require some auth token to work, so that it doesn't become just a public proxy.
Maybe for that reason, it should be scoped to results/ and pass an individualized token to that is passed with each request, eg. like
Authorization: Bearer <token>
but maybe more custom, to avoid conflicts with real sites.The same mechanism can then also be used for restricting access to
port/<port>/
.@remram44 do you have any thoughts on this approach, for proxy and/or auth header?
The text was updated successfully, but these errors were encountered: