qqmyers
commented
2 years ago This can open any GET calls that have side effects to a CSRF issue - we should assure we don't have any or add other protections before we open the api to session cookies.
Closed pdurbin closed 1 year ago
qqmyers
commented
2 years ago This can open any GET calls that have side effects to a CSRF issue - we should assure we don't have any or add other protections before we open the api to session cookies.
pdurbin
commented
1 year ago Today in an auth meeting I offered to create an issue but @GPortas just reminded me I already created this one! 😄
I just added "developers only for now" to emphasize that the new auth mechanism will be off by default and hidden behind a feature flag. Only developers will turn this on for now. Production installations should not turn it on due to CSRF (mentioned above) and possibly other security concerns. What we're trying to do is unblock development of a new React frontend.
pdurbin
commented
1 year ago @GPortas regarding the feature flag...
I pointed you toward this example which uses a database setting: https://guides.dataverse.org/en/5.12.1/installation/config.html#allowapitokenlookupviaapi
However, these days we're trying to use MPCONFIG (MicroProfile Config API) instead. @poikilotherm wrote extensive docs here: https://guides.dataverse.org/en/5.12.1/developers/configuration.html
I'm not sure the best example of an MPCONFIG setting for you to look at. Maybe Oliver can suggest a straightforward one.
mreekie
commented
1 year ago closed by IQSS/dataverse#9290
Overview of the Feature Request
In order to use a Single Page Application (SPA) architecture, the SPA (written in React, Vue, Angular, Web Components, etc.) needs to be able to authenticate against Dataverse APIs.
What kind of user is the feature intended for?
Frontend developers using React or similar.
What inspired the request?
https://github.com/GPortas/dataverse-react-poc by @GPortas relies on a fork of Dataverse at https://github.com/GPortas/dataverse/tree/session_api_auth that allows a JSESSIONID session cookie to be used to auth against the Dataverse APIs.
To use the words from the README:
"In particular, this PoC focuses on testing the following points:
It is necessary to locally deploy Dataverse with this branch: https://github.com/GPortas/dataverse/tree/session_api_auth
That branch has the JSESSIONID cookie Native API auth implemented, necessary for this PoC."
Any related code?
If we were to accept the changes as-is, they can be previewed here:
https://github.com/IQSS/dataverse/compare/develop...GPortas:dataverse:session_api_auth
Any related open or closed issues?