There is no way to determine the user ID when connecting through the API

[paulmueller]

CKAN version
2.8

Describe the bug
It is not possible to determine a users ID when connecting through the API. In my opinion, this should be the default behavior of user_show, but the documentation states that either the id or the user_obj parameter must be given. I think it would be user-convenient to change this default behavior.

Steps to reproduce
Connect via API using an API key and call user_show without arguments.

Expected behavior
The information about the currently logged-in user is shown.

Actual behavior

{"help": "https://dmoain.tld/api/3/action/help_show?name=user_show", "success": false, "error": {"message": "Not found", "__type": "Not Found Error"}}

[paulmueller]

Note: A workaround is to iterate over user_list and check whether the API key matches the apikey value (which is only set if authorized).

[wardi]

Instead of changing user_show let's add a new action id_for_current_user_show or similar that returns just the user id when someone is logged in. IIUC this should be harder to abuse with XSS attacks because it requires another round-trip to get actual user details (security experts please weigh in if you know better)

[jqnatividad]

@shubham-mahajan @wardi just pinging to see if PR #5504 is still WIP.

[shubham-mahajan]

@jqnatividad From my end PR is done, let's wait @wardi to review.

[paulmueller]

Any updates on this one? The workaround I mentioned before does not anymore work with API tokens. A new workaround is to check whether "email" is set for a user in the user list.

[shubham-mahajan]

@paulmueller It is agreed in (#5504 (comment)) that we will not be using a separate method but will create a flag in the request for that.

I will create a PR soon for that

[paulmueller]

@wardi I just updated from CKAN 2.9.4 to CKAN 2.9.5 and realized that #6338 did not get merged into the 2.9 branch. Is there any particular reason for that?

I checked

• https://github.com/ckan/ckan/blob/dev-v2.9/ckan/logic/action/get.py#L1368
• https://github.com/ckan/ckan/blob/2.9/ckan/logic/action/get.py#L1368

The docs say that during a patch release, developers should cherry-pick commits which are labeled as "backports". How is this done? Or do I have to wait until 2.10 for this to arrive in production?

http://docs.ckan.org/en/latest/contributing/release-process.html#preparing-patch-releases

[wardi]

@paulmueller new features aren't backported in case they cause issues for current users.
If you need this feature in 2.9 the simplest option would be to create a branch and backport just the feature(s) you need. Once you upgrade to 2.10 this feature will be available without running your own branch.

[paulmueller]

👍 Thank you for the clarification.