Comments (13)
I'm a little confused about the title, do you mean CORS rather than CSRF?
In your case, how would you get hold of a valid DKC token on your app?
from girder_web_components.
It shouldn't be necessary. If you hit the login endpoint, girder sets the auth cookie for the server's domain via a response header.
from girder_web_components.
Sorry, I mean CSRF because an active session cookie with data.kitware.com is necessary for domain.example.com to run the above application and load the video.
My app gets a token when a user logs in with GWC's own Auth component and stores that token in domain.example.com's cookie jar. This does require CORS to be enabled for domain.example.com, but that isn't enough to load the video.
@jbeezley what are the conditions required for this? When I hit /user/authenticaton
, the Set-Cookie
header only appears if my request originates from data.kitware.com. If I hit /user/authentication
from another domain, no Set-Cookie
header is present.
from girder_web_components.
Good point. I think it will work if you add this:
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#Sending_a_request_with_credentials_included
from girder_web_components.
I'm not quite sure how to use that to fix this issue.
I tried making the authentication request with fetch instead, and I get Access to fetch at 'https://data.kitware.com/api/v1/user/authentication' from origin 'http://localhost:8081' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'.
I believe this is a regular browser CORS issue: Chrome won't set cookies for data.kitware.com
when a request originates from another domain. I don't think you can force a browser to do with fetch.
Does that make sense, or have I used fetch wrong?
fetch('https://data.kitware.com/api/v1/user/authentication', {
headers: {
'Girder-Authorization': 'Basic ......',
'Girder-Token': null,
'Origin': 'http://localhost:8081',
'User-Agent': 'Mozilla',
},
credentials: 'include',
mode: 'cors',
method: 'GET',
}
from girder_web_components.
Yeah, I guess it will only allow you to do that if you white list a specific domain.
from girder_web_components.
My app gets a token when a user logs in with GWC's own Auth component and stores that token in domain.example.com's cookie jar. This does require CORS to be enabled for domain.example.com, but that isn't enough to load the video.
Is this authenticating against DKC, or against domain.example.com?
from girder_web_components.
App running on domain.example.com, authenticating against DKC using gwc/Auth/Authentication.vue
from girder_web_components.
Ah yes. In that case you'd need to white list the domain explicitly, which makes sense when you consider the security implications here (if you pretend your site was a malicious site, for instance)
from girder_web_components.
If this is for a demo site or something, or an app, I'm fine with whitelisting it on DKC.
from girder_web_components.
I think you addressed that by allowing cookie-authentication only for downloads
endpoints. As it stands, any malicious site could already display protected data in girder if it knows the URI.
Rather than relying on the girderToken cookie set by DKC, girder could allow query string based authentication for media on a page.
From domain.example.com, I want to be able to do this:
<img src="https://data.kitware.com/file/:fileid/download?token=mytoken">
This is easier than having to white-list domain.example.com explicitly, especially if the person developing domain.example.com isn't a DKC admin, or even some other entity not endorsed or managed by Kitware.
One of the major strengths I see in GWC is that it allows non-privileged users to develop and deploy apps that use any instance of girder. This feature would enable developers to embed girder-managed data into their own apps on any domain where CORS is enabled.
I suppose what I'm confused about is why you would enable CORS for *
(such as DKC does) when you really want to restrict CORS capabilities to a white list.
The security implications are, as far as I can tell, no different with or without this feature.
from girder_web_components.
I suppose what I'm confused about is why you would enable CORS for * (such as DKC does) when you really want to restrict CORS capabilities to a white list.
We don't want to restrict allowed origins to a white list, but browsers insist on white list policies for certain functionalities like the one you're trying to do. As such, I'm happy to add a whitelist in addition to *
to enable your use case. (Girder lets us have both *
and explicit domains in a list IIRC.)
from girder_web_components.
I'll follow up if it turns out the whitelist addition is needed. Mostly I'm just trying to figure out if allowing cookie auth for video and img resources is the best way to grant access to protected resources for every use case.
I think there are times when token-based auth would be more convenient, but those cases may be rare enough to deter this addition. Going to close this issue for now.
Thanks, @zachmullen!
Edit for historical record: Token-based auth would allow a developer to reliably display content without being domain-whitelisted, but using/reading/modifying the resource with a canvas still wouldn't be possible.
The ability for non-whitelist origins to display authenticated content from girder when a session is active is probably more of a harmless by-product than an actual feature.
from girder_web_components.
Related Issues (20)
- Upload list rows don't flash to "done" before they disappear.
- Explore using semantic-release HOT 9
- Yarn upgrade causes some unit tests to fail
- revert html boolean attributess back to shorthand form.
- support webkitdirectory for uploads
- [feature] Support page skipping in data browser
- General documentation improvements.
- Add an option to hide password based registration HOT 3
- Refactor OAuth component
- Dark theme UI bug in uploader widget
- Markdown Preview for girder-upsert-folder broken in dark mode.
- [BUG] [Girder-Upload] Upload doesn't tolerate very large numbers of files. HOT 4
- [Feature] Forgot Password Dialog and Girder API connection
- Upper limit on parallel uploads HOT 1
- Make Vue a peer dep
- Don't swallow uncaught errors during upload
- SSRF vulnerability in axios version < 0.21.1 HOT 5
- Still getting CSS issues in >= 3.0.1
- Show better error for email verification required HOT 2
- Fix vuetify and typescript in docs
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from girder_web_components.