On Sun, Apr 5, 2020 at 2:58 PM Roman V. Isaev <r...@isaeff.net> wrote:

> > One of the key features that the user-mapping.xml authentication
> mechanism
> > does not support is layering with other modules, so this likely won't
> work.
>
> Ok, I see -- user-mapping.xml is no-go.
>

It's not really intended to be a production solution.  There are other ways
to deliver connection information - I think Mike wrote an extension for his
Day Job that takes connection information as a JSON string.  This might
help you out - I think it's available on Mike's github page.


>
> > > I tried rest api, but it seems to be broken, or at least guacapy
> > > library seems to be broken. It can fetch data, but it does not add
> > > anything, here is an issue:
> > > https://github.com/pschmitt/guacapy/issues/31
> > I'm not familiar with this tool - it isn't something directly supported
> by
> > the project.  Not sure if the author is lurking about here - if so,
> perhaps
> > they can chime in on it, but it's not a familiar tool to me.
>
> Ok, I ran tcpflow, recorded data exchange between the library and Guacamole
> server and now I see the problem -- all library's get_ and login methods
> are using
> GET and x-www-form-urlencoded and these are okay. I can simulate
> authentication
> procedure with curl:
>
> % curl -i -X POST "http://127.0.0.1:6060/api/tokens"; -d
> 'username=guacadmin&password=guacadmin' -H "Content-Type:
> application/x-www-form-urlencoded"
> HTTP/1.1 200
> Content-Type: application/json
> Transfer-Encoding: chunked
> Date: Sun, 05 Apr 2020 18:31:05 GMT
>
>
> {"authToken":"A6F2080CE953348AF4D7CBA920F9986CEF46FEFC3DC75856924329C46945A596","username":"guacadmin","dataSource":"postgresql","availableDataSources":["postgresql","postgresql-shared"]}
>
>
This looks good - you are getting the authentication token.


> But add_* methods are using json, and they aren't working, here is
> tcpflow dump of add_user attempt:
>
> % cat 010.001.000.146.53620-010.001.000.174.06060
> POST
>
> /api/session/data/postgresql-shared/connectionGroups?token=B9D5E7224FBDF70B77FF17C9712DD62F3EC393C0506A6E2B90F4739B8291AF30
> HTTP/1.1
> Host: g.aroma.ru:6060
> Connection: keep-alive
> Accept-Encoding: gzip, deflate
> Accept: */*
> User-Agent: python-requests/2.23.0
> Content-Length: 169
> Content-Type: application/json
>
> "{\"parentIdentifier\":\"ROOT\", \"name\":\"iaas-099 (Test)\",
> \"type\":\"ORGANIZATIONAL\",
> \"attributes\":{\"max-connections\":\"\",\"max-connections-per-user\":\"\"}}"
>
> % cat 010.001.000.174.06060-010.001.000.146.53620
> HTTP/1.1 500
> Content-Type: application/json
> Transfer-Encoding: chunked
> Date: Sun, 05 Apr 2020 17:50:18 GMT
> Connection: close
>
> ac
> {"message":"Unexpected internal
> error","translatableMessage":{"key":"Unexpected internal
>
> error","variables":null},"statusCode":null,"expected":null,"type":"INTERNAL_ERROR"}
> 0
>
>
You're trying to write it to the postgresql-shared endpoint, which isn't
going to work, because the postgresql-shared extension doesn't support
storing connections - it's simply there to share existing connections.  So,
you need to post to the postgresql endpoint
(api/session/data/postgresql/connectionGroups).  There may be other issues
with that particular POST query, but that's at least the initial one.


> Even authentication does not work json style, again curl test:
>
> % curl -i -X POST "http://127.0.0.1:6060/api/tokens"; -d %
> '{"username":"guacadmin", "password":"guacadmin"}' -H "Content-Type:
> application/json"
> HTTP/1.1 500
> Content-Type: application/json
> Transfer-Encoding: chunked
> Date: Sun, 05 Apr 2020 18:33:10 GMT
> Connection: close
>
> {"message":"Unexpected internal
> error","translatableMessage":{"key":"Unexpected internal
> error","variables":null},"statusCode":null,"expected":null,"type":"INTERNAL_ERROR"}
>
Guacamole log:
>
> 18:49:34.482 [http-nio-8080-exec-9] ERROR o.a.g.rest.RESTExceptionMapper -
> Unexpected internal error: Can not deserialize instance of
> java.util.ArrayList out of VALUE_STRING token at [Source:
> org.apache.catalina.connector.CoyoteInputStream@22bf9b00; line: 1,
> column: 2]
>
> Is it supposed to work at all with json bodies? And if I can't use POST
> and nested
> data as json, how to encode more complicated requests as
> application/x-www-form-urlencoded
> for user/connection adding?..
>
>
No, the api/tokens endpoint expects the application/x-www-form-urlencoded
encoding type.  So, plain JSON encoding will not work.  The answer on how
to encode more complicated requests is, as a form.  There are plenty of
tools out there that will facilitate this.  Also, I can't remember off the
top of my head, but some of the other non-login endpoints may take JSON
data - may just be the login one that expects form encoding.  I can't
remember...


> > You should be careful, but it is documented in the manual because we have
> > foreseen the possibility that folks will want to manipulate the data
> > directly.
>
> I spent last day migrating mysql data backend to postgres, because
> official guacamole/guacamole docker image does not support RDP
> printing while oznu/guacamole does, and oznu is postgres-based. And I
> had to move users and connections, hundreds of them were entered
> earlier.
>
>
I know we have a bug or two in RDP printing at the moment that we need to
resolve, but hopefully those will be fixed, soon.  I believe a solution has
been identified and needs to be committed.


> So, now I finished moving, it finally works and damn, I hate this
> stuff!! That's why I want to communicate with Guacamole via external API
> without digging into database.
>
>
Yes, migrating between databases can be a little bit painful, but shouldn't
be too bad, particularly if you keep things like user and group IDs the
same as you go across.  Anyway, sounds like you're past that point.

The REST API works perfectly fine - the entire Guacamole Client application
uses the underlying REST API, so the API is fully functional.  You do have
to interact with it in the expected fashion, so figuring that out can take
some time.  We also don't have great documentation on the REST API at the
moment - it's been identified as something we need to document better and
we're currently looking at trying to find a tool that will generate the
documentation rather than having to manually create and maintain
documentation for the REST API.

-Nick

Reply via email to