Exhibit permissions

[mynameisfiber]

Saves whether a user can access a particular exhibit into rethink and check permissions when the user hits the API. Responds with 403 when the user isn't allowed in.

I chose to do the rethink stuff a bit differently here than in the quantifiedSelf repo. I made a dbhelper file that does all of the heavy rethink stuff and you just create a new object that inherits from that and implements all of the logic. The only annoying part is the accessor function that maintains the global connection, but there's no real way around that. I think doing it this was will make it easier for each processor to deal with it's own rethink connection, if that processor needs an actual DB.

NOTE: the permissions stuff (as well as the checkin stuff) will use the gulperbase db... if a processor is making it's own connection to the DB it should have it's own DB. Remember, the end goal is to have every process be isolated and working on it's own machine.

[mynameisfiber]

@wannabeCitizen @peymanmortazavi tested and ready for review

[wannabeCitizen]

Immediate question for me is, "what constitutes needing a db?" Most exhibits are simply static JSON so should we go ahead and say "if you are never going to modify the DB in any way, no need to use rethink". Because if we want DB tables, it's easy for me to add that method into basically everything we have, but it doesn't seem necessary. I'm just not sure how clean we want our system to be, if static files are cool, it seems we can mostly roll with that without other reasons. Curious on your thoughts @mynameisfiber

[mynameisfiber]

basically the same rational you would normally have when deciding between flat files vs a database: do you need to modify the data frequently? will you need to slice/sort the data in different ways?

for the most part i think having things as flat files is fine for us... it may make some of the calls slower. For example, pr0n reads the file, decrypts it, saves any changes then re-encrypts and saves on API calls. It should have a database backing it, but we'll only have at most 24 users at one so I'm not worried about that for now.

I mainly put that big note because i saw before you had wanted to make a DB and I wanted to make a smooth path for that without messing with the future goal of separating everything.

[wannabeCitizen]

Great and thanks! Am going to read through code now.

I think when we expand the show and aren't running on a 4 mo timeline, we'll want to make use of DBs more so it's nice to have the infrastructure designed that way.