-
Notifications
You must be signed in to change notification settings - Fork 486
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add MyData API to dataverse documentaion #9596
Conversation
@sirineREKIK thanks for the pull request! Can you please take a look at these errors? https://github.com/IQSS/dataverse/actions/runs/4989177823/jobs/8932750403?pr=9596 Thanks! (I'm giving this a size 3 because it shouldn't take much effort to review and QA.) |
Parameters: | ||
|
||
``key`` is the user token, for this API is must not be passed in the header. | ||
``role_id`` User roles, several possible values among: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Roles are customizable. Standard roles include:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. I think my only minor comment is that roles are customizable (i.e. by https://guides.dataverse.org/en/4.15.1/api/native-api.html#id24) so the values shown as parameters are only examples, not all possible values. It would be nice to have a change before this is merged, but I don't think it should be slowed down for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't tested this and I'm wondering about the "key" thing but I left a little feedback. Thanks for working on this, @sirineREKIK! ❤️
export PUBLISHED_STATES=Unpublished | ||
export PER_PAGE=10 | ||
|
||
curl -H GET http://$SERVER_URL/api/mydata/retrieve?key=$API_TOKEN&role_ids=$ROLE_IDS&dvobject_types=$DVOBJECT_TYPES&published_states=$PUBLISHED_STATES&per_page=$PER_PAGE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- -H with no header?
- sending -H with the API token is preferred to sending "key" (I just noticed the note about key below.) 🤔
- I'd suggest removing GET since it's the default
- https is preferred over http
- I'd replace
http://$SERVER_URL
with$SERVER_URL
- I'd put quotes around the URL because of all the
&
characters. Bash will get confused.
|
||
Parameters: | ||
|
||
``key`` Is the user token, for this API is must not be passed in the header. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this true?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we have a release note snippet as well, please? For now (sorry), please see this issue:
Co-authored-by: Philip Durbin <philipdurbin@gmail.com>
Can you check if everything is ok or if we need to do something else please? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://dataverse-guide--9596.org.readthedocs.build/en/9596/api/native-api.html#mydata looks reasonable but I haven't tested it.
@kcondon if you could verify that indeed the API token can only be passes as a query parameter ("key") for this API rather than as header (curl -H ...), I would appreciate it!
I am able to access this endpoint when passing the api_token ("key") in the header: curl -H "X-Dataverse-key:$API_TOKEN" "$SERVER_URL/api/mydata/retrieve?role_ids=$ROLE_IDS&dvobject_types=$DVOBJECT_TYPES&published_states=$PUBLISHED_STATES&per_page=$PER_PAGE" This should be the preferred method since it is more secure. @sirineREKIK Would you mind updating the document to use the header or is there something we are missing here? |
Hello, curl -H "X-Dataverse-key: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" "https://demo.dataverse.org/api/v1/mydata/retrieve?dvobject_types=Dataverse&dvobject_types=Dataset&published_states=Published&role_ids=8&per_page=5" | jq . Also it is always the same return for all our installation environements. |
@sirineREKIK Thank you for that information. I was able to reproduce the problem. I still believe passing the key in the header is the correct syntax since all of my previous testing with endpoints has confirmed this is the correct method. However, I do not yet know what's wrong in this case. Also, please note that this syntax is working on my test server. |
@sirineREKIK Ok, I have found the problem but don't know why yet. Release v5.13 appears to fail when passing the key in the header for this endpoint but works for others. in v5.14, due out soon, it works passing it in the header. So, I think we should therefore go with the header form. I'm checking here to see what's changed in the code that might have affected this endpoint. I know there was a roles change but thought it was about creating new roles and inheritance. |
@sirineREKIK It's been confirmed that due to other work in this area, the header behavior was fixed in v5.14. So, let's go with the key in the header format. Thanks! Regards, Kevin |
@kcondon Thank you for that information. Changes are taken into account. |
@sirineREKIK Thanks, it looks great! |
I'm glad the header works! Probably due to recent auth refactoring? 🤔 Not sure. 😄 |
@pdurbin Yes. Guillermo fixed it. I believe this unpublished api implementation predated our move to using the header as a more secure way of passing info. So, really was just never implemented, I think? |
add MyData API to dataverse documentaion