On Fri, Mar 13, 2020 at 3:26 PM Jason Haar <jason_h...@trimble.com> wrote:
> This is a CentOS7 system running the downloaded install of guacamole-1.1.0 > - but using the yum install guacd (guacd-1.1.0-1.el7.x86_64). Even if I > have an older version, the error msg you see (Log in failed. Please > reconnect and try again) is also misleading. No amount of reconnecting is > going to fix this :-) > In your specific case, perhaps not. In general, the expectation would be that entering invalid credentials could be resolved by reconnecting and entering the correct credentials, or by the administrator resolving whatever transient configuration issue is preventing credentials from being accepted. Guacamole has an error code for invalid credentials which produces that message, however there is no distinct error code for "your credentials are invalid, but also the server will never accept any of that type of credentials and reconnecting is pointless". There is an error code for when the remote desktop server is refusing the connection. That might be more appropriate for the case that the server is refusing to accept the credentials provided, but it does still advise the user to try again. Shouldn't that error literally be what guacd was reporting in the logs? Way > more useful to the end-user > No, that level of specific internal details shouldn't normally be exposed to the end-user. It needs to be exposed to the administrator, hence being logged, but the full nature of internal failures should not be exposed to users that wouldn't normally be aware of those failures. > Oh yeah, it is behind an apache reverse proxy - so maybe that changes the > error message? > Not changing it per se, but it might be causing it. Can you share your Apache configuration? Also, what browser and version is being used when this occurs? In general, connection-specific error messages are passed through Guacamole-specific status codes via the Guacamole protocol, independent of the HTTP or WebSocket transport. The connection stability warning is distinct from those messages in that it's produced on the client side, based on whether the HTTP or WebSocket tunnels detect possible connection instability. - Mike
