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
Since #241 we have cookie-based authentication. This solved the issue of opening images that require authentication. However, this approach only works for images on the same domain. If you'd visit example.com, where you'd login, and show a private image from atomicdata.dev, you would not be able to see it, because example.com's JS will not be able to set a cookie due to security.
So how do we deal with this?
We still want to have cross-domain authentication for automatically downloaded things
We can't set custom headers, because images requested automatically by the browser. Only the cookies for that domain are included
Set a cookie server-side
This is the de facto standard way of doing things. Servers control authentication and identies. We could add a /cookie endpoint, which returns a server-signed cookie (JWT) that proves to the server that the user is authenticated.
This approach is feasible, but it also feels like unnecessary complexity. Since the client owns the private key (and not the server), there is no need for the server to sign anything. It just adds another point of failure.
Add a query parameter with some token
Instead of requesting atomicdata.dev/myimage.png, you'd request atomicdata.dev/myimage.png?authResource=asdf. The client adds this token, which encodes an Authentication Resource (i.e. the same content as the cookie)
This means the client will need to add this query param to all image URLs.
Proxy all the images
Instead of requesting atomicdata.dev/myimage.png, we'd request example.com/proxy?url=atomicdata.dev/myimage.png. The proxy could then re-use the Authentication Resource created by the client, and gain access to the image.
This approach has a couple of downsides:
The proxy server can now access the image. This is not very privacy friendly.
It will be far slower because extra roundtrip, the image will load 2 to 3 times slower.
The proxy server will have far more work to do, which makes performance worse for other users.
The text was updated successfully, but these errors were encountered:
joepio
changed the title
Cross domain requests. I wasn't yet able to set cookies in such a way, that they would be scoped to one domain that is different from the current domain. This means that setting an image on a private drive on atomicdata.dev, and then visiting that image from a different domain, would not actually work at this moment. EDIT: As @rescribet noted below, it is not possible to set a cookie using JS for a domain other than the domain where the script originated.
Cross domain requests.
Jan 5, 2023
joepio
changed the title
Cross domain requests.
Cross domain authentication (using cookies?)
Jan 5, 2023
Since #241 we have cookie-based authentication. This solved the issue of opening images that require authentication. However, this approach only works for images on the same domain. If you'd visit
example.com
, where you'd login, and show a private image fromatomicdata.dev
, you would not be able to see it, becauseexample.com
's JS will not be able to set a cookie due to security.So how do we deal with this?
Set a cookie server-side
This is the de facto standard way of doing things. Servers control authentication and identies. We could add a
/cookie
endpoint, which returns a server-signed cookie (JWT) that proves to the server that the user is authenticated.This approach is feasible, but it also feels like unnecessary complexity. Since the client owns the private key (and not the server), there is no need for the server to sign anything. It just adds another point of failure.
Add a query parameter with some token
Instead of requesting
atomicdata.dev/myimage.png
, you'd requestatomicdata.dev/myimage.png?authResource=asdf
. The client adds this token, which encodes an Authentication Resource (i.e. the same content as the cookie)This means the client will need to add this query param to all image URLs.
Proxy all the images
Instead of requesting
atomicdata.dev/myimage.png
, we'd requestexample.com/proxy?url=atomicdata.dev/myimage.png
. The proxy could then re-use the Authentication Resource created by the client, and gain access to the image.This approach has a couple of downsides:
The text was updated successfully, but these errors were encountered: