Implement server-side authentication

[rogerhutchings]

We need to handle auth on the server. Specifically, picking up user project preferences for determining workflow selection etc.

cc #365 #1132

Time estimate: 6 weeks

[rogerhutchings]

Okay, made some progress on this today with @camallen, to the point where I got a cookie passed along with the page request :tada:

Steps to reproduce

• Spin up a local copy of the Panoptes API, set up a new user, and get a client_id.

• Update config/initializers/session_store.rb b/config/initializers/session_store.rb with the following:

  Rails.application.config.session_store :cookie_store,key: '_Local_Panoptes_session', domain: '.zooniverse.org'

  (This step is optional, but helps you identify the cookie passed along with the request as being from your local copy of Panoptes.)

• Update the default block in config/cors_config.yml:

  default: &default
    headers: :any
    request_methods: [delete, get, post, options, put, head]
    expose: [ETag, X-CSRF-Param, X-CSRF-Token]
    max_age: 300
    allows:
      - {
          origins: !ruby/regexp '/^https?:\/\/(127\.0\.0\.1|localhost|[a-z0-9-]+\.local|10\.[0-9]+\.[0-9]+\.[0-9]+|192\.[0-9]+\.[0-9]+\.[0-9]+|[a-z0-9-]+\.zooniverse\.org|[a-z0-9-]+\.(pfe-)?preview\.zooniverse\.org)(:\d+)?$/',
          resource: "/users*",
          credentials: true,
        }
      - {
          origins: !ruby/regexp '/^https?:\/\/(127\.0\.0\.1|localhost|[a-z0-9-]+\.local|10\.[0-9]+\.[0-9]+\.[0-9]+|192\.[0-9]+\.[0-9]+\.[0-9]+|[a-z0-9-]+\.zooniverse\.org|[a-z0-9-]+\.(pfe-)?preview\.zooniverse\.org)(:\d+)?$/',
          resource: "/oauth/*",
          credentials: true,
        }
      - { origins: "*", resource: "*" }

• Start your local copy of Panoptes with docker-compose up (you will need to change the docker-compose.yml to change the host port)

• Start your local copy of app-project

• Visit http://local.zooniverse.org:3000/projects/brooke/i-fancy-cats?panoptes-api-host=http%3A%2F%2Flocal.zooniverse.org%3A3001&panoptes-api-application=<client_id>, replacing <client_id> with the actual client id you got in the first step.

• Log in, and refresh

• You should see the _Local_Panoptes_session cookie in dev tools, and in the headers of the req object if you log it in app-project.

Notes / thoughts

• Setting environment variables for PANOPTES_API_HOST etc doesn't work on the client side - they're correctly set on the server-side, but don't get picked up on the client. To test this, omit the panoptes-api-host and panoptes-api-application query params, and watch it fail.
• I haven't tried exchanging the cookie for a bearer token yet on the server side
• We'll need a store to keep the bearer token (in volatile state, we don't want to pass it along with the store snapshot to hydrate the store)
• The panoptes auth client is probably going to spam the bejeezus out of the server logs because it console.logs everything it does (because it was never designed to be used on a server)
• @camallen is going to need to do some work on https://github.com/zooniverse/Panoptes/issues/3123 to get this working on production / staging

[camallen]

Noting that once i've solved https://github.com/zooniverse/Panoptes/issues/3123 you won't need to run your own API to test this. Please ping me if you need help.

[camallen]

Ok - SSR authentication update, i’ve modified the frontend.preview.zooniverse.org domain to proxy /users/sign_in & oauth/tokens requests to the production API*

In order to test the SSR cookies are being sent to the front end apps, you’ll need to visit https://frontend.preview.zooniverse.org/projects/nora-dot-eisner/planet-hunters-tess?panoptes-api-host=https://frontend.preview.zooniverse.org (or rebuild the underlying code to use this domain for auth host on preview site).

Once there you will be able to sign in normally (to Production API) and the correct session cookie will set in the browser, thus also sent to the SSR app on reload etc

Then that session cookie can be used to to get a JWT and interact with the API for authenticated page content creation on the server 🎉

You can check this by looking at your reload HTML page request headers and see the cookies being sent on the original request (also inspect your cookies)

The production www.zooniverse.org cloud front behaves the same as preview.* and as the auth host is www.zooniverse.org this will work out of the box on that site.

Please reach out if you have questions etc.

* This is a little confusing as by default the deployed code on that domain (PFE) talks to staging, interestingly the deployed FE-project|content-app talk to production (these have different CloudFront paths proxying to the different apps).

These rebuilt project-app is available at /projects/nora-dot-eisner/planet-hunters-tess The CF upstream API destination (production) is most likely to change longer term but it works in the short term for the testing the main deployed project we have.

The PJC code will have to change to sort the CFEs so will think about how we can help with this issue as well. It may be that we may have to look at frontend.preview.zooniverse.org -> production APIs and/or frontend-staging.preview.zooniverse.org -> staging (edited)