Thanks. Makes sense.
Only partial issue is unless the CDN also has an auth layer, youâre redirecting to a âanyone can readâ link. If member access is required, this doesnât work sadly. Unless you know of a one time key approach.
Thanks. Makes sense.
Only partial issue is unless the CDN also has an auth layer, youâre redirecting to a âanyone can readâ link. If member access is required, this doesnât work sadly. Unless you know of a one time key approach.
It sounds like you want ACLs on image reads. That is:
* unauthenticated user GET request -> 401 challenge
* unauthorized user GET request -> 403 forbidden
* authorized user GET request -> 200 OK
In that case, the authorization check could happen either at the stable proxy domain provider, or at the image hosting provider. Iâm guessing the former is where youâd want to put that logic.
But yes, if the image hosting provider does authenticate requests, then leaking the image hosting provider URLs could get your content backdoored.
A way to solve this is to have your stable domain provider authenticate with the image provider and include a short-lived token in the 302 URL. That way, only clients authenticated with the stable domain can GET the image hosted resources.
Whether this roundabout token business is worth it I canât say. đ