Feature: optional JSON endpoint for data export #62

Open
opened 6 months ago by max.mehl · 0 comments
Owner

Problem

Right now, if a service or website (e.g. publiccode.eu or in future the fsfe.org website) wants to extract data from a forms application (e.g. pmpc-sign), this basically only works when this service is on the same server as forms, and reads forms' JSON file.

This is bad, since we do not want to couple services just because of this, or even cannot (in case of the FSFE website). Also, it is a security concern since this service could access all kinds of sensible data, e.g. signers of an open letter that did not want to appear publicly.

Possible solution

I propose an optional, configurable endpoint for forms. It would allow us to export certain data under certain conditions and make them available via a defined URL, ideally in a JSON format.

The fields that are exported should be customisable.

Example

Let's say I want to export a few things for the pmpc-sign application in forms:

  • total number of signatures
  • name, country and comment of every entry that has permissionPub = yes.

This could be available via https://forms.fsfe.org/api/pmpc-sign.json.

That can then be used in other services, e.g.:

Definition of fields and conditions

Probably, we need to settle on a basic language to define the exported fields and their conditions. IMHO this could be quite raw, like an SQL dialect, jq expressions or raw python, or something customised.

In any case I think we should make every field optional so that we don't expose unwanted data.

Blockers

This would actually remove the blocker for #25. But perhaps it's sane to do tackle #25 first and then immediately implement this feature so we don't have to tweak the same function twice.

## Problem Right now, if a service or website (e.g. publiccode.eu or in future the fsfe.org website) wants to extract data from a forms application (e.g. pmpc-sign), this basically only works when this service is on the same server as forms, and reads forms' JSON file. This is bad, since we do not want to couple services just because of this, or even cannot (in case of the FSFE website). Also, it is a security concern since this service could access all kinds of sensible data, e.g. signers of an open letter that did not want to appear publicly. ## Possible solution I propose an optional, configurable endpoint for forms. It would allow us to export certain data under certain conditions and make them available via a defined URL, ideally in a JSON format. The fields that are exported should be customisable. ## Example Let's say I want to export a few things for the `pmpc-sign` application in forms: * total number of signatures * `name`, `country` and `comment` of every entry that has `permissionPub = yes`. This could be available via `https://forms.fsfe.org/api/pmpc-sign.json`. That can then be used in other services, e.g.: * pmpc-website where you can define remote JSON data as data source: https://gohugo.io/templates/data-templates/#get-remote-data * JavaScript to replace a placeholder on a website (e.g. fsfe.org) with the actual numbers and data from the JSON endpoint ## Definition of fields and conditions Probably, we need to settle on a basic language to define the exported fields and their conditions. IMHO this could be quite raw, like an SQL dialect, `jq` expressions or raw python, or something customised. In any case I think we should make every field optional so that we don't expose unwanted data. ## Blockers This would actually remove the blocker for #25. But perhaps it's sane to do tackle #25 first and then immediately implement this feature so we don't have to tweak the same function twice.
florian.vuillemot was assigned by max.mehl 3 months ago
max.mehl added the
prio:mid
label 3 months ago
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.