OAuth Connection issue (with WFS Module and QGIS)

Hosting farmOS
21

I am working on documenting this whole install and will add this to it.

Awesome!!

This appears to work, not sure it is best practices.

Yea that would work! Couple of small tips/thoughts:

  • Instead of 770, I would recommend 440 - which means “user and group can read, everyone else can’t do anything”. This is a bit more secure than 770 which means “user and group can write, everyone else can’t do anything”. Not a huge difference in practice, probably, but it just means that if an attacker “broke into” the Docker container, they would only be able to read the key (which IS bad), but they wouldn’t be able to modify it (which maybe would be worse). It’s also possible to make the volume itself read-only in your docker-compose.yml file, which would achieve the same thing. This can be done by adding :ro to the end of the volume definition (eg: ./keys:/opt/drupal/keys:ro)
  • Be sure to mount that directory as a volume! If the keys get recreated from one container to the next, then it would break all existing OAuth2 tokens (I believe).
  • You can also run chown and chmod on the directory outside of the container - doesn’t need to be done inside. This brings up a subtle but important consideration, though. On Linux user/group names are just shortcuts that point to numeric user/group ID. It it a widely used standard convention on most Linux flavors that www-data always corresponds to an ID of 33 (both user/group). Although it might not be safe to assume that all the time! So eg: if you run chown www-data:www-data outside of the Docker container, and your host system uses a different ID for whatever reason, then it will NOT have an owner/group of www-data inside the container. This is probably enough of an edge case that we don’t need to worry about it though. (I do wonder how it would behave on Windows though…)
22

Thanks @mstenta!

I will post my install writeup shortly.

4 Likes