| [21:22:59] | * mstenta[m] has quit (Ping timeout: 244 seconds) |
| [21:22:59] | * symbioquine[m] has quit (Ping timeout: 244 seconds) |
| [21:22:59] | * harry[m]1 has quit (Ping timeout: 244 seconds) |
| [21:23:00] | * spacespy[m] has quit (Ping timeout: 244 seconds) |
| [21:23:00] | * scrdcow[m] has quit (Ping timeout: 244 seconds) |
| [21:23:22] | * blm5303[m] has quit (Ping timeout: 244 seconds) |
| [21:23:23] | * permakai[m] has quit (Ping timeout: 244 seconds) |
| [21:23:23] | * davd[m] has quit (Ping timeout: 244 seconds) |
| [21:23:27] | * mindcls[m] has quit (Ping timeout: 244 seconds) |
| [21:23:32] | * jgaehring[m]1 has quit (Ping timeout: 260 seconds) |
| [21:23:33] | * Anonymous[m] has quit (Ping timeout: 260 seconds) |
| [21:23:58] | * and712[m] has quit (Ping timeout: 244 seconds) |
| [21:26:25] | * blm5303[m] has joined #farmos |
| [21:26:25] | * permakai[m] has joined #farmos |
| [21:26:27] | * davd[m] has joined #farmos |
| [21:26:51] | * jgaehring[m]1 has joined #farmos |
| [21:28:35] | * and712[m] has joined #farmos |
| [21:29:20] | * Anonymous[m] has joined #farmos |
| [21:33:18] | * mstenta[m] has joined #farmos |
| [21:33:18] | * symbioquine[m] has joined #farmos |
| [21:33:20] | * spacespy[m] has joined #farmos |
| [21:35:10] | * scrdcow[m] has joined #farmos |
| [21:35:11] | * harry[m]1 has joined #farmos |
| [21:41:38] | * mindcls[m] has joined #farmos |
| [22:14:57] | * scrdcow[m] has quit (*.net *.split) |
| [22:14:57] | * permakai[m] has quit (*.net *.split) |
| [22:16:26] | * scrdcow[m] has joined #farmos |
| [22:17:33] | * permakai[m] has joined #farmos |
| [04:22:13] | * Kingdutch has joined #farmos |
| [04:25:10] | <Kingdutch> | Ello o/ |
| [04:25:44] | <Kingdutch> | mstenta asked me to join you here after I appraoched him about working on simple_oauth :) |
| [04:43:51] | <spacespy[m]> | Hi |
| [04:43:51] | <farmBOT> | eh oh |
| [05:38:09] | <Kingdutch> | The impression I get from looking at the oauth2_server module is that it's more aimed at enterprise like OAuth that we're looking at (i.e. separate application scopes from per-user permissions through Drupal roles). Is there a reasonn that you've decided not to use the oauth2_server module? |
| [05:38:52] | <Kingdutch> | I was told that it used a slightly more outdated oauth2 PHP library under the hood and that it may not support OpenID Connect (although it's project page says it does). |
| [05:39:18] | <Kingdutch> | Could it be easier to update the library in oauth2_server than to change the inherent model of simple_oauth? |
| [10:46:24] | <paul121[m]1> | Oh wow! I'm just looking at the latest oauth2_server releases. We hadn't considered it because it didn't have a clear upgrade path to Drupal 9 |
| [10:47:15] | <paul121[m]1> | but... they released a new version just two weeks ago! The previous release was in 2018... |
| [10:49:29] | <paul121[m]1> | so I'm actually just seeing this latest release right now |
| [10:50:42] | <paul121[m]1> | we did have some trouble getting `user_access` permissions to work with the D7 oauth2_server module. TWe needed this module to bridge that gap: https://www.drupal.org/project/restws_oauth2_server |
| [10:50:52] | <paul121[m]1> | * we did have some trouble getting `user_access` permissions to work with the D7 oauth2_server module. We needed this module to bridge that gap: https://www.drupal.org/project/restws_oauth2_server |
| [10:51:36] | <paul121[m]1> | I'm curious how all the permissions and clients are implemented in D9... there's likely some changes there |
| [10:52:01] | <paul121[m]1> | Kingdutch: were you able to find any good documentation on the latest version? |
| [10:58:25] | <paul121[m]1> | just quickly looking... `servers`, `clients`, and `scopes` are all config entities, which makes sense. But I don't see any way that the `scopes` are connected to permissions or roles |
| [11:00:22] | <paul121[m]1> | this was part of the challenge we had, and why we needed to manually "log in" the user associated with access tokens |
| [11:01:32] | <symbioquine[m]> | fwiw, I've had pretty good success using the new farmOS oauth support - albeit with a bit of a learning curve on the setup side :) |
| [11:02:40] | <paul121[m]1> | we were able to create custom scopes such as `farm_info` that only returned a subset of data from custom pages such as `farm.json`, but never extended that to entity permissions... thats the real challenge I think |
| [11:04:26] | <paul121[m]1> | `simple_oauth` has been pretty easy to work with so far. The way the library is designed (with services) its easy to decorate/override certain pieces that we want to modify |
| [11:05:13] | <paul121[m]1> | for example, rather that using a UUID as a `client_id`, we want a readable name. So by modifying the `ClientRepository` service we can change how the clients are loaded |
| [11:05:45] | <paul121[m]1> | * for example, rather than using a UUID as a `client_id`, we want a readable name. So by modifying the `ClientRepository` service we can change how the clients are loaded |
| [11:08:31] | <paul121[m]1> | Kingdutch : just re-reading your Q... maybe `oauth2_server` would be better for you :-) Since it does separate scopes from roles |
| [11:08:31] | <paul121[m]1> | > (i.e. separate application scopes from per-user permissions through Drupal roles) |
| [11:10:06] | <paul121[m]1> | I guess it depends on your content? If you're wanting to provide granular access to entities, that might be challenging. But maybe that has become easier in the D9 module! |
| [11:20:00] | <paul121[m]1> | symbioquine: have you been manually installing `simple_oauth` ? |
| [11:22:22] | <symbioquine[m]> | Hmmm, I don't have `simple_oauth`, but it looks like I do have `oauth2_server` and `restws_oauth2_server`... |
| [11:23:01] | <paul121[m]1> | ah so this is D7 |
| [11:23:05] | <symbioquine[m]> | yeah |
| [11:23:12] | <symbioquine[m]> | I thought that part was stock farmOS-1.5 |
| [11:23:19] | <paul121[m]1> | yeah it is |
| [11:23:25] | <symbioquine[m]> | ok good :) |
| [11:23:26] | <mstenta[m]> | Yea paul121 is working on 2.x stuff :-) |
| [11:23:30] | <paul121[m]1> | we're starting to figure it out for D9 and farmOS 2.x |
| [11:23:43] | <symbioquine[m]> | ah, that makes sense |
| [11:23:55] | <paul121[m]1> | wouldn't have surprised me if you were following along ;-) |
| [11:24:07] | <symbioquine[m]> | maybe I should be... |
| [11:24:09] | <mstenta[m]> | symbioquine: we're making good progress on 2.x! excited to show you on the next monthly call! |
| [11:25:01] | <mstenta[m]> | still VERY premature... but if you want to play around, here are instructions for creating a local dev env: http://2x.farmos.org/development/ |
| [11:25:30] | <mstenta[m]> | I am currently working on building out the basic data architecture (logs, assets, fields, etc), as well as migration routines. paul121 is working on API / auth stuff |
| [11:26:00] | <mstenta[m]> | The goal is to get the server stuff all working pretty quick... and then turn focus to UI after that (along with maybe doing more in Field Kit / Vue.js) |
| [11:26:45] | <mstenta[m]> | (Although there are some hairy things to figure out with the log fields... that's going to be the mountain I start climbing next ... just getting the broad strokes into place first before i dig into the more complicated stuff) |
| [12:00:36] | * iuresearcherpw[m has left #farmos ("Kicked by @appservice-irc:matrix.org : Idle for 30+ days") |
| [12:03:55] | <Kingdutch> | I've been working with oauth2_server today which has been going quite well. The reason I decided to switch over simple_oauth was for two reasons: |
| [12:04:08] | <Kingdutch> | 1) We don't need Scopes for our current implementation but will need those in the future. |
| [12:04:32] | <Kingdutch> | 2) simple_oauth includes the Consumer module which conflates applications with user roles, so removing that later if we need to make something ourselves is probably more difficult. |
| [12:05:14] | <Kingdutch> | For oauth2_server it does help you create clients with scopes although it leaves it up to you to make the scopes of a request have impact on actual functioality. |
| [12:06:05] | <Kingdutch> | I'm currently writing an access check that allows me to specify scopes on a path similar to user permissions. |
| [12:06:40] | <Kingdutch> | I can see us in the future writing an extension to the GraphQL resolver that will allow us to restrict access to parts of the graphs or fields based on scopes in the GraphQL request. |
| [12:07:39] | <Kingdutch> | We will be serving both trusted and untrusted apps, so that's why the roles break down for us. The scopes indicate the permissions that an application has whereas the roles indicate what a user is allowed to do. |
| [12:07:40] | <paul121[m]1> | > I'm currently writing an access check that allows me to specify scopes on a path similar to user permissions. |
| [12:07:41] | <paul121[m]1> | cool! that makes sense. so you just need to restrict access to certain paths? |
| [12:08:16] | <Kingdutch> | The way I see it you could have an application that can request certain data without a user (acting essentially as user 1 or the anonymous user). This would be limited by a scope. |
| [12:08:51] | <Kingdutch> | You can also have an application acting on behalf of a user which means certain scopes would have to be approved for a user but the actions would then be the intersection of the application scopes and the users permission. |
| [12:09:20] | <Kingdutch> | (e.g. an application could block a user on behalf of a user only if they have the system:user:block scope and the user they're acting for has the `administer users` permission) |
| [12:09:51] | <Kingdutch> | We have to restrict access to a path for now but in the future will have to restrict access to parts of a GraphQL API (which is under a single /graphql path) |
| [12:10:49] | <paul121[m]1> | thats a good summary of scopes + roles! |
| [12:11:51] | <paul121[m]1> | I'm actually working on making a new `farm_client` config entity that will represent `clients` for simple_oauth |
| [12:12:38] | <Kingdutch> | The thing I am running into in the oauth2_server module is the association of scopes with servers. Although I don't think that's necessarily a problem since a token is associated with a server. Currently I nneed to have a server loaded to get a token from a request. I've contacted the maintainer to ask if we can rewrite that to load the token data without the server (since the server is't actually |
| [12:12:44] | <Kingdutch> | needed). |
| [12:12:49] | <Kingdutch> | > I'm actually working on making a new `farm_client` config entity that will represent `clients` for simple_oauth |
| [12:12:52] | <Kingdutch> | Ah interesting |
| [12:13:05] | <Kingdutch> | I was actually pleasatly surprised by the client implementation in oauth2_server |
| [12:13:34] | <Kingdutch> | It allowed to overwrite the authentication mechanisms available on a server, which is great for internal clients. |
| [12:13:56] | <paul121[m]1> | part of this includes adding additional config options... such as `client.grant_user_roles` (to grant user roles), `client.configurable_scopes` (so authorizing user can select a subset), etc |
| [12:14:23] | <Kingdutch> | I think adding a separate form and two permissions (create oauth clients; create internal oauth clients) would be a great way to handle which scopes could be selected and whether the option for user authorization should be enabled. |
| [12:15:24] | <paul121[m]1> | Yeah that makes sense |
| [12:15:46] | <Kingdutch> | It sounds like we're working towards something very similar but filling in the opposite gaps. |
| [12:16:03] | <paul121[m]1> | At least to begin with, our clients will only be manged in code. But we could provide a form in the future |
| [12:16:51] | <paul121[m]1> | this requires 3rd parties to make a Drupal module, but seems like that is almost required... can't ask everyone to manually configure an identical OAuth client on their servers.. |
| [12:17:13] | <Kingdutch> | Ah yeah |
| [12:17:47] | <Kingdutch> | I think we're going for something like what you see on many platforms, where you'd have to login to create an application (or have a platform manager do it). |
| [12:18:11] | <Kingdutch> | I can see us adding a central repository that could automatically add new apps though, but that's thinking ahead a bit |
| [12:18:31] | <Kingdutch> | I just tried creating a client in oauth2_server, will have to check how scopes for clients are managed. |
| [12:18:44] | <Kingdutch> | If they always have access to all server scopes this may still become an issue ^^' |
| [12:19:48] | <paul121[m]1> | > It sounds like we're working towards something very similar but filling in the opposite gaps. |
| [12:19:48] | <paul121[m]1> | I agree! We have the need for "application scopes" too, but they will largely be tied to entity permissions. It may require creating more roles, but simple_oauth allows us to hit the ground running I think |
| [12:20:35] | <paul121[m]1> | I'm curious how you add that access controller though, maybe bridging scopes -> entity permissions wouldn't be too challenging |
| [12:20:56] | <Kingdutch> | Oh that's a good point actually. I was thinkinng about attaching the scopes to the GraphQL API but it makes more sense to attach it to entities in fields. I'll have to think about that. |
| [12:21:52] | <paul121[m]1> | report back what ya find! |
| [12:22:17] | <Kingdutch> | I'll have to check tomorrow if what I'm trying now actually works. Only got started today. Then I'll ask intnernally if we can make this available for you. We're not at a point that we want to throw this in public repo's but that's mostly because we're not planning on supporting this yet. |
| [12:22:52] | <Kingdutch> | Will do! I'll probably be back tomorrow :) (It's 18:20 here now) |
| [12:24:15] | <paul121[m]1> | Great! |