| [03:26:17] | * farmBOT has joined #farmos |
| [09:31:36] | <mstenta[m]> | paul121 symbioquine I'm wondering if we should remove the logic for auto-generating OAuth2 keys during `farm_api` installation, and instead provide documentation for how to set them up. The convenience of auto-generating them is nice, but there are some issues with it currently... |
| [09:32:55] | <mstenta[m]> | The reason I'm looking into this now is because I realized we don't have any documentation for setting up keysin our installation docs. |
| [09:34:06] | <mstenta[m]> | We also don't do anything in our Docker image to set them up automatically. |
| [09:34:13] | <mstenta[m]> | And I'm not sure we easily can... |
| [09:35:42] | <mstenta[m]> | The keys need to be persisted in a Docker volume. But in order to auto-generate them, that volume also needs to be writable by Apache. Once they're generated, though, it should be read only. |
| [09:36:25] | <mstenta[m]> | On Farmier, I generate keys ahead of time, and bind-mount them as read-only. So the code in farm_api's install hook detects that they already exist and doesn't attempt to create them. |
| [09:41:36] | <mstenta[m]> | If the keys directory is not mounted as a volume, then they are lost during the first farmOS upgrade. :-/ |
| [09:44:03] | <mstenta[m]> | Oh but I guess that doesn't even happen because keys doesn't exist in the first place 😅 |
| [09:45:37] | <mstenta[m]> | Another tricky thing is that keys needs to be readable by Apache, but nothing else. And the Apache user (uid 33) inside the container may have a different ID outside the container. |
| [09:47:23] | <mstenta[m]> | > remove the logic for auto-generating OAuth2 keys during `farm_api` installation, and instead provide documentation for how to set them up |
| [09:47:23] | <mstenta[m]> | I'm curious what kinds of warning/guidance (if any) `simple_oauth` shows in the UI when keys don't exist? |
| [09:49:54] | <mstenta[m]> | > We also don't do anything in our Docker image to set them up automatically. |
| [09:49:54] | <mstenta[m]> | We could create a `/opt/drupal/keys` directory in our Docker build process as a first step. Then it at least exists (for both Docker and packaged releases). And we could include a volume mount in our `docker-compose.production.yml` example. Although it would still require manual steps to make it writable before Drupal installation takes place. |
| [10:00:14] | <symbioquine[m]> | Hmmm... |
| [10:02:03] | <symbioquine[m]> | I guess we should test the different scenarios to know what the "bad things" we're trying to avoid are. |
| [10:03:19] | <mstenta[m]> | Curious what the experience has been of other folks who set up self-hosted instances |
| [10:03:21] | <mstenta[m]> | (and are using Oauth2) |
| [10:03:21] | <mstenta[m]> | They must have run into this |
| [10:03:32] | <symbioquine[m]> | I'm sure I did, I just can't remember, other than needing to configure that bind-mount. |
| [10:03:40] | <mstenta[m]> | (cc botlfarm postmanpat Farmer Ed ) |
| [10:04:27] | <mstenta[m]> | (ps this is inspired by helping riotmiked the other day...) |
| [10:05:20] | <mstenta[m]> | Yea and if you don't have keys set up and writable before installation, then you need to manually create the keys. The farm_api installation code only runs once when the module gets installed. |
| [10:05:33] | <mstenta[m]> | (Although uninstalling it and reinstalling it would trigger that again...) |
| [10:05:54] | <mstenta[m]> | But maybe it would be better for us to provide a button in the UI for doing that 🤔 |
| [10:06:56] | <mstenta[m]> | farm_api is a "default" module that is installed with farmOS, but not everyone who has it needs the API, and of that subset, not everyone needs OAuth2 connection |
| [10:07:45] | <mstenta[m]> | (for what it's worth... so adding docs for "setting up API" might be nice) |
| [10:08:02] | * FarmerEd[m] has joined #farmos |
| [10:08:03] | <FarmerEd[m]> | I can't remember off the top of my head, but I'm pretty sure anytime I setup a new instance I end up going in circles with this. |
| [10:08:08] | * botlfarm[m] has joined #farmos |
| [10:08:09] | <botlfarm[m]> | I believe I set up oauth2 a while ago, but have no recollection of what the process was. I also no longer use it. |
| [10:08:11] | <FarmerEd[m]> | Probably should have documented it myself by now |
| [16:09:48] | * paul121[m] has joined #farmos |
| [16:09:49] | <paul121[m]> | <mstenta[m]> "The keys need to be persisted in..." <- Is there any reason it can't be left as writable by Apache? Or is it just a safety thing, to prevent it accidentally being changed in the future? |
| [16:11:03] | <paul121[m]> | it kinds sounds like this is a hosting level concern, it would be nice if we could try to auto-create when we have write permission, otherwise skip, and add a (what is it called?) a hook_module_requirements info piece? or maybe simple_oauth already does this? |
| [16:11:06] | <mstenta[m]> | Yea just best practice. But in theory we might be able to revoke write access via PHP too, after keys are written 🤔 |
| [16:12:10] | <mstenta[m]> | Yea it is a hosting level concern. It came up because I realized we don't have any documentation for it, and it does not work out of the box with our Docker or packaged releases |
| [16:12:36] | <mstenta[m]> | At the very least we need docs |
| [16:12:51] | <mstenta[m]> | But it got me thinking about whether or not we should rethink the auto generating logic |
| [16:13:54] | <mstenta[m]> | I don't think we should require keys be generated manually, but maybe we could provide a drush command or something that allows the keys to be generated after farm_api install |
| [16:14:49] | <mstenta[m]> | But also got me thinking that OAuth is technically a separate layer on top of the API that not every necessarily needs |
| [16:15:05] | <mstenta[m]> | Eg Asset Link uses the API but not OAuth (I think) |
| [16:15:23] | <mstenta[m]> | So in some cases it isn't necessary to set up keys at all |
| [16:15:52] | <paul121[m]> | True |