Login to ODK Central using appuser token

[spwoodcock]

What high-level problem are you trying to solve?

• appuser tokens give access to specific forms.
• Currently login to Central is via username and password for site-wide auth.
• It would be great if an alternative login flow was possible: login using an appuser token, where the user has restricted access / goes directly to the project detail page, with access only to the forms that the appuser has permissions to see.

Possible useful scenarios:

• Open up flows for external apps to easily open up pages directly in ODK Central, such as the submission details page, or form editing page.
• Some users manage multiple forms within the same project, where each manager should only access a subset of the forms (discussed at ODK Summit). This would enable access to the form on the Central UI, without needing to make multiple site-wide roles on the instance.
• We could also use the built in appuser permission levels, as an alternative to creating lots of new site-wide role types for specific requirements (e.g. a user than can only edit a specific form).

Any ideas on how ODK could help you solve it?

• Currently the API supports auth via appuser token.
• I imagine it wouldn't be a huge lift to enable login to the UI using appuser tokens too?

[seewhy]

This sounds interesting.

Sorry to hijack, but maybe would also solve / move forward an earlier idea:

Restricting web user access to specific forms within a project

Not sure if this is actually a support request or an idea... Please reallocate accordingly 1. What is the issue? Please be detailed. Context: I'm building a plugin for QGIS (yes, another one) that uses the API to download submission data (and hopefully will integrate pyODK shortly, once I can figure out how to manage the Pydantic dependency within QGIS! That will hopefully allow the plugin to work "bi-directionally" with entities when the relevant functions escape into pyODK) I…

Specifically you mention...

@spwoodcock

Currently the API supports auth via appuser token.

Does that also (potentially) mean that if access to Central via an appuser token were implemented, we could access the submissions from the relevant form(s) for that appuser (and accessible Entities) from the API instead of needing a webuser? That could be a really useful tool for QuODK to manage access more effectively / with some granularity (assuming the right strategy for app users!)...

[spwoodcock]

Thanks for linking the other thread! That was exactly the idea I had in mind

Yes, I think having the option for adding user credentials OR appuser token in QuODK could solve your problem!

The docs reference here says 'App Users are only allowed to list and download forms, and upload new submissions to those forms.', so I think appuser tokens can possibly only be used for a subset of the API.

Viewing submission isn't included in the actions there though, so it would need a bit of testing to confirm if viewing / downloading submissions is possible via appuser token

[seewhy]

@spwoodcock

Viewing submission isn't included in the actions there though, so it would need a bit of testing to confirm if viewing / downloading submissions is possible via appuser token

I agree that it's not currently possible to download submissions - I had been looking closely at the docs in the early stages of development... In my naivety I'm hopeful that because there is essentially two-way traffic (i.e. download form, upload submission) with the appuser token, it might 'just' require building out using existing procedures rather than a whole new process... However, I wonder if it would cause security issues with Android devices potentially able to download submissions? Which might be why this hasn't been implemented?

But the idea seems simple, so obviously I like it