On Wed, Mar 13, 2019 at 1:18 PM Nick Couchman <[email protected]> wrote:
> > >> Looks reasonable. Naming convention within libguac for the various >> instruction sending functions is guac_protocol_send_OPCODE(), though, so >> this would need to be guac_protocol_send_required(). >> > > I've updated the naming conventions on these... > > >> >> Perhaps the instruction should accept a list of parameter names rather >> than >> just a single name? This is what is done for the related "args" >> instruction: >> >> https://guacamole.apache.org/doc/1.0.0/libguac/protocol_8h.html#a6047d380b097ebc7d5f35b167e3419e6 >> >> > Yeah, this was my next step, but just thought I should start with getting > it working, then move on to making the code more efficient. > > >> Client: >> > >> > >> https://github.com/necouchman/guacamole-client/commit/72de5595880baea46505cf4f9ad49640f16519e7 >> >> >> Same here - convention is "onOPCODE", so this would need to be >> "onrequired". >> > > Fixed. > > >> > >> I think you will run into trouble manually parsing the Guacamole protocol >> with a guac_parser in a context where inbound instructions are already >> being parsed received. Is this because the FreeRDP authentication callback >> must be synchronous? >> >> > I'm not sure. On the xfreerdp side of things, this code results in a > Password: prompt on the command line, and the xfreerdp app waits until you > enter something before proceeding. > Yeah, looks like this is going to be problematic. Parsing the Guacamole protocol while it is already running doesn't seem to work - if I use guac_parser_expect(), it fails because there are other things going on in the background for the connection and the argv opcode isn't the first thing through, so it doesn't get what it's expecting. I also tried just looping on guac_parser_read() and looking at the opcodes as they come across, ignoring anything but argv, but it still fails. This probably means that the use of the FreeRDP authentication callback will not work, unless there's some other way to accomplish this. I could still try to block the pthread until the input is received, but this might cause other problems on the client side with an unresponsive connection? I could prompt ahead of this, before the RDP connection is actually established, but the situations where input are going to be required aren't necessarily predictable. For example, if the server supports either RDP or TLS security, then the username and password do not have to be entered in order to establish the connection, so it's possible for the connection to go to the Windows login screen. If NLA security is in use, then the credentials must be provided prior to the connection being established. However, if you have authentication set to "any" (auto-detect), then it's hard to know before actually connecting to the server what is going to be required. I could make some assumptions about it (just ask for username and password if they aren't provided, assuming they'll be used at some point along the way), but maybe there are situations where people actually don't want to provide those at all, and don't want to be prompted for it? -Nick >
