Use case
For many reasons, farm data can be sensitive. Part of our commitment to our users is that their data should default to private unless they explicitly share it. Once use case where this is particularly important, is when the users answers additional survey questions
Work in progress
Background
gbathree 1:48 PM
Hey guys, Kevin from LiteFarm is querying surveys they are using from their DB - he had a question about authentication (the surveys contain some private data)
Kevin Cussen 1:49 PM
Howdy!
I was hoping to get some help with one of our use cases
LiteFarm is making a callout to https://app.surveystack.io/api/submissions/...
We'd built the integration assuming surveys would be public and now we're seeing folks making private ones
So Greg suggested rather than passing in a token (which would take time for us to build) you might be able to just whitelist or server or some such
Does that make sense?
December 5th, 2022
Manuel Härdi 12:47 AM
Hi Kevin,"We'd built the integration assuming surveys would be public and now we're seeing folks making private ones"by saying "folks making private ones", you mean that your callout to https://app.surveystack.io/api/submissions/ does not return all survey data but only those parts not being defined as PRIVATE in the survey definition in surveystack?
gbathree 5:37 AM
Yes that's what he's talking about
Their server needs a token (at least that's one way to solve the problem)
Kevin Cussen 8:59 AM
Correct @Manuel Härdi
So if you point us to documentation on access and refresh tokens, we can do thatt
Or if there's something else you are able to do that wouldn't require engineering time, I'm all ears too
gbathree 9:00 AM
(or @will if you seeing this)
Manuel Härdi 2:07 PM
Most common solution would be to just add the auth header when calling surveystack. Thats a userid and a token (i'll supply docs). Depending on the use case, the auth credentials you use are system wide and fixed, or defined per user in its profile settings (edited)
Kevin Cussen 2:08 PM
For our case, it would be per certifier
So I assume we'd just need to hold an extra column in our certifier table for access / refresh tokens
image.png
Manuel Härdi 2:11 PM
Makes sens, though you wont need a refresh token (our auth mechanism is more like in Slack, as opposed to OAUTH
Kevin Cussen 2:13 PM
OK
Manuel Härdi 2:13 PM
Often thats called API KEY
You could certainly use that new col for other integrations
Kevin Cussen 2:14 PM
Do you have doc on that / those endpoint(s)?
Manuel Härdi 2:14 PM
Yep, i'll provide it later as i'm on the road.
Manuel Härdi 2:16 PM
Btw only alternative to auth i can think of: prevent surveys from having private data - but i guess you can't influence that?
2 repliesLast reply 2 months agoView thread
December 6th, 2022
Manuel Härdi 6:14 AM
How to define the request header:Requst url example: GET http://app.surveystack.io/api/submissions?survey=60d20b292f38fe0001916497
header key: Authorization
header value format: email token
header value example: test@test.com 6575c307-de99-4df9-876a-c78571ee86c7There's no place in the UI yet where that token could be copied by users, we could add that if required@will feel free to comment / correct (edited)
December 9th, 2022
Kevin Cussen 4:57 PM
Could we meet early next week? I'd like to better understand how we could retrieve the token.
The use case is this: We want the survey itself to be available to view and input data into without any credentials. Once a user submits a survey, that data should then be hidden.
We would like to be able to use the token of the survey creator (not the users that fill out the survey) to log-in and get the data.
December 10th, 2022
gbathree 10:32 AM
The user need to submit to your organization, in which case your orgs admins can see the results. So you just need a token for an admin of your group.1
We are reevaluating the group permissioning structure so I do understand there's some improvement there on our part
So for example a token for your user would work
December 12th, 2022
Kevin Cussen 10:28 PM
OK, so we could have one administrator token for each certifying body and whenever a user submits to that certifier, they submit via that certifiers token (names would be included in the submission documents - so no confusion about the submitter). We would then retrieve the data also using the administrators token. Do I understand correctly?