o2r-project / o2r-bouncer Goto Github PK

The default session cookie name connect.sid is used so far.
Let's use a better name, for example... o2rookie, or o2cookie.

See https://github.com/expressjs/session#name

The URL https://o2r.uni-muenster.de/api/v1/user/0000-0002-0024-5046 exposes the user level even without login. It would be nicer to only do that if the requesting user is logged in and at least admin. Or also "view levels up to own level"? No, that's confusing or also a piece of information.

Add a notification in a configured Slack channel when a new user registers.

Ideally, in this channel the user level could directly be set, see o2r-project/o2r-platform#73

All of this should not be too hard, because there is a slack package on npm.

Important for production deployments over https: Support secure cookies: https://github.com/expressjs/session#cookiesecure

Could also first experiment with the auto setting, but then must be thoroughly tested with reference-implementation and o2r-platform.

Currently only admins can see the user level. The user should at least see his own level:

https://github.com/o2r-project/o2r-bouncer/blob/master/controllers/user.js#L37

• implement extra check so that the user level is in the response document
• check that endpoint .../level works for reading for the same user
• update API docs
• create issue for platform that the user can see his level somehow

As discussed here this might not happen often, but if it does it might happen at the worst time:
https://groups.google.com/forum/#!topic/orcid-api-users/1gT_1hh4G48

To test the credentials, we should try to receive a /read-public token, see https://members.orcid.org/api/tutorial/read-orcid-records#readpub

When we store a user's access token in the session, we could use it later on.

• Evaluate what "safe and secure" should entail.
• Check whether this makes sense when only asking for /authenticate because according to to the scope documentation

From the ORCID documentation: https://members.orcid.org/api/integrate/orcid-sign-in

ORCID will then return the researcher’s verified ORCID iD and an access token, along with the refresh token, scope(s), name on the ORCID record, and token expiry. A example response:

   {"access_token":"f5af9f51-07e6-4332-8f1a-c0c11c1e3728","token_type":"bearer",
   "refresh_token":"f725f747-3a65-49f6-a231-3e8944ce464d","expires_in":631138518,
   "scope":"/authorize","name":"Sofia Garcia","orcid":"0000-0001-2345-6789"}

Store the ORCID iD and access token in your system in a safe and secure manner. Both items will be required to perform any action to their ORCID record: read, write, update. If you are only requesting /authorize access, access tokens can be stored to indicate that the iD has been authenticated, as well as to read public access data.

Use the ORCID iD and access token to read the user’s record and populate their profile in your system: Save users time by allowing them to quickly and easily transfer data from their ORCID records to your system. All you need to is to make a quick call to their record:

  Method: GET
  Content-type: application/vnd.orcid+xml or application/vnd.orcid+json
  Authorization type: Bearer
  Access token: [Stored access token]
  End point: https://api.sandbox.orcid.org/v2.0/[Stored ORCID iD]/record
  Example record XML: GitHub

This concerns all microservices:

• http://scottksmith.com/blog/2014/09/04/simple-steps-to-secure-your-express-node-application/
• https://expressjs.com/de/advanced/best-practice-security.html
• https://www.theodo.fr/blog/2015/04/preventing-csrf-attacks-with-express-and-angularjs/

How does CSRF security work with using the API? https://github.com/expressjs/csurf#ignoring-routes

Tasks

• audits
• https-only cookie (disable for dev)