[
https://issues.apache.org/jira/browse/GUACAMOLE-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521402#comment-17521402
]
Nick Couchman edited comment on GUACAMOLE-1563 at 4/13/22 1:05 AM:
-------------------------------------------------------------------
Thanks [~mjumper], sounds good, I'll try to brush it up and submit a couple of
PRs for it. Regarding your points:
* Yes, there should probably be some way to communicate back to the remote
server that the URI failed to open, possibly with some related reason for it. I
say possibly with some reason, because, in most cases the attempt by the
browser to open a URI that then fails to open is probably going to result in
some sort of error message on the local browser, so it probably makes sense to
avoid inundating the user with pop-ups telling them that something didn't work.
That said, it might make sense to give the user the option to open the URI
within the remote server, or at least make that a configurable option.
* I think this mechanism may actually be related to the above case - in the
case where the user opens a link, and the helper application and/or virtual
channel service cannot get that URI delivered to RDP channel, the user should
be given an option of what to do, next, or a configuration file can provide
those directives.
Also, it might be nice, from an admin perspective, to configure sites that
"bypass" the delivery of the URI to the RDP channel. I see this very similar to
how the Proxy Server configuration has functioned for the better part of three,
maybe four decades, now. In the case where a user may be connecting to a
virtual server inside an Intranet, and certain IPs or DNS names won't be
accessible outside that location, it would be useful to be able to have those
sites continue to open inside the browser on the remote system.
Seems like most of this will need to be done in the remote server side - the
guacd/guacamole-client parts are actually pretty minimal. That means a lot of
coding inside WIndoze - sigh -. Right now I'm writing everything in Visual
Studio, mainly because it has the necessary includes for the RDP Virtual
Channel. Is that going to cause any problems with publishing source and/or
binaries? Or any guidance or preference on using a different platform and API
to handle that?
Anyway, I"ll start shaping the code into something more PR-worthy and less
proof-that-it-can-be-done.
was (Author: nick.couch...@yahoo.com):
Thanks [~mjumper], sounds good, I'll try to brush it up and submit a couple of
PRs for it. Regarding your points:
* Yes, there should probably be some way to communicate back to the remote
server that the URI failed to open, possibly with some related reason for it. I
say possibly with some reason, because, in most cases the attempt by the
browser to open a URI that then fails to open is probably going to result in
some sort of error message on the local browser, so it probably makes sense to
avoid inundating the user with pop-ups telling them that something didn't work.
That said, it might make sense to give the user the option to open the URI
within the remote server, or at least make that a configurable option.
* I think this mechanism may actually be related to the above case - in the
case where the user opens a link, and the helper application and/or virtual
channel service cannot get that URI delivered to RDP channel, the user should
be given an option of what to do, next, or a configuration file can provide
those directives.
Also, it might be nice, from an admin perspective, to configure sites that that
"bypass" the delivery of the URI to the RDP channel. I see this very similar to
how the Proxy Server configuration has functioned for the better part of three,
maybe four decades, now. In the case where a user may be connecting to a
virtual server inside an Intranet, and certain IPs or DNS names won't be
accessible outside that location, it would be useful to be able to have those
sites continue to open inside the browser on the remote system.
Seems like most of this will need to be done in the remote server side - the
guacd/guacamole-client parts are actually pretty minimal. That means a lot of
coding inside WIndoze - sigh -. Right now I'm writing everything in Visual
Studio, mainly because it has the necessary includes for the RDP Virtual
Channel. Is that going to cause any problems with publishing source and/or
binaries? Or any guidance or preference on using a different platform and API
to handle that?
Anyway, I"ll start shaping the code into something more PR-worthy and less
proof-that-it-can-be-done.
> Question: Open link in external webbrowser
> ------------------------------------------
>
> Key: GUACAMOLE-1563
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1563
> Project: Guacamole
> Issue Type: Task
> Components: guacamole
> Reporter: peter
> Priority: Minor
>
> I'd like to open a link clicked within an RDP session to open in the external
> browser. In contrast to GUACAMOLE-1534 I'm in full control of what happens
> when a link is clicked. So I could, for example, fire a custom event within
> the RDP session that contains the link url.
> Can you point me in the direction of what needs to be done for this? For
> example:
> * Create an event listener
> [https://guacamole.apache.org/doc/gug/event-listeners.html|http://example.com/]
> * ? Create a tunnel ?
> * Register a custom event
> * Fire that event within the session
> * Catch it and retrieve the event payload
> Thanks in advance!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
