ref: Change default Firebase ruleset #348
Conversation
…participantID in Firebase
RobertGemmaJr
requested review from
digicosmos86,
hetd54,
anna-murphy and
broarr
|
Visit the preview URL for this PR (updated for commit 6a05569): https://ccv-honeycomb--pr348-ref-rules-jarj54dj.web.app (expires Mon, 18 Dec 2023 20:18:35 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 Sign: 4ace1dcea913a952d2a1af84b94a4421bf36e610 |
| if participantID in get(/databases/$(database)/documents/registered_studies/$(studyID)).data.registered_participants; | ||
| // Allows any combination of studyID and participantID to be created in Firebase | ||
| if true | ||
| // Forces participantID and studyID to already be in Firebase to log in |
There was a problem hiding this comment.
Is there a way for researchers to preregister the participantID and studyID into Firebase? Perhaps add a link to the instructions here? And update documentation?
Also, part of me kind of feels like there should be a stricter default than a looser one. And then the documentation should make it clearer. However, from the way this PR is framed it sounds like like most researchers have pivoted to prolific and this is somewhat archaic
There was a problem hiding this comment.
Yeah, the idea of pre-registering participants isn't really a thing for online studies. It's mostly a hold out from clinic based studies where the participants are registered way ahead of time.
I'll add a comment for a discussion post on this though!
This ruleset allows the creation of
participantIDs andstudyIDs at runtime when using firebase. This is needed for working with Prolific which the majority of Firebase users are using at this point. I figure I'd just change the default rather than walk each lab through the change.Also fixes an issue with the Content-Security Policy that was preventing API access to Firebase.
This is a change for version 3.3 of Honeycomb, merging into a holding branch