Hi Nick Thanks for the response. I neglected to mention the full details of what I actually am doing, mainly that I am actually implementing an AuthenticationProvider. Here's a better synopsis:
I have an administrative python script that I call use to do basic items in guacamole, such as create users, permissions, and connections. Before I installed my rfoo authentication provider, I would do things like: - POST /guacamole/api/session/data/postgres/users - POST /guacamole/api/session/data/postgres/connectionGroups - POST /guacamole/api/session/data/postgres/connections The above has been plenty stable, as it's just the guacamole API. However, I then wanted to consume some data from an internal API from inside the guacamole interface and display it in the interface using angularjs. Therefore, I created a new authentication provider (I very much modeled it after the wol provider <https://github.com/necouchman/guacamole-client/tree/f5db7c1f314fd9abc72faa5d0231881465d95419/extensions/guacamole-auth-wol>). For example, a guacamole user can get some textual briefing information about a specific connection by GET /guacamole/api/session/ext/rfoo/briefing. I also created a route to display a dynamic message on the homepage with GET /guacamole/api/session/ext/rfoo/motd. This authentication provider also works great, but as soon as I installed it my administrative python script "broke" in that I had to change the datasource from postgres to rfoo. My authentication provider doesn't have any persistent storage, and all the details are still being stored in the postgres database, even though I'm not referencing/extending the postgres authentication provider in my code. Differently put, I would guess if you installed the wol provider <https://github.com/necouchman/guacamole-client/tree/f5db7c1f314fd9abc72faa5d0231881465d95419/extensions/guacamole-auth-wol>, a similar thing would happen. I can post my provider code, but I might need to spend some time redacting the internal API routes. On Tue, Feb 27, 2024 at 5:20 PM Nick Couchman <[email protected]> wrote: > On Tue, Feb 27, 2024 at 9:53 AM ITS SkillsUSA <[email protected]> > wrote: > >> Hi There >> >> I had a question about the order of authentication providers in >> guacamole-client. I have been using the official docker container with the >> postgresql authentication extension for years, and it has been quite >> stable. I developed some API programs outside the container and was able to >> call them using postgres as my datasource (ie >> /guacamole/api/session/data/postgres/...) This has worked well. >> >> I then decided I wanted to add my own guacamole-ext to do some light css >> theming. I created my own extension (named rfoo). This broke all of my API >> calls, as the datasource needed to be updated to rfoo. (ie >> /guacamole/api/session/data/rfoo/...) I then spent some time trying every >> permutation of EXTENSION_PRIORITY, but was unable to get the API url to >> change back to postgres. >> >> My questions: >> >> 1. Even though I'm just doing css changes, is the guacamole-ext / >> authentication provider the best way to accomplish this? >> > > For CSS changes, you do need guacamole-ext, and a Guacamole Extension; > however, you need not implement an authentication provider class unless > you're doing some sort of integration between the authentication provider > and the CSS - like a custom attribute that controls the CSS in some way. If > all you're doing is changing the look and feel of the Guacamole Client web > application through CSS, you just need the guac-manifest.json file and the > actual CSS files. No need for any Java classes at all. > > Also, none of those things should change anything about the API or how you > interact with data sources. > > >> 2. Is there a way to specify which authentication provider can be used in >> the API url, or better yet just generically send the API calls without a >> datasource? >> >> > That depends on what you're trying to do. If you're doing things like > creating and deleting connections, connection groups, users, and/or user > groups, you have to specify a data source, since all of those things happen > within the context of the data source. > > Perhaps you could share what errors you're seeing, or how those API calls > "broke" after you added your extension? > > -Nick >
