Restricting access to stimuli files

Skip to first unread message

Becky Gilbert

Oct 12, 2020, 8:07:54 PM10/12/20
Hi all,

Is it possible to restrict access to stimuli files that are stored inside the study folder in study_assets_root? I assume this might be possible by changing the parent folder permissions - is there any other way? Also, is possible to allow only one particular participant to have access to each stimuli file?

Longer version, for context: I'm working with a researcher who is running a study in which participants record videos of themselves and then watch their own video in a later session. The videos will be uploaded onto our server via a non-JATOS-hosted page, and then these files will be moved into the JATOS study folder so that they become available for the later session. The videos also need to be watched/approved by the researcher after being uploaded and before the participant watches them. We're trying to do all of this in a way that is automated and/or can be done via the JATOS GUI (so that the researcher doesn't need direct access to the server).

So far, the solution we've come up with is to schedule a cron job on the server that regularly transfers the newly-uploaded video files into the study's JATOS directory. After a file is transfered, the researcher can watch it by logging into the JATOS GUI and running a component that no one else has access to (it won't be part of the normal study flow). After watching the video, the researcher can add the file name to an 'approved' list that's stored in the study's batch data. Then, when a participant accesses the study link, in the JS we check to see if their video file (1) exists in the stimuli folder and (2) is listed as 'approved' in the batch data. If these conditions are met then the participant will be shown their video, otherwise they'll get a message on the screen. The problem with this is that *I think* the video files are publically accessible once they're inside the study folder, right? So if someone knows what they're doing, they could potentially watch any of the videos in the folder?

One other solution I thought of is to move the "video checking" step into a different JATOS study, so that the researcher can still check the files via the JATOS GUI, but without moving the files into the 'real' study before they've been checked. Then we'd need to set up another cron job that moves files from this 'checking' study to the 'real' study, as long as the file name is listed in the batch data (so this would also require querying the database). This would mean that the video files don't appear in the 'real' study folder until they've been checked. However this still doesn't solve the problem of participants potentially being able to view the other participants' approved videos, since these files would all be stored in the same study folder.

I'd really appreciate any thoughts/suggestions on how we could set this up so that access to video files is restricted to specific participants. And we're happy to hear solutions that are complicated, involve a lot of server-side changes etc. The things we're most concerned about are protecting participant's data privacy, and avoiding a workflow that requires the researcher to have direct access to the server.

Thank you!

Elisa Filevich

Oct 13, 2020, 2:41:32 AM10/13/20
Hi Becky,

I'm not sure this will be the solution for all the features you need, but it might be:
Since JATOS v.3.5.1 participants have the possibility of uploading arbitrary files (like videos) using jatos.uploadResultFile ( I'm not sure if you know this but your description of the problem, where participants upload videos to the JATOS server outside of JATOS makes me think you might not. Now you can do it all within JATOS. 

These uploaded files are available only within a single study run, so they are available for the participant who uploaded them only. 
The are also available to the experimenter, by going to Export Result Files ( in the GUI.

So, if you need participants to access the files only at a later session, this is what I would do:
- Say you have a study with components 1,2,3. Component 1 is the gatekeeper. If it's a new participant, they will be directed to component 2 where they do the task, upload the study, etc.
- At the end of component 2, do not use any of the jatos.endStudy or jatos.startNextComponent functions. Instead, simply display a message telling participants that 'they can now close the tab'. This will keep the study unfinished, and participants will be able to come back to it later. Set a flag in the batch session data where you have the subjectID and a value that tells your JS whether the video was uploaded. 
- Have the experimenter check the video from the GUI. Once they approve it, they can edit the batch session data and change a flag that tells your code that the video was approved. 
- Now participants can use the same link to start the study from component 1. Your code will read the flag in the batch session data (corresponding to the subjectID's entry) that the video was approved, and redirect participants to component 3. Participants can now see the video, and at the end, finish the study. 

I *think* this does all you need, but might have missed something. 
Hope it helps!

You received this message because you are subscribed to the Google Groups "JATOS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Kristian Lange

Oct 13, 2020, 4:49:43 PM10/13/20
Hi Becky,

Using the file upload feature, like Elisa suggested, is probably the best way, but I have another idea that I want to share. You are right in that all files in the study assets folder are accessible by all workers of this study. Each video can be downloaded by a worker provided the worker knows the file name. And this might help in your problem: using impossible to guess filenames like UUIDs. Nobody is going to guess e.g. 7698918f-ce43-47b2-be57-a4914b6da646 and there is no possibility to list the content of a study folder. You can store all your videos, each with a different UUID as a filename, in the study assets folder. The only problem then is to pass on the filename to the study's JavaScript without revealing it to all workers like one would do with the JSON Input Data or the Batch Session. But for this you can use URL query parameters: put the filename as an extra query parameter at the end of each study link. Those parameters are then accessible in your study's JavaScript via jatos.urlQueryParameters.


Becky Gilbert

Oct 16, 2020, 3:21:59 PM10/16/20
Hi Elisa and Kristian,

Sorry for the delay getting back to you, and thanks very much for your extremely helpful responses.

Elisa - I did know about the new jatos.uploadResultFile function - thanks very much for adding this feature! We're running an older version of JATOS on our server, and didn't think it would be worth upgrading just to handle the video uploads, which is why we set up the non-JATOS upload page. But I didn't realize that we could do both the video upload and video re-watching sessions using the same JATOS study, which beautifully solves the problem of having to move files around. That's a much better solution - thanks!

Kristian - ah, I didn't realize that it's not possible for the user to browse the whole contents of the study folder, and that they have to know the specific file names they want in order to request them. So the UUID solution sounds great. And even if I knew this, I don't think I would've thought of using URL query parameters to get around the problem of revealing all the file names to all participants. Brilliant.

Thanks again to both of you! :)

Reply all
Reply to author
0 new messages