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.

Reply to this note

Please Login to reply.

Discussion

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. đŸ˜