Add ability to configure Facebook permission scope

[patcon]

Addresses https://github.com/pol-is/polisServer/issues/77

How's this look? ~~Is it ok to generate fake SSL certs like this for development -- could be helpful elsewhere too. The extra omgwtfssl docker image is very small and quick to download.~~

We're not forcing https redirect, so someone will still be able to access polis via http://

To Do

• [x] code spike
• [x] question: will polis work without email scope?
  • should, since anyone can choose not to give email now. #todo add e2e tests to see what happens.
• [x] document creation of FB app
• [x] document configuration of FB login
• [x] doc FB permission scopes
• [x] remove SSL cert container
• [x] ~~change FB app setup instructions to not require HTTPS~~ impossible https://github.com/pol-is/polis/pull/253#issuecomment-675039124
• [ ] get this working for dev-server too
• [x] ~~write e2e tests for FB login~~ wont-do https://github.com/pol-is/polis/issues/541
• [x] ~~set up github actions to run FB e2e tests~~ wont-do https://github.com/pol-is/polis/issues/541

[patcon]

The code rn is working as an MVP, if anyone wants to test.

Work that could also be done in this PR, if we wanted:

• is this SERVER_DATA approach suitable? It's set at runtime in one place (server) vs build time in multiple places (clients).
  • could we move FB_APP_ID into SERVER_DATA as well?
• should we automatically hide facebook login UI elements when FB app ID is missing or an empty string? (settings in client-admin, and social login buttons in client-participation)
• should we remove references to location data vestigial from user_location FB scope?

any and all of the above could be kicked into a later PR, or ditched

[patcon]

this __SERVER_DATA__ thing is seemingly a common pattern for react fwiw:

• https://www.algolia.com/doc/guides/building-search-ui/going-further/api-keys-security/react/#inline-the-api-key
• https://create-react-app.dev/docs/title-and-meta-tags/#injecting-data-from-the-server-into-the-page

If we're concerned with being able to serve built clients without proxying them through server component, we could do this: https://github.com/facebook/create-react-app/issues/1703#issuecomment-287681768

[patcon]

how this look to you, @urakagi?

[patcon]

Perhaps out-of-scope here, but just learned a good way to test login flows easily via test users:

• Facebook: Test Users
• Facebook: Testing Your Login Flow

@colinmegill worth our spinning up an issue for kicking the tires on some of these login flows, or you feeling pretty good about how robust they are?

[patcon]

My concern here is the introduction of fake SSL in the mainline docker-compose.yml.

Yeah, could use some thought. Thinking we could just not add an explicit depends_on, and then change instructions to be not be docker-compose up on the whole setup, e.g., docker-compose up --detach nginx-proxy.

Something like that would not deploy the fake cert.

There might be a more established way of leaving some containers off the up command.

EDIT: seems we're doing it the "right" way already: https://github.com/docker/compose/issues/1294#issuecomment-94196371

This might be a reason to use a Makefile to wrap some common and repeating usages of docker-compose 🤷

[ballPointPenguin]

EDIT: seems we're doing it the "right" way already: docker/compose#1294 (comment)

sure. So we just have to decide which combination of things should be the "default" and which should require an extra argument or more specific command.

I think I still have the opinion that in general the docker-compose should lean towards a development/demo type scenario, ie "I want to run this on my laptop and see what it does", plus development of specific modules while letting docker manage the others.

As such I don't object to the fake ssl and so on being part of docker-compose, but we might also consider keeping the whole thing in "dev" mode. Production deployment requirements are likely to be special and diverse enough that they will require special case-by-case considerations. I could be wrong about that (which would be delightful actually) and maybe a flexible enough docker-compose could be enough for nearly everybody.

The reason I'm being philosophical is because I think we are still on the journey towards deciding what comes in the box and what requires extra batteries and configuration, and for whom.

[patcon]

Seems I can note in Facebook app setup instructions to disable "enforce HTTPS": https://developers.facebook.com/blog/post/2018/06/08/enforce-https-facebook-login/

This makes the need for SSL in development a moot point, and allows us to kick the conversation down the road a bit.

I'm going to change that setting, add some tests, and open this PR back up for review.

[patcon]

Just found out that SSL is mandatory for FB login now, so we need to add some self-signed cert for testing (I can perhaps do it in cypress tests workflow):

https://developers.facebook.com/docs/facebook-login/security/#https

[patcon]

Removed omgwtfssl container, and instead using certs from #540

[patcon]

Going to pull Facebook docs into https://github.com/pol-is/polis/issues/541, and deal with this as just a tiny thing later. Moving to draft as its own of review for now