| [19:28:12] | <holz[m]> | <mstenta[m] "You mention you're using POST to"> Hello follow-up question ~ So I am unable to POST to create new records at /log, I am still getting error "500 Service unavailable (with message)". Retrieving data with GET is no problem for me. Again, I am using oauth2 password credentials grant, hosting via farmier. Any pointers? |
| [19:45:15] | <mstenta[m]> | Do the example `curl` commands work? |
| [19:45:18] | <mstenta[m]> | https://farmos.org/development/api/#creating-records |
| [23:06:17] | * farmBOT has joined #farmos |
| [00:26:47] | * mmn has quit (Remote host closed the connection) |
| [00:45:57] | * mmn has joined #farmos |
| [03:37:06] | * mmn has quit (Quit: goodbye) |
| [04:00:04] | * farmtech[m] has quit (Quit: Idle for 30+ days) |
| [05:26:30] | <holz[m]> | <mstenta[m] "Do the example `curl` commands w"> No, perhaps I have some small mistake. This is what I did: |
| [11:00:13] | * zedrickr11[m] has quit (Quit: Idle for 30+ days) |
| [12:45:01] | <paul121[m]> | holz: That looks correct. I'm curious what would happen if you try Session auth, could you try that? https://farmos.org/development/api/#2-session-cookie-and-csrf-token |
| [12:45:32] | <paul121[m]> | ohhh actually... it looks like your `timestamp` is in milliseconds, not seconds |
| [12:45:39] | <paul121[m]> | that might create the 500 error |
| [12:46:46] | <paul121[m]> | try `1606644424` instead |
| [13:21:38] | <mstenta[m]> | Ah good catch! |
| [13:36:21] | <symbioquine[m]> | @paul121 In farmOS 2.x is it expected for the `farm` oauth2 client to allow the "Authorization Code" Grant type to proceed for any domain without a confirmation prompt? |
| [13:37:29] | <symbioquine[m]> | paul121: ^ |
| [13:43:14] | <symbioquine[m]> | I might be missing something, but it looks like a site at "https://my.malicious.example.com/" could redirect a user who is already logged into their farmOS instance to "https://my.example.farm/oauth/authorize?response_type=code&client_id=far... and the user would be redirected immediately without any prompt to |
| [13:43:14] | <symbioquine[m]> | "https://my.malicious.example.com/farmOSGrantHandler/?code=deadbeefdeadbe... |
| [13:43:33] | <paul121[m]> | Hmmm that doesn't sound right. I think we should consider disabling authorization code grant for the default client altogether |
| [13:44:05] | <symbioquine[m]> | If I check the "third party" box it works as expected - showing a prompt... |
| [13:44:56] | <paul121[m]> | Simple oauth has a setting for "trusted clients" or "remembered clients" or something that will allow the client to automatically be re-authorized without form, once it is authorized once. That's a configurable option on the client I believe |
| [13:44:56] | <symbioquine[m]> | ACTION uploaded an image: image.png (26KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/ZwUOxVQYoLoUaeld... > |
| [13:45:53] | <paul121[m]> | Ah okay. Yea, maybe if it isn't "third party" then simple oauth doesn't display the authorization form |
| [13:47:52] | <symbioquine[m]> | Just curious, what's the intended use-case for that oauth client? |
| [13:48:40] | <symbioquine[m]> | Is it the "Resource Owner" grant flow to allow clients like farmOS.py? |
| [13:51:40] | <symbioquine[m]> | This all came up because I was testing accessing farmOS 2.x from QGIS and the oauth2 setup seemed "a bit too easy" so I started poking around... :) |
| [13:51:43] | <paul121[m]> | It's meant to just be a default client so something is available to use, but that is a bit of an oauth anti-pattern. There really shouldn't be one client that's used for multiple purposes |
| [13:52:06] | <paul121[m]> | Yea that oauth connection would be great! |
| [13:54:45] | <paul121[m]> | IMO we should disable that client by default, and have a `farm_dev` instead. Provided with an optional module. But having a default client available might make sense... mainly for convenience though? I think mstenta pushed for the default option ;-) |
| [13:57:11] | <symbioquine[m]> | There's also some weird behavior with simple_oauth - for example if you pass a non-existent client id it returns a 401 which causes the browser to pop up a basic auth dialog; |
| [13:57:16] | <symbioquine[m]> | ACTION uploaded an image: image.png (45KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/NoxkpqJbvtiHrbvf... > |
| [13:58:24] | <symbioquine[m]> | But as far as I can tell, there's nothing useful a normal user could do at that point. |
| [14:00:00] | <paul121[m]> | Oh interesting |
| [14:00:19] | <symbioquine[m]> | OTH, with oauth2_server you get a sensible error message; `{"error":"invalid_client","error_description":"The client id supplied is invalid"}` |
| [14:00:45] | <paul121[m]> | That may actually be a "bug" we've introduced... |
| [14:01:01] | <symbioquine[m]> | with that patch? |
| [14:01:15] | <paul121[m]> | We modified simple oauth to use strings as client_id identifiers, rather than UUIDs |
| [14:01:28] | <paul121[m]> | So we change the logic of how the consumer entities are looked up |
| [14:02:01] | <paul121[m]> | But... It should still be compatible with UUIDs |
| [14:02:35] | <paul121[m]> | Maybe that is an edge case, if nothing is found, we're over-ordering the default behavior |
| [14:04:25] | <symbioquine[m]> | oauth2_server returns that message with a http 400 code |
| [14:08:43] | <symbioquine[m]> | I think the "bug" is here; https://github.com/thephpleague/oauth2-server/blob/master/src/Exception/... |
| [14:08:52] | <mstenta[m]> | > IMO we should disable that client by default, and have a `farm_dev` instead. Provided with an optional module. But having a default client available might make sense... mainly for convenience though? I think mstenta pushed for the default option ;-) |
| [14:08:53] | <mstenta[m]> | Yea I thought it would be nice to have a simple default for farmOS.py, curl, etc that didn't require enabling another module |
| [14:08:54] | <symbioquine[m]> | But it's somewhat subjective... |
| [14:09:22] | <mstenta[m]> | But it should be limited to password auth I think |
| [14:10:41] | <symbioquine[m]> | I'm going to open an issue with thephpleague/oauth2-server anyway and see what happens... :) |
| [14:14:03] | <paul121[m]> | Oh wow! It's in the php library. Interesting. Worth mentioning I'm not too sure if oauth2_server was very up to spec in D7 |
| [14:14:22] | <paul121[m]> | Although the oauth spec is a bit all over the place |
| [14:14:29] | <symbioquine[m]> | Yeah, I hope the spec doesn't require http 401... |
| [14:14:33] | <symbioquine[m]> | That would be surprising :) |
| [14:15:09] | <symbioquine[m]> | I'll open the issue and let it get sorted out there. That way at least there's a tracking issue for the surprising behavior even if it turns out that it is just following the spec. |
| [14:15:52] | <paul121[m]> | Also the new oauth2_server module for D8 was refactored to use that same thephpleague library! The released that right after we got done implementing simple_oauth haha |
| [14:16:05] | <paul121[m]> | Cool! Curious where that goes |
| [14:16:15] | <paul121[m]> | I gtg! Talk later |
| [14:22:52] | <symbioquine[m]> | <mstenta[m] "But it should be limited to pass"> Agreed. I just don't see a way to turn off the Authorization Code grant flow... |
| [14:23:53] | <symbioquine[m]> | If we could, then I believe the behavior would match that of the default client in farmOS 7.x-1.x |
| [14:24:41] | <mstenta[m]> | This is where the client gets created: https://github.com/farmOS/farmOS/blob/c837e626b11d3c0b46f14dc4e79ecaa64f... |
| [14:24:58] | <mstenta[m]> | But paul121 is more familiar than I am, I might defer to him when he's back :-) |
| [14:25:47] | <mstenta[m]> | One thing I wanted to mention to you, though, symbioquine - just to be sure you're aware: we are not writing auto-update code for 2.x until we release the first official beta |
| [14:26:19] | <mstenta[m]> | So we're sort of working under the assumption that farmOS 2.x is being installed fresh at this point... as things change in the dev branch they won't auto-update existing deployments |
| [14:27:20] | <mstenta[m]> | So this one is a good example... if we change the code in `hook_install()` it will NOT update the client in any farmOS 2.x databases that are already installed |
| [14:27:48] | <mstenta[m]> | After beta release, we'll start to include `hook_update_N()` functions that include update logic |
| [14:28:27] | <mstenta[m]> | Just isn't worth our time (or all the added code) in the pre-beta dev phase |
| [14:28:57] | <mstenta[m]> | Hopefully by the time we release a beta, most things will be pretty solid, so update code will be limited |
| [14:29:51] | <symbioquine[m]> | Makes sense. I'm just doing dev testing at this point so I can just blow away the whole install between tests :) |
| [14:30:07] | <mstenta[m]> | Cool! That's what I figured - just wanted to make sure :-) |
| [14:30:16] | <mstenta[m]> | We should probably post that somewhere so it's explicit |
| [14:31:31] | <mstenta[m]> | (Although we don't really have "farmOS 2.x" posted anywhere prominent, so most people probably don't know about it) |
| [14:33:10] | <mstenta[m]> | Oh so on another topic you might be interested in... I've been playing around a bit with a modified `.github/workflows/run-test.yml` file that can be used in contrib modules for automated testing |
| [14:33:42] | <mstenta[m]> | * Oh so on another topic you might be interested in... I've been playing around a bit with a modified `.github/workflows/run-tests.yml` file that can be used in contrib modules for automated testing |
| [14:35:16] | <mstenta[m]> | It's based off of the farmOS `run-tests.yml` with a few differences: |
| [14:35:17] | <mstenta[m]> | - Doesn't build the docker containers - just pulls the `2.x` and `2.x-dev` images from Docker Hub |
| [14:35:17] | <mstenta[m]> | - Does a few things to allow the contrib module to be required via Composer, so that other dependencies get pulled in |
| [14:35:37] | <mstenta[m]> | I was thinking... it might be nice to try to package something like this up as an action in the GitHub Actions marketplace |
| [14:35:52] | <mstenta[m]> | Because it's going to be pretty much boilerplate that other modules could largely copy |
| [14:36:11] | <mstenta[m]> | I haven't made reusable actions before, but it sounds like it would be a good option |
| [14:36:25] | <symbioquine[m]> | ACTION sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/cOoZujhJGIIkLLgE... > |
| [14:36:47] | <mstenta[m]> | Cool! Here I'll paste what I have into a gist.... one sec |
| [14:36:53] | <symbioquine[m]> | Was just thinking yesterday that I need to figure out how to do that... |
| [14:37:27] | <mstenta[m]> | I got it working... but it might benefit from some improvements |
| [14:38:07] | <mstenta[m]> | And like I said... I'd rather not have to copy+paste+modify this in every module (and update when changes are needed) - so maybe a github marketplace action would help |
| [14:38:59] | <mstenta[m]> | https://gist.github.com/mstenta/90d1caa7cddfb4f9073de1ddefafdae4 |
| [14:39:40] | <mstenta[m]> | (context: this is for a `farmier` module, which I install on farmier-hosted sites to do a few small overrides etc - so you can search/replace "farmier" with your module name) |
| [14:40:49] | <mstenta[m]> | > I got it working... but it might benefit from some improvements |
| [14:40:49] | <mstenta[m]> | In particular, I had to do a few things to work around the `www-data` user id `33` thing... (thanks for documenting that btw - i might have forgotten and spent longer trying to debug it had i not just recently read your comments) |
| [14:41:52] | <symbioquine[m]> | :) |
| [14:41:55] | <mstenta[m]> | > Does a few things to allow the contrib module to be required via Composer, so that other dependencies get pulled in |
| [14:41:56] | <mstenta[m]> | To do this, I am basically just checking out the repo into the `www` folder AFTER the containers are started (so that it's available in the container), and then use `composer config` to add a local repository |
| [14:42:06] | <mstenta[m]> | Then `composer require` works |
| [14:42:31] | <symbioquine[m]> | Yeah, that workflow looks pretty straight-forward (hind-sight being what it is) :) |
| [14:42:38] | <mstenta[m]> | Cool! |
| [14:42:50] | <mstenta[m]> | Have you ever made a github marketplace action? |
| [14:42:53] | <mstenta[m]> | Curious what's involved |
| [14:42:57] | <symbioquine[m]> | no idea |
| [14:43:09] | <symbioquine[m]> | Can't imagine it would be too hard though... |
| [14:43:12] | <mstenta[m]> | https://docs.github.com/en/free-pro-team@latest/actions/creating-actions... |
| [14:45:19] | <mstenta[m]> | jgaehring and I talked about doing something similar for Field Kit module packaging |
| [14:45:52] | <mstenta[m]> | (to basically run npm install, create a tarball, attach it to a release, etc) |
| [14:46:54] | <mstenta[m]> | So maybe it would make sense to have a dedicated repo for farmOS-related actions we provide to the community... at github.com/farmOS/farmOS-actions or something |
| [14:47:34] | <mstenta[m]> | (Which I assume would just be the source code... but the actions themselves would be published to the marketplace, and devs could include them in their workflow files as they wish) |
| [14:47:57] | <mstenta[m]> | But we can work up to that :-) |
| [14:48:15] | <mstenta[m]> | Dogfood them ourselves for a bit first... even if it means having the same code in multiple repos |
| [14:55:44] | <symbioquine[m]> | https://github.com/thephpleague/oauth2-server/issues/1162 |
| [14:56:13] | <symbioquine[m]> | <mstenta[m] "So maybe it would make sense to "> According to https://docs.github.com/en/free-pro-team@latest/actions/creating-actions... "Each repository must contain a single action." |
| [14:56:25] | <mstenta[m]> | ahh.. |
| [14:56:29] | <mstenta[m]> | oh well |
| [14:56:47] | <symbioquine[m]> | So maybe create one called "farmOS-module-test-gh-action" for now? :) |
| [14:56:57] | <mstenta[m]> | yea something like that |
| [14:57:04] | <mstenta[m]> | maybe `farmOS-action-*`? |
| [14:57:21] | <mstenta[m]> | `farmOS-action-run-rests` or something |
| [14:57:37] | <mstenta[m]> | so they all get alphabetically sorted in the repo list :-)( |
| [14:57:40] | <mstenta[m]> | * so they all get alphabetically sorted in the repo list :-) |
| [14:57:48] | <symbioquine[m]> | yeah, not sure but it might be worth making the name communicate that it's a "Github" action... |
| [14:57:55] | <mstenta[m]> | mm yea perhaps |
| [14:58:11] | <mstenta[m]> | we could also consider creating a github.com/farmOS-actions group |
| [14:58:13] | <mstenta[m]> | and putting them in there |
| [14:58:15] | <symbioquine[m]> | I don't know if the repository name needs to match the action name in the marketplace. |
| [14:58:32] | <mstenta[m]> | we already have github.com/farmOS-legacy, where I move old stuff |
| [14:59:04] | <symbioquine[m]> | If not, maybe the repository name includes "gh" or "github", but the action name doesn't need to since it appears in the context of the Github actions marketplace. |
| [14:59:16] | <mstenta[m]> | yea |
| [14:59:40] | <mstenta[m]> | if we put them in their own org, then we could just make it clear that the org is for github actions... so we don't need it in the repo name |
| [15:00:08] | <symbioquine[m]> | that could work too |
| [15:00:19] | <mstenta[m]> | most users of them wouldn't be looking for actual repos anyway... so it's ok if it's not in the farmOS org |
| [15:00:30] | <mstenta[m]> | they'd find them via the marketplace i assume... or by copying other modules |
| [15:00:57] | <symbioquine[m]> | <symbioquine[m] "https://github.com/thephpleague/"> paul121: in case you wanted to follow along on that issue |
| [15:01:19] | <symbioquine[m]> | <mstenta[m] "they'd find them via the marketp"> or ideally from the documentation :) |
| [15:01:34] | <mstenta[m]> | yes yes |
| [15:02:59] | <mstenta[m]> | i set up the org and added you as a member :-) |
| [15:03:35] | <symbioquine[m]> | cool |
| [15:04:54] | <symbioquine[m]> | I was just getting around to creating a repository for the WFS module development to happen in so hopefully soon I'll check in a stubbed version of the controller and try to get the WFS compliance test suite running against it using that action... |
| [15:04:56] | <mstenta[m]> | (this way too... if we ever move off of GitHub we just leave this behind) |
| [15:05:12] | <symbioquine[m]> | makes sense |
| [15:05:12] | <mstenta[m]> | neat! |
| [15:06:09] | <symbioquine[m]> | https://opengeospatial.github.io/ets-wfs20/ |
| [15:06:40] | <symbioquine[m]> | * I was just getting around to creating a repository for the WFS module development to happen in so hopefully soon I'll check in a stubbed version of the controller and try to get the WFS conformance test suite running against it using that action... |
| [15:06:49] | <mstenta[m]> | oh very cool |
| [15:07:42] | <symbioquine[m]> | Seems like WFS 2.0 makes more sense than 3.0 for now since QGIS doesn't support WFS 3.0 yet. |
| [15:07:54] | <mstenta[m]> | ah |
| [15:09:01] | <symbioquine[m]> | QGIS also supports something called "OGC API - features"... but I haven't been able to make very much sense of it yet; https://www.ogc.org/standards/ogcapi-features |
| [15:10:35] | <mstenta[m]> | makes sense to focus on what's supported by qgis |
| [15:10:51] | <symbioquine[m]> | <symbioquine[m] "QGIS also supports something cal"> It almost looks like it might be possible to make the JSON:API endpoint compatible with it... but I haven't fully GROKed it yet |
| [15:11:08] | <symbioquine[m]> | Seems almost too free-form... |
| [15:11:10] | <mstenta[m]> | oooh interesting |
| [15:11:30] | <symbioquine[m]> | http://docs.opengeospatial.org/is/17-069r3/17-069r3.html#collections |
| [15:48:33] | * farmtech[m] has joined #farmos |
| [16:36:32] | <holz[m]> | <paul121[m] "try `1606644424` instead"> works!! amazing, thanks! |
| [16:37:48] | <mstenta[m]> | @holz usually 500 means there's a bug somewhere... ideally a validation issue like that should throw a different code |
| [16:37:58] | <mstenta[m]> | so you shouldn't expect to see 500s normally |
| [16:38:24] | <mstenta[m]> | we're working on farmOS 2.x, which has a completely different framework for the API, so hopefully it is already fixed there :-) |
| [16:45:52] | <holz[m]> | <mstenta[m] "we're working on farmOS 2.x, whi"> Exciting! Maybe a vague question: I am making a nodejs app, should I be expecting some major changes? |
| [16:48:17] | <mstenta[m]> | yes haha |
| [16:48:32] | <mstenta[m]> | http://2x.farmos.org/development/api/changes/ |
| [16:49:00] | <mstenta[m]> | that is a work in progress document... we are adding to it as we build out the farmOS 2.x data architecture - so it is still missing things that we have not upgraded to 2.x yet |
| [16:49:22] | <mstenta[m]> | we are aiming for Spring 2021 |
| [16:49:25] | <mstenta[m]> | to start beta |
| [16:49:47] | <mstenta[m]> | so you may want to still target the 1.x API in the short term... depends on what you're doing I suppose |
| [16:50:08] | <mstenta[m]> | but we will document all the changes in that doc, so it should make the upgrade process pretty straightforward when the time comes... |
| [16:51:11] | <mstenta[m]> | for the most part, the data model itself will be roughly the same (with some notable exceptions) |
| [16:51:29] | <mstenta[m]> | the endpoints themselves are changing, and we're using JSON:API and JSON Schema - so the JSON structure is changing |
| [16:51:46] | <mstenta[m]> | and a bunch of names are changing (eg: dropping the `farm_` prefix from log types) |
| [16:52:03] | <mstenta[m]> | basically just cleaning up the old API and making it perfect (and less Drupal-y) :-) |
| [16:58:58] | <holz[m]> | mstenta: nice, glad to have the heads up. I have a short term goal for the end of December so I will work with the 1.x API. the WIP document is super useful, seems like upgrading on my end will be fairly straightforward! |
| [17:03:24] | <mstenta[m]> | Great! |
