[jira] [Commented] (GUACAMOLE-884) Canvas Render Browser Memory Leakage
[
https://issues.apache.org/jira/browse/GUACAMOLE-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937968#comment-16937968
]
Michael Jumper commented on GUACAMOLE-884:
--
{quote}
Chrome, firefox, Safari, IE, edge browsers all have this problem.
{quote}
No, this does not occur with Firefox. I have not tested against IE, but either
way this remains a bug in the browser(s) in question, not within Guacamole. If
the workaround you describe will work without performance penalty, it may still
be worth doing, but we definitely shouldn't attempt to work around a browser
bug if doing so will hurt performance across the board. More on this below.
{quote}
We found that as long as we use the new image () to draw the image, we have
this problem.
{quote}
There does appear to have been old bugs in Chrome related to leaks in
{{Image}}, though they have been marked as fixed:
https://bugs.chromium.org/p/chromium/issues/detail?id=36142
https://bugs.chromium.org/p/chromium/issues/detail?id=114570
A very similar bug in WebKit, also marked as fixed, was recently reopened:
https://bugs.webkit.org/show_bug.cgi?id=31253
{quote}
But if you turn the base64 picture into blob, it's no problem to use the method
of createImageBitmap to produce image. But there is a big problem of browser
compatibility in createImageBitmap. Is the way you transmit data wrong? Maybe
there is a better choice for data transmission. Base64 pictures should not be
used. Many people say that frequently drawn canvas does not recommend base64
pictures, but rather RGBA matrix pictures.
{quote}
No, the way we transmit data is not wrong. Base64 is a perfectly valid
mechanism for transmitting data, and in this case happens to be the best
performing.
The choice of base64 was not made arbitrarily. Binary data transmission
mechanisms have been tested, as have other alternative encodings which require
manual decoding in JavaScript like a 7-bit encoding. In all cases, using base64
and data URIs far outperformed other methods. Minor gains in bandwidth due due
to using a more efficient encoding than base64 were eclipsed by performance
penalties due to {{Blob}}.
I will do a quick performance check and retry decoding received Base64 without
using {{Image}}, however I am expecting the same results as in past tests:
poorer responsiveness.
> Canvas Render Browser Memory Leakage
>
>
> Key: GUACAMOLE-884
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-884
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-common-js
>Affects Versions: 1.0.0
> Environment: guacamole 1.0
>Reporter: jianfeng chen
>Priority: Minor
> Attachments: 001.png, CorrectCode.png, guac-js-heap.png, pysh.py
>
>
> In SSH protocol, executing Python scripts will constantly render and refresh
> the interface, resulting in a gradual increase in browser memory, and finally
> browser crash.
> The script content is in the attachment.
> Execute script instructions：python pysh.py 1024 1
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GUACAMOLE-884) Canvas Render Browser Memory Leakage
[ https://issues.apache.org/jira/browse/GUACAMOLE-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937441#comment-16937441 ] Michael Jumper edited comment on GUACAMOLE-884 at 9/25/19 5:57 PM: --- Chrome, firefox, Safari, IE, edge browsers all have this problem. We found that as long as we use the new image () to draw the image, we have this problem. But if you turn the base64 picture into blob, it's no problem to use the method of createImageBitmap to produce image. But there is a big problem of browser compatibility in createImageBitmap. Is the way you transmit data wrong?Maybe there is a better choice for data transmission. Base64 pictures should not be used. Many people say that frequently drawn canvas does not recommend base64 pictures, but rather RGBA matrix pictures. !CorrectCode.png|width=100%! was (Author: chenjf): Chrome, firefox, Safari, IE, edge browsers all have this problem. We found that as long as we use the new image () to draw the image, we have this problem. But if you turn the base64 picture into blob, it's no problem to use the method of createImageBitmap to produce image. But there is a big problem of browser compatibility in createImageBitmap. Is the way you transmit data wrong?Maybe there is a better choice for data transmission. Base64 pictures should not be used. Many people say that frequently drawn canvas does not recommend base64 pictures, but rather RGBA matrix pictures. !CorrectCode.png! > Canvas Render Browser Memory Leakage > > > Key: GUACAMOLE-884 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-884 > Project: Guacamole > Issue Type: Bug > Components: guacamole-common-js >Affects Versions: 1.0.0 > Environment: guacamole 1.0 >Reporter: jianfeng chen >Priority: Minor > Attachments: 001.png, CorrectCode.png, guac-js-heap.png, pysh.py > > > In SSH protocol, executing Python scripts will constantly render and refresh > the interface, resulting in a gradual increase in browser memory, and finally > browser crash. > The script content is in the attachment. > Execute script instructions：python pysh.py 1024 1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GUACAMOLE-884) Canvas Render Browser Memory Leakage
[ https://issues.apache.org/jira/browse/GUACAMOLE-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936936#comment-16936936 ] Michael Jumper edited comment on GUACAMOLE-884 at 9/24/19 3:47 PM: --- Testing with your script, I see normal sawtooth heap behavior: !guac-js-heap.png|width=100%! While I do see "Memory footprint" in Chrome's task manager gradually growing, that is distinct from the JS heap, which hovers around 10 MB. You can see this yourself if you right click within the task manager and check "JavaScript memory" to display JS heap size in its own column. It doesn't look like there is a leak here, at least not within Guacamole. There is growth of memory usage, but that is external to the JavaScript heap and outside Guacamole (within Chrome). If there is a leak here, it may be a leak in Chrome, external to the JavaScript VM. was (Author: mike.jumper): Testing with your script, I see normal sawtooth heap behavior: !guac-js-heap.png|width=100%! While I do see "Memory footprint" in Chrome's task manager gradually growing, that is distinct from the JS heap, which is hovers around 10 MB. You can see this sourself if you right click within the task manager and check "JavaScript memory" to display the will show JS heap size in its own column. It doesn't look like there is a leak here, at least not within Guacamole. There is growth of memory usage, but that is external to the JavaScript heap and outside Guacamole (within Chrome). If there is a leak here, it may be a leak in Chrome, external to the JavaScript VM. > Canvas Render Browser Memory Leakage > > > Key: GUACAMOLE-884 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-884 > Project: Guacamole > Issue Type: Bug > Components: guacamole-common-js >Affects Versions: 1.0.0 > Environment: guacamole 1.0 >Reporter: jianfeng chen >Priority: Minor > Attachments: 001.png, guac-js-heap.png, pysh.py > > > In SSH protocol, executing Python scripts will constantly render and refresh > the interface, resulting in a gradual increase in browser memory, and finally > browser crash. > The script content is in the attachment. > Execute script instructions：python pysh.py 1024 1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-884) Canvas Render Browser Memory Leakage
[ https://issues.apache.org/jira/browse/GUACAMOLE-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936936#comment-16936936 ] Michael Jumper commented on GUACAMOLE-884: -- Testing with your script, I see normal sawtooth heap behavior: !guac-js-heap.png|width=100%! While I do see "Memory footprint" in Chrome's task manager gradually growing, that is distinct from the JS heap, which is hovers around 10 MB. You can see this sourself if you right click within the task manager and check "JavaScript memory" to display the will show JS heap size in its own column. It doesn't look like there is a leak here, at least not within Guacamole. There is growth of memory usage, but that is external to the JavaScript heap and outside Guacamole (within Chrome). If there is a leak here, it may be a leak in Chrome, external to the JavaScript VM. > Canvas Render Browser Memory Leakage > > > Key: GUACAMOLE-884 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-884 > Project: Guacamole > Issue Type: Bug > Components: guacamole-common-js >Affects Versions: 1.0.0 > Environment: guacamole 1.0 >Reporter: jianfeng chen >Priority: Minor > Attachments: 001.png, guac-js-heap.png, pysh.py > > > In SSH protocol, executing Python scripts will constantly render and refresh > the interface, resulting in a gradual increase in browser memory, and finally > browser crash. > The script content is in the attachment. > Execute script instructions：python pysh.py 1024 1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GUACAMOLE-884) Canvas Render Browser Memory Leakage
[ https://issues.apache.org/jira/browse/GUACAMOLE-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-884: - Attachment: guac-js-heap.png > Canvas Render Browser Memory Leakage > > > Key: GUACAMOLE-884 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-884 > Project: Guacamole > Issue Type: Bug > Components: guacamole-common-js >Affects Versions: 1.0.0 > Environment: guacamole 1.0 >Reporter: jianfeng chen >Priority: Minor > Attachments: 001.png, guac-js-heap.png, pysh.py > > > In SSH protocol, executing Python scripts will constantly render and refresh > the interface, resulting in a gradual increase in browser memory, and finally > browser crash. > The script content is in the attachment. > Execute script instructions：python pysh.py 1024 1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-249) Update RDP plugin support to 2.0.0 releases
[
https://issues.apache.org/jira/browse/GUACAMOLE-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935964#comment-16935964
]
Michael Jumper commented on GUACAMOLE-249:
--
{quote}
[~mjumper] Are you going to release a V1.1.0 =)?
{quote}
The project will, yes, after this and any other 1.1.0 issues are completed. At
the moment, I believe all issues within 1.1.0 scope have been completed except
for the following:
* GUACAMOLE-249 (this issue) and GUACAMOLE-707 (expected to be solved by this
issue)
* GUACAMOLE-234 (migration to the Apache Directory API for LDAP support,
currently showing regressions)
Once the migration to the FreeRDP 2.0.0-RC4 API is complete, there will also
need to be a good amount of regression testing to verify that absolutely
everything within RDP still functions, as well as to verify that things do
build on the various distributions shipping FreeRDP 2.0.0 packages. I'm
somewhat worried that the git snapshot used by Debian, Ubuntu, etc. to build
their FreeRDP packages will not actually have the same API as the 2.0.0-RC4
release candidate used by Fedora/CentOS/RHEL, despite appearing to have the
same version number.
> Update RDP plugin support to 2.0.0 releases
> ---
>
> Key: GUACAMOLE-249
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-249
> Project: Guacamole
> Issue Type: Improvement
> Components: RDP
>Reporter: Simone Caronni
>Assignee: Michael Jumper
>Priority: Critical
> Fix For: 1.1.0
>
> Attachments: Screenshot_2018-09-01_14-48-56.png
>
>
> The planets have aligned, after 2.5 years FreeRDP has released new snapshots:
> https://github.com/FreeRDP/FreeRDP/releases
> Thanks,
> --Simone
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-249) Update RDP plugin support to 2.0.0 releases
[
https://issues.apache.org/jira/browse/GUACAMOLE-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935140#comment-16935140
]
Michael Jumper commented on GUACAMOLE-249:
--
I am currently ripping away all the legacy structure/prototype/function checks,
conditional compilation, compatibility headers, etc. that we have been
maintaining to allow building against different releases of FreeRDP 1.x. It's
definitely a healing experience seeing all these compatibility layers removed.
So far:
{code:none}
[mjumper@dev-mjumper guacamole-server]$ git diff --stat staging/1.1.0
...
59 files changed, 118 insertions(+), 1596 deletions(-)
[mjumper@dev-mjumper guacamole-server]$
{code}
About a third of those deletions are {{configure.ac}}.
> Update RDP plugin support to 2.0.0 releases
> ---
>
> Key: GUACAMOLE-249
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-249
> Project: Guacamole
> Issue Type: Improvement
> Components: RDP
>Reporter: Simone Caronni
>Assignee: Michael Jumper
>Priority: Critical
> Fix For: 1.1.0
>
> Attachments: Screenshot_2018-09-01_14-48-56.png
>
>
> The planets have aligned, after 2.5 years FreeRDP has released new snapshots:
> https://github.com/FreeRDP/FreeRDP/releases
> Thanks,
> --Simone
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-249) Update RDP plugin support to 2.0.0 releases
[ https://issues.apache.org/jira/browse/GUACAMOLE-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932990#comment-16932990 ] Michael Jumper commented on GUACAMOLE-249: -- With various distributions adding FreeRDP 2.x packages, with some also dropping FreeRDP 1.x, this may actually simplify things. Part of the complexity here was the need to maintain support for both, which requires developing our own RDP API to stand between Guacamole and FreeRDP. If we can drop support for FreeRDP 1.x ourselves, that's a lot easier. > Update RDP plugin support to 2.0.0 releases > --- > > Key: GUACAMOLE-249 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-249 > Project: Guacamole > Issue Type: Improvement > Components: RDP >Reporter: Simone Caronni >Assignee: Michael Jumper >Priority: Critical > Fix For: 1.1.0 > > Attachments: Screenshot_2018-09-01_14-48-56.png > > > The planets have aligned, after 2.5 years FreeRDP has released new snapshots: > https://github.com/FreeRDP/FreeRDP/releases > Thanks, > --Simone -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-880) Obfuscation of guacamole client protocol
[ https://issues.apache.org/jira/browse/GUACAMOLE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16931004#comment-16931004 ] Michael Jumper commented on GUACAMOLE-880: -- [~Why4ArtThou], please remain civil. Insults, name-calling, etc. are not acceptable here. https://www.apache.org/foundation/policies/conduct.html > Obfuscation of guacamole client protocol > > > Key: GUACAMOLE-880 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-880 > Project: Guacamole > Issue Type: Wish > Components: guacamole-client, guacamole-server >Reporter: Bolke de Bruin >Priority: Major > Labels: security > > One of the reasons we deploy guacamole is to limit data leakage > possibilities. We recently had a audit on our infrastructure and it was shown > that it was quite easy to leak out data through the guacamole protocol by > creating special images inside the desktop and then using mitmproxy (python) > and the guacamole python modules to capture the data inside those images. > In order to limit the attack surface we would like to have obfuscation of the > protocol if configured to do so. Of course this could be done by implementing > a custom protocol, but it would be nice if Guacamole would have the > facilities (hooks) to do this. One could think of allowing a custom function > to encrypt/obfuscate the outgoing stream and attach into the javascript that > decrypts the stream. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GUACAMOLE-880) Obfuscation of guacamole client protocol
[ https://issues.apache.org/jira/browse/GUACAMOLE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16930104#comment-16930104 ] Michael Jumper commented on GUACAMOLE-880: -- [~bolke], it's not a corner case or an invalid use case (as you note, restricting the easy flow of data is part of the reasoning behind GUACAMOLE-381). Steganographic retransmission of data that is intended to be isolated to the machine being accessed is a legitimate concern for such an environment. If there is a known, accepted way to meaningfully defeat steganography, I'm sure we are open to it. Do you have examples of defenses which are known to be effective? Just as it's not recommended to write your own encryption algorithms with the expectation that they are secure, I don't think we can just throw noise into transmitted images with the hope that steganography will then be too difficult. There would need to be a solution that can be proven to work, or at least one that is accepted as a solution by those that are experts in the field. My expectation (though I would be happy to be proven wrong) is that no such solution exists. In general, for any remote desktop protocol, graphics and timing data must have a reasonable degree of fidelity, and it's an unfortunate reality that those same graphics and timing data can be used for covert transmission of other data. As long as the graphics are still readable / usable by the users of the system, they can function as a channel for steganographic transmission of data, even if that channel is lossy. As such, my understanding is that it is not possible to defeat steganography without simultaneously making the system unusable. As for the final point of the protocol itself being easy to parse, or the API being accessible ... There will always exist libraries for parsing the Guacamole protocol, and part of good library/protocol design is that those libraries and that protocol remain that way. While the merits of possible defenses to steganography are worth discussing, I don't think there is any security basis for trying to make the protocol or API more complex and hoping attackers will not want to bother. > Obfuscation of guacamole client protocol > > > Key: GUACAMOLE-880 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-880 > Project: Guacamole > Issue Type: Wish > Components: guacamole-client, guacamole-server >Reporter: Bolke de Bruin >Priority: Major > Labels: security > > One of the reasons we deploy guacamole is to limit data leakage > possibilities. We recently had a audit on our infrastructure and it was shown > that it was quite easy to leak out data through the guacamole protocol by > creating special images inside the desktop and then using mitmproxy (python) > and the guacamole python modules to capture the data inside those images. > In order to limit the attack surface we would like to have obfuscation of the > protocol if configured to do so. Of course this could be done by implementing > a custom protocol, but it would be nice if Guacamole would have the > facilities (hooks) to do this. One could think of allowing a custom function > to encrypt/obfuscate the outgoing stream and attach into the javascript that > decrypts the stream. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GUACAMOLE-880) Obfuscation of guacamole client protocol
[
https://issues.apache.org/jira/browse/GUACAMOLE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16930050#comment-16930050
]
Michael Jumper commented on GUACAMOLE-880:
--
{quote}
For some more background on what is currently possible (and our penetration
test actually went a bit further): https://rtheory.net/analysis/guac/
{quote}
Doesn't the above post simply go over what can be done to any unencrypted web
application that provides a public API? Without something like TLS to guarantee
integrity, I would think it goes without saying that any malicious third party
would have the exact same capabilities as the legitimate user.
> Obfuscation of guacamole client protocol
>
>
> Key: GUACAMOLE-880
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-880
> Project: Guacamole
> Issue Type: Wish
> Components: guacamole-client, guacamole-server
>Reporter: Bolke de Bruin
>Priority: Major
> Labels: security
>
> One of the reasons we deploy guacamole is to limit data leakage
> possibilities. We recently had a audit on our infrastructure and it was shown
> that it was quite easy to leak out data through the guacamole protocol by
> creating special images inside the desktop and then using mitmproxy (python)
> and the guacamole python modules to capture the data inside those images.
> In order to limit the attack surface we would like to have obfuscation of the
> protocol if configured to do so. Of course this could be done by implementing
> a custom protocol, but it would be nice if Guacamole would have the
> facilities (hooks) to do this. One could think of allowing a custom function
> to encrypt/obfuscate the outgoing stream and attach into the javascript that
> decrypts the stream.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (GUACAMOLE-880) Obfuscation of guacamole client protocol
[ https://issues.apache.org/jira/browse/GUACAMOLE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16930049#comment-16930049 ] Michael Jumper commented on GUACAMOLE-880: -- My understanding is: # It is possible to generate an image which encodes arbitrary data graphically, and to retrieve that data from that image. # Libraries exist for parsing Guacamole protocol data, which inherently contains graphics. # It is therefore possible to encode arbitrary data such that Guacamole will transmit it graphically, parse the Guacamole protocol using an available library, and ultimately decode that data. Am I missing something above? > Obfuscation of guacamole client protocol > > > Key: GUACAMOLE-880 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-880 > Project: Guacamole > Issue Type: Wish > Components: guacamole-client, guacamole-server >Reporter: Bolke de Bruin >Priority: Major > Labels: security > > One of the reasons we deploy guacamole is to limit data leakage > possibilities. We recently had a audit on our infrastructure and it was shown > that it was quite easy to leak out data through the guacamole protocol by > creating special images inside the desktop and then using mitmproxy (python) > and the guacamole python modules to capture the data inside those images. > In order to limit the attack surface we would like to have obfuscation of the > protocol if configured to do so. Of course this could be done by implementing > a custom protocol, but it would be nice if Guacamole would have the > facilities (hooks) to do this. One could think of allowing a custom function > to encrypt/obfuscate the outgoing stream and attach into the javascript that > decrypts the stream. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Reopened] (GUACAMOLE-880) Obfuscation of guacamole client protocol
[ https://issues.apache.org/jira/browse/GUACAMOLE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper reopened GUACAMOLE-880: -- > Obfuscation of guacamole client protocol > > > Key: GUACAMOLE-880 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-880 > Project: Guacamole > Issue Type: Wish > Components: guacamole-client, guacamole-server >Reporter: Bolke de Bruin >Priority: Major > Labels: security > > One of the reasons we deploy guacamole is to limit data leakage > possibilities. We recently had a audit on our infrastructure and it was shown > that it was quite easy to leak out data through the guacamole protocol by > creating special images inside the desktop and then using mitmproxy (python) > and the guacamole python modules to capture the data inside those images. > In order to limit the attack surface we would like to have obfuscation of the > protocol if configured to do so. Of course this could be done by implementing > a custom protocol, but it would be nice if Guacamole would have the > facilities (hooks) to do this. One could think of allowing a custom function > to encrypt/obfuscate the outgoing stream and attach into the javascript that > decrypts the stream. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (GUACAMOLE-880) Obfuscation of guacamole client protocol
[ https://issues.apache.org/jira/browse/GUACAMOLE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper closed GUACAMOLE-880. Resolution: Invalid > Obfuscation of guacamole client protocol > > > Key: GUACAMOLE-880 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-880 > Project: Guacamole > Issue Type: Wish > Components: guacamole-client, guacamole-server >Reporter: Bolke de Bruin >Priority: Major > Labels: security > > One of the reasons we deploy guacamole is to limit data leakage > possibilities. We recently had a audit on our infrastructure and it was shown > that it was quite easy to leak out data through the guacamole protocol by > creating special images inside the desktop and then using mitmproxy (python) > and the guacamole python modules to capture the data inside those images. > In order to limit the attack surface we would like to have obfuscation of the > protocol if configured to do so. Of course this could be done by implementing > a custom protocol, but it would be nice if Guacamole would have the > facilities (hooks) to do this. One could think of allowing a custom function > to encrypt/obfuscate the outgoing stream and attach into the javascript that > decrypts the stream. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Reopened] (GUACAMOLE-880) Obfuscation of guacamole client protocol
[ https://issues.apache.org/jira/browse/GUACAMOLE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper reopened GUACAMOLE-880: -- > Obfuscation of guacamole client protocol > > > Key: GUACAMOLE-880 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-880 > Project: Guacamole > Issue Type: Wish > Components: guacamole-client, guacamole-server >Reporter: Bolke de Bruin >Priority: Major > Labels: security > > One of the reasons we deploy guacamole is to limit data leakage > possibilities. We recently had a audit on our infrastructure and it was shown > that it was quite easy to leak out data through the guacamole protocol by > creating special images inside the desktop and then using mitmproxy (python) > and the guacamole python modules to capture the data inside those images. > In order to limit the attack surface we would like to have obfuscation of the > protocol if configured to do so. Of course this could be done by implementing > a custom protocol, but it would be nice if Guacamole would have the > facilities (hooks) to do this. One could think of allowing a custom function > to encrypt/obfuscate the outgoing stream and attach into the javascript that > decrypts the stream. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (GUACAMOLE-880) Obfuscation of guacamole client protocol
[ https://issues.apache.org/jira/browse/GUACAMOLE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16930017#comment-16930017 ] Michael Jumper edited comment on GUACAMOLE-880 at 9/15/19 5:38 PM: --- There is no level of obfuscation which would prevent the legitimate users of any remote desktop protocol from obtaining information from the graphical content of their own sessions, at least not without making things unusable. Obtaining information from received graphics is exactly what the human brain does when it accesses a remote desktop. You cannot prevent this. Any attempt to obfuscate things while still allowing the remote desktop to be usable would amount to [security through obscurity|https://en.wikipedia.org/wiki/Security_through_obscurity]. As far as ensuring that users external to a remote desktop session cannot capture the content of other sessions, Guacamole already supports this through encryption. It is expected that Guacamole deployments will use SSL/TLS in front of the web application in production. If needed in your use case, you can also enable SSL/TLS between the web application and guacd. was (Author: mike.jumper): There is no level of obfuscation which would prevent the legitimate users of any remote desktop protocol from obtaining information from the graphical content of their own sessions, at least without making things unusable. Obtaining information from received graphics is exactly what the human brain does when it accesses a remote desktop. You cannot prevent this. Any to obfuscate things while still allowing the remote desktop to be usable would amount to [security through obscurity|https://en.wikipedia.org/wiki/Security_through_obscurity]. As far as ensuring that users external to a remote desktop session cannot capture the content of other sessions, Guacamole already supports this through encryption. It is expected that Guacamole deployments will use SSL/TLS in front of the web application in production. If needed in your use case, you can also enable SSL/TLS between the web application and guacd. > Obfuscation of guacamole client protocol > > > Key: GUACAMOLE-880 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-880 > Project: Guacamole > Issue Type: Wish > Components: guacamole-client, guacamole-server >Reporter: Bolke de Bruin >Priority: Major > Labels: security > > One of the reasons we deploy guacamole is to limit data leakage > possibilities. We recently had a audit on our infrastructure and it was shown > that it was quite easy to leak out data through the guacamole protocol by > creating special images inside the desktop and then using mitmproxy (python) > and the guacamole python modules to capture the data inside those images. > In order to limit the attack surface we would like to have obfuscation of the > protocol if configured to do so. Of course this could be done by implementing > a custom protocol, but it would be nice if Guacamole would have the > facilities (hooks) to do this. One could think of allowing a custom function > to encrypt/obfuscate the outgoing stream and attach into the javascript that > decrypts the stream. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (GUACAMOLE-880) Obfuscation of guacamole client protocol
[ https://issues.apache.org/jira/browse/GUACAMOLE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper closed GUACAMOLE-880. Resolution: Invalid > Obfuscation of guacamole client protocol > > > Key: GUACAMOLE-880 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-880 > Project: Guacamole > Issue Type: Wish > Components: guacamole-client, guacamole-server >Reporter: Bolke de Bruin >Priority: Major > Labels: security > > One of the reasons we deploy guacamole is to limit data leakage > possibilities. We recently had a audit on our infrastructure and it was shown > that it was quite easy to leak out data through the guacamole protocol by > creating special images inside the desktop and then using mitmproxy (python) > and the guacamole python modules to capture the data inside those images. > In order to limit the attack surface we would like to have obfuscation of the > protocol if configured to do so. Of course this could be done by implementing > a custom protocol, but it would be nice if Guacamole would have the > facilities (hooks) to do this. One could think of allowing a custom function > to encrypt/obfuscate the outgoing stream and attach into the javascript that > decrypts the stream. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GUACAMOLE-880) Obfuscation of guacamole client protocol
[ https://issues.apache.org/jira/browse/GUACAMOLE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16930017#comment-16930017 ] Michael Jumper commented on GUACAMOLE-880: -- There is no level of obfuscation which would prevent the legitimate users of any remote desktop protocol from obtaining information from the graphical content of their own sessions, at least without making things unusable. Obtaining information from received graphics is exactly what the human brain does when it accesses a remote desktop. You cannot prevent this. Any to obfuscate things while still allowing the remote desktop to be usable would amount to [security through obscurity|https://en.wikipedia.org/wiki/Security_through_obscurity]. As far as ensuring that users external to a remote desktop session cannot capture the content of other sessions, Guacamole already supports this through encryption. It is expected that Guacamole deployments will use SSL/TLS in front of the web application in production. If needed in your use case, you can also enable SSL/TLS between the web application and guacd. > Obfuscation of guacamole client protocol > > > Key: GUACAMOLE-880 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-880 > Project: Guacamole > Issue Type: Wish > Components: guacamole-client, guacamole-server >Reporter: Bolke de Bruin >Priority: Major > Labels: security > > One of the reasons we deploy guacamole is to limit data leakage > possibilities. We recently had a audit on our infrastructure and it was shown > that it was quite easy to leak out data through the guacamole protocol by > creating special images inside the desktop and then using mitmproxy (python) > and the guacamole python modules to capture the data inside those images. > In order to limit the attack surface we would like to have obfuscation of the > protocol if configured to do so. Of course this could be done by implementing > a custom protocol, but it would be nice if Guacamole would have the > facilities (hooks) to do this. One could think of allowing a custom function > to encrypt/obfuscate the outgoing stream and attach into the javascript that > decrypts the stream. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (GUACAMOLE-878) LDAP user list is not shown in admin dashboard
[ https://issues.apache.org/jira/browse/GUACAMOLE-878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper closed GUACAMOLE-878. Resolution: Invalid For LDAP users to appear within the users tab, you must log in as an LDAP user, and that user's corresponding account in the database must have administrative privileges. See: http://guacamole.apache.org/doc/gug/ldap-auth.html#ldap-and-database > LDAP user list is not shown in admin dashboard > -- > > Key: GUACAMOLE-878 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-878 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-ldap >Reporter: Ali Zamani >Priority: Minor > > After integrating Guacamole with LDAP, users from LDAP can login; However, > LDAP user list is not appeared in the admin -> settings -> users. So there's > no control in the GUI on privilege and connections associated to each LDAP > user. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GUACAMOLE-478) RDP clipboard uses incorrect newline characters
[
https://issues.apache.org/jira/browse/GUACAMOLE-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927209#comment-16927209
]
Michael Jumper commented on GUACAMOLE-478:
--
{quote}
Why are newlines being converted at all? I would argue all newlines should be
left intact, and if we need to add any (i.e. modifications made in the
guacamole overlay) we can choose a sensible default.
{quote}
They are not currently being converted, at least not by Guacamole nor any part
of the stack. They are being normalized by the browser.
The problem is not that the web application is incorrectly converting newlines,
but that no such conversion is performed. Since Windows RDP seems to expect
Windows-style CR+LF newlines within the clipboard, things will not work as
expected if the browser uses different newlines within the clipboard data
provided to Guacamole. The solution is to perform the required conversion and
not assume that the browser will provide clipboard data in the same format as
the remote desktop server requires.
Before that is done, it needs to be established whether CR+LF newlines are a
requirement for all text clipboard data for RDP, or if this is only the case
for Windows. This will dictate whether the conversion needs to be tied to a
connection parameter.
> RDP clipboard uses incorrect newline characters
> ---
>
> Key: GUACAMOLE-478
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-478
> Project: Guacamole
> Issue Type: Bug
> Components: RDP
>Reporter: Amarjeet Singh
>Priority: Minor
> Attachments: guacamole_clipboard_interfering_with_windows_newlines.mp4
>
>
> With the RDP protocol originating from Windows, the format of text clipboard
> contents is assumed to use Windows-style newline characters (CR+LF).
> Guacamole currently does not attempt to translate newline characters, sending
> the format used within the received clipboard stream. This means that
> applications running within RDP which only support Windows-style newlines,
> such as Notepad, fail to handle received clipboard data.
> Applications which can handle both UNIX-style and Windows-style newline
> characters are unaffected.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Closed] (GUACAMOLE-879) docker image guacd install fonts for ssh to render
[
https://issues.apache.org/jira/browse/GUACAMOLE-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper closed GUACAMOLE-879.
Resolution: Invalid
Please don't open a bug report if you simply have a question about Guacamole.
Use the u...@guacamole.apache.org mailing list instead:
http://guacamole.apache.org/support/#mailing-lists
Thanks.
> docker image guacd install fonts for ssh to render
> ---
>
> Key: GUACAMOLE-879
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-879
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole
>Reporter: Evan Wang
>Priority: Major
> Attachments: 1568108587(1).png, 微信截图_20190910174329.png,
> 微信截图_20190910174356.png
>
>
> I use {{guacamole/guacd}}:1.0.0 to deploy guacad.
> I need to use SSH to render chinese.
> So I docker exec into the container(build from {{guacamole/guacd}}:1.0.0) and
> run
> {code:java}
> apt-get install fonts-wqy-zenhei
> fc-cache
> {code}
> Then I config the SSH connection, set font-name to "WenQuanYi Zen Hei" and
> reconnect it.
> The font size might be changed but font still not changed.
> How should I do ?
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GUACAMOLE-872) Guacamole Rest API Documentation
[ https://issues.apache.org/jira/browse/GUACAMOLE-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-872: - Fix Version/s: (was: 1.1.0) > Guacamole Rest API Documentation > - > > Key: GUACAMOLE-872 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-872 > Project: Guacamole > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.0.0 > Environment: XML >Reporter: samir chahine >Priority: Minor > Labels: pull-request-available > Attachments: Screen Shot 2019-09-05 at 4.14.41 pm.png > > Original Estimate: 0h > Remaining Estimate: 0h > > I have created a new page for information regarding the access of the > Guacamole API through a Rest Framework. > In my search for a well documented list of api calls I was never able to find > one, rather I broke apart the pre-built API to discover the endpoints > necessary to make these functionalities possible. > > This is the pull request: > [https://github.com/apache/guacamole-manual/pull/123] -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (GUACAMOLE-699) Multiple fixes and improvements for the german translation
[ https://issues.apache.org/jira/browse/GUACAMOLE-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper resolved GUACAMOLE-699. -- Resolution: Done > Multiple fixes and improvements for the german translation > -- > > Key: GUACAMOLE-699 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-699 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-client >Affects Versions: 1.0.0 >Reporter: leetxyz >Priority: Trivial > Fix For: 1.1.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Oh hai > While testing the new 1.0.0 release I found a bunch of typos, missing strings > and completely missing translations (e.g. in guacamole-auth-totp and in > guacamole-auth-cas) in the german language files. > Is someone already working on this? If not, do I just need to update > guacamole-client/guacamole/src/main/webapp/translations/de.json or are there > any other files? > For the translation of the extension, can I just copy > guacamole-client/extensions/guacamole-auth-*/src/main/resources/translations/en.json > to de.json and translate it? > This is my first time trying to get involved in open source, please contact > me if I did something wrong in the process. > best regards -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (GUACAMOLE-870) Connection history query fails against SQL Server
Michael Jumper created GUACAMOLE-870:
Summary: Connection history query fails against SQL Server
Key: GUACAMOLE-870
URL: https://issues.apache.org/jira/browse/GUACAMOLE-870
Project: Guacamole
Issue Type: Bug
Components: guacamole-auth-jdbc-sqlserver
Reporter: Michael Jumper
While the connection history initially displays correctly, any queries against
the history fail with the following error:
{code:none}
com.microsoft.sqlserver.jdbc.SQLServerException: Incorrect syntax near
'username'.
{code}
This is due to the use of the {{POSITION()}} function within the query and is
presumably a holdover from the initial creation of SQL Server support for
Guacamole. This function is present in both the MySQL and PostgreSQL flavors of
the Guacamole history query, which predate SQL Server support and would have
been used as its basis.
Unlike MySQL and PostgreSQL, SQL Server does not support the {{POSITION()}}
function. The {{CHARINDEX()}} function should be used instead.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Closed] (GUACAMOLE-866) guacamole can not upload folder！
[ https://issues.apache.org/jira/browse/GUACAMOLE-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper closed GUACAMOLE-866. Resolution: Duplicate Not a bug, just not implemented. Demand for the feature you describe is not high, presumably because you can already upload multiple files at the same time by simply dragging the contents of a folder rather than the folder itself. Duplicate of GUACAMOLE-612. > guacamole can not upload folder！ > > > Key: GUACAMOLE-866 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-866 > Project: Guacamole > Issue Type: Bug > Components: guacamole >Affects Versions: 1.0.0 > Environment: guacamole1.0 >Reporter: vicent.wu >Priority: Major > > now ctrl+alt+shift can upload file，but can not upload folder ，i think > guacamole have no this features or have this feature but I didn't find it ? > or if there is no such function, is it considered to increase the demand? > thanks!! -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (GUACAMOLE-630) Allow terminal color scheme to be changed while connection is running
[ https://issues.apache.org/jira/browse/GUACAMOLE-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907848#comment-16907848 ] Michael Jumper edited comment on GUACAMOLE-630 at 8/15/19 11:48 PM: It looks like it's all Pickr, actually. Some sort of lengthy init or animation, multiplied by 18 (16 palette colors, plus foreground and background): !guacamole-630-profile-ctrl-alt-shift.png|width=100%! We may need to either find another decent color picker, or look into ways to have an instance of Pickr be both shared and pre-initialized. was (Author: mike.jumper): It looks like it's all Pickr, actually. Some sort of length init or animation, multiplied by 18 (16 palette colors, plus foreground and background): !guacamole-630-profile-ctrl-alt-shift.png|width=100%! We may need to either find another decent color picker, or look into ways to have an instance of Pickr be both shared and pre-initialized. > Allow terminal color scheme to be changed while connection is running > - > > Key: GUACAMOLE-630 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-630 > Project: Guacamole > Issue Type: New Feature > Components: SSH, Telnet >Reporter: Michael Jumper >Assignee: Michael Jumper >Priority: Trivial > Fix For: 1.1.0 > > Attachments: guacamole-630-profile-ctrl-alt-shift.png > > > As mentioned within GUACAMOLE-629, the Guacamole protocol currently imposes > limitations on the parameters which configure a connection. As the color > scheme used by the terminal of an SSH/telnet connection is one such > parameter, the terminal interface is limited to a pre-configured color scheme > which cannot be changed while the connection is active. > It would be awfully nice if the color scheme of the terminal could be changed > by the user without administrative access, and without requiring > disconnect/reconnect. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Comment Edited] (GUACAMOLE-630) Allow terminal color scheme to be changed while connection is running
[ https://issues.apache.org/jira/browse/GUACAMOLE-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907848#comment-16907848 ] Michael Jumper edited comment on GUACAMOLE-630 at 8/15/19 6:06 AM: --- It looks like it's all Pickr, actually. Some sort of length init or animation, multiplied by 18 (16 palette colors, plus foreground and background): !guacamole-630-profile-ctrl-alt-shift.png|width=100%! We may need to either find another decent color picker, or look into ways to have an instance of Pickr be both shared and pre-initialized. was (Author: mike.jumper): It looks like it's all Pickr, actually. Some sort of length init or animation, multiplied by 18 (16 palette colors, plus foreground and background): !guacamole-630-profile-ctrl-alt-shift.png|thumbnail! We may need to either find another decent color picker, or look into ways to have an instance of Pickr be both shared and pre-initialized. > Allow terminal color scheme to be changed while connection is running > - > > Key: GUACAMOLE-630 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-630 > Project: Guacamole > Issue Type: New Feature > Components: SSH, Telnet >Reporter: Michael Jumper >Assignee: Michael Jumper >Priority: Trivial > Fix For: 1.1.0 > > Attachments: guacamole-630-profile-ctrl-alt-shift.png > > > As mentioned within GUACAMOLE-629, the Guacamole protocol currently imposes > limitations on the parameters which configure a connection. As the color > scheme used by the terminal of an SSH/telnet connection is one such > parameter, the terminal interface is limited to a pre-configured color scheme > which cannot be changed while the connection is active. > It would be awfully nice if the color scheme of the terminal could be changed > by the user without administrative access, and without requiring > disconnect/reconnect. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GUACAMOLE-630) Allow terminal color scheme to be changed while connection is running
[ https://issues.apache.org/jira/browse/GUACAMOLE-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907848#comment-16907848 ] Michael Jumper commented on GUACAMOLE-630: -- It looks like it's all Pickr, actually. Some sort of length init or animation, multiplied by 18 (16 palette colors, plus foreground and background): !guacamole-630-profile-ctrl-alt-shift.png|thumbnail! We may need to either find another decent color picker, or look into ways to have an instance of Pickr be both shared and pre-initialized. > Allow terminal color scheme to be changed while connection is running > - > > Key: GUACAMOLE-630 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-630 > Project: Guacamole > Issue Type: New Feature > Components: SSH, Telnet >Reporter: Michael Jumper >Assignee: Michael Jumper >Priority: Trivial > Fix For: 1.1.0 > > Attachments: guacamole-630-profile-ctrl-alt-shift.png > > > As mentioned within GUACAMOLE-629, the Guacamole protocol currently imposes > limitations on the parameters which configure a connection. As the color > scheme used by the terminal of an SSH/telnet connection is one such > parameter, the terminal interface is limited to a pre-configured color scheme > which cannot be changed while the connection is active. > It would be awfully nice if the color scheme of the terminal could be changed > by the user without administrative access, and without requiring > disconnect/reconnect. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Reopened] (GUACAMOLE-630) Allow terminal color scheme to be changed while connection is running
[ https://issues.apache.org/jira/browse/GUACAMOLE-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper reopened GUACAMOLE-630: -- I'm seeing a performance regression when opening the Guacamole menu on an SSH/telnet connection, with the menu taking a good few seconds to open while JS hangs. I suspect this may be due to GUACAMOLE-630, with lengthy AngularJS digest cycle(s) resulting from the fancy palette UI. Will debug... > Allow terminal color scheme to be changed while connection is running > - > > Key: GUACAMOLE-630 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-630 > Project: Guacamole > Issue Type: New Feature > Components: SSH, Telnet >Reporter: Michael Jumper >Assignee: Michael Jumper >Priority: Trivial > Fix For: 1.1.0 > > > As mentioned within GUACAMOLE-629, the Guacamole protocol currently imposes > limitations on the parameters which configure a connection. As the color > scheme used by the terminal of an SSH/telnet connection is one such > parameter, the terminal interface is limited to a pre-configured color scheme > which cannot be changed while the connection is active. > It would be awfully nice if the color scheme of the terminal could be changed > by the user without administrative access, and without requiring > disconnect/reconnect. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Reopened] (GUACAMOLE-234) Migrate from JLDAP to Apache Directory LDAP API
[
https://issues.apache.org/jira/browse/GUACAMOLE-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper reopened GUACAMOLE-234:
--
Coverity reports the following:
{code:none}
*** CID 1452278: Resource leaks (RESOURCE_LEAK)
/extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/ObjectQueryService.java:
226 in
org.apache.guacamole.auth.ldap.ObjectQueryService.search(org.apache.directory.ldap.client.api.LdapNetworkConnection,
org.apache.directory.api.ldap.model.name.Dn,
org.apache.directory.api.ldap.model.filter.ExprNode, int)()
220 }
221
222 }
223
224 }
225
>>> CID 1452278: Resource leaks (RESOURCE_LEAK)
>>> Variable "results" going out of scope leaks the resource it refers to.
226 return entries;
227
228 }
229 catch (CursorException | LdapException e) {
230 throw new GuacamoleServerException("Unable to query list of
"
231 + "objects from LDAP directory.", e);
{code}
{code:none}
*** CID 1452280: Exceptional resource leaks (RESOURCE_LEAK)
/extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/LDAPConnectionService.java:
140 in
org.apache.guacamole.auth.ldap.LDAPConnectionService.bindAs(org.apache.directory.api.ldap.model.name.Dn,
java.lang.String)()
134 try {
135
136 // Connect to LDAP server
137 ldapConnection.connect();
138
139 // Explicitly start TLS if requested
>>> CID 1452280: Exceptional resource leaks (RESOURCE_LEAK)
>>> Variable "ldapConnection" going out of scope leaks the resource it
>>> refers to.
140 if (confService.getEncryptionMethod() ==
EncryptionMethod.STARTTLS)
141 ldapConnection.startTls();
142
143 }
144 catch (LdapException e) {
145 throw new GuacamoleServerException("Error connecting to
LDAP server.", e);
{code}
There's also this, but I believe it's a false positive, seeing as it's a
debug-level log message:
{code:none}
*** CID 1452279: Low impact security (SENSITIVE_DATA_LEAK)
/extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/ObjectQueryService.java:
189 in
org.apache.guacamole.auth.ldap.ObjectQueryService.search(org.apache.directory.ldap.client.api.LdapNetworkConnection,
org.apache.directory.api.ldap.model.name.Dn,
org.apache.directory.api.ldap.model.filter.ExprNode, int)()
183 * information required to execute the query cannot be read from
184 * guacamole.properties.
185 */
186 public List search(LdapNetworkConnection ldapConnection,
187 Dn baseDN, ExprNode query, int searchHop) throws
GuacamoleException {
188
>>> CID 1452279: Low impact security (SENSITIVE_DATA_LEAK)
>>> Leaking persistent secret data, "baseDN". Passing it to
>>> "org.slf4j.Logger.debug(java.lang.String, java.lang.Object,
>>> java.lang.Object)" stores it to a log file or displays it on the console.
189 logger.debug("Searching \"{}\" for objects matching \"{}\".",
baseDN, query);
190
191 try {
192
193 LdapConnectionConfig ldapConnectionConfig =
ldapConnection.getConfig();
194
{code}
> Migrate from JLDAP to Apache Directory LDAP API
> ---
>
> Key: GUACAMOLE-234
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-234
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-auth-ldap
>Reporter: Michael Jumper
>Assignee: Nick Couchman
>Priority: Minor
> Fix For: 1.1.0
>
>
> The LDAP support currently uses [JLDAP|http://www.openldap.org/jldap/], but
> that library has been unmaintained for several years now (no changes
> whatsoever since 2009). Migrating away from such a library might be a good
> idea. The Apache Directory project has produced an LDAP client API which
> could serve as a replacement:
> http://directory.apache.org/api/
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (GUACAMOLE-360) Autoreconnect only most recent session
[ https://issues.apache.org/jira/browse/GUACAMOLE-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper resolved GUACAMOLE-360. -- Resolution: Done > Autoreconnect only most recent session > -- > > Key: GUACAMOLE-360 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-360 > Project: Guacamole > Issue Type: New Feature > Components: guacamole-client >Reporter: Matt Prager >Assignee: Michael Jumper >Priority: Minor > Fix For: 1.1.0 > > > I've had an issue with Guacamole where I forget to logoff a VNC session, go > use a completely different computer or device, try to login to the same > session and get caught in an "autoreconnect loop" where the new session logs > off off the old session which then autoreconnects that old session and logs > off the new session ad inifinitum. There's no way to stop this because, if > I'm not in front of the computer I forgot to log off, I have no way of > shutting down that session remotely. > Since many of us leave tabs open rather than remembering to close them, it > seems that the behavior should be, in the event of a user trying to > simultaneously log into the same session, that autoreconnect should only > apply to the most recent session and the older session should be disconnected > and remain that way. > Otherwise, you run into a situation where you were using Guacamole at the > office to log into a VNC session and are then unable to use Guacamole to log > into that session from anywhere else which sort of defeats the purpose of > remote access. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GUACAMOLE-360) Autoreconnect only most recent session
[
https://issues.apache.org/jira/browse/GUACAMOLE-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904535#comment-16904535
]
Michael Jumper commented on GUACAMOLE-360:
--
I'm moving forward with a slightly simpler approach with the
{{ActiveConnection}} interface simply extending {{Connectable}} in addition to
its other base interfaces. Following that refactor through, admins can join any
active connection and users can join any of their own active connections.
> Autoreconnect only most recent session
> --
>
> Key: GUACAMOLE-360
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-360
> Project: Guacamole
> Issue Type: New Feature
> Components: guacamole-client
>Reporter: Matt Prager
>Assignee: Michael Jumper
>Priority: Minor
> Fix For: 1.1.0
>
>
> I've had an issue with Guacamole where I forget to logoff a VNC session, go
> use a completely different computer or device, try to login to the same
> session and get caught in an "autoreconnect loop" where the new session logs
> off off the old session which then autoreconnects that old session and logs
> off the new session ad inifinitum. There's no way to stop this because, if
> I'm not in front of the computer I forgot to log off, I have no way of
> shutting down that session remotely.
> Since many of us leave tabs open rather than remembering to close them, it
> seems that the behavior should be, in the event of a user trying to
> simultaneously log into the same session, that autoreconnect should only
> apply to the most recent session and the older session should be disconnected
> and remain that way.
> Otherwise, you run into a situation where you were using Guacamole at the
> office to log into a VNC session and are then unable to use Guacamole to log
> into that session from anywhere else which sort of defeats the purpose of
> remote access.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (GUACAMOLE-360) Autoreconnect only most recent session
[ https://issues.apache.org/jira/browse/GUACAMOLE-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper reassigned GUACAMOLE-360: Assignee: Michael Jumper (was: Nick Couchman) > Autoreconnect only most recent session > -- > > Key: GUACAMOLE-360 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-360 > Project: Guacamole > Issue Type: New Feature > Components: guacamole-client >Reporter: Matt Prager >Assignee: Michael Jumper >Priority: Minor > Fix For: 1.1.0 > > > I've had an issue with Guacamole where I forget to logoff a VNC session, go > use a completely different computer or device, try to login to the same > session and get caught in an "autoreconnect loop" where the new session logs > off off the old session which then autoreconnects that old session and logs > off the new session ad inifinitum. There's no way to stop this because, if > I'm not in front of the computer I forgot to log off, I have no way of > shutting down that session remotely. > Since many of us leave tabs open rather than remembering to close them, it > seems that the behavior should be, in the event of a user trying to > simultaneously log into the same session, that autoreconnect should only > apply to the most recent session and the older session should be disconnected > and remain that way. > Otherwise, you run into a situation where you were using Guacamole at the > office to log into a VNC session and are then unable to use Guacamole to log > into that session from anywhere else which sort of defeats the purpose of > remote access. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GUACAMOLE-630) Allow terminal color scheme to be changed while connection is running
[
https://issues.apache.org/jira/browse/GUACAMOLE-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper resolved GUACAMOLE-630.
--
Resolution: Done
The webapp now provides an interface for this, driven by the {{argv}}
instruction and leveraging the [Pickr|https://github.com/Simonwep/pickr] color
picker.
> Allow terminal color scheme to be changed while connection is running
> -
>
> Key: GUACAMOLE-630
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-630
> Project: Guacamole
> Issue Type: New Feature
> Components: SSH, Telnet
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>Priority: Trivial
> Fix For: 1.1.0
>
>
> As mentioned within GUACAMOLE-629, the Guacamole protocol currently imposes
> limitations on the parameters which configure a connection. As the color
> scheme used by the terminal of an SSH/telnet connection is one such
> parameter, the terminal interface is limited to a pre-configured color scheme
> which cannot be changed while the connection is active.
> It would be awfully nice if the color scheme of the terminal could be changed
> by the user without administrative access, and without requiring
> disconnect/reconnect.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GUACAMOLE-808) Support redirecting to originally requested URL after successful OpenID login
[
https://issues.apache.org/jira/browse/GUACAMOLE-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901334#comment-16901334
]
Michael Jumper commented on GUACAMOLE-808:
--
[~tanakakz] - assuming what you describe is not bad practice, the ability to
define multiple possible redirect URIs for the case that a single Guacamole
instance is actually being served via multiple domains is a different issue.
This issue deals only with the path within the application.
> Support redirecting to originally requested URL after successful OpenID login
> -
>
> Key: GUACAMOLE-808
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-808
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole, guacamole-auth-openid
>Affects Versions: 1.0.0
>Reporter: Parth Mishra
>Priority: Minor
>
> Upon successful authentication via OIDC, the user is returned to the redirect
> URI (e.g. {{https://myserver.com/guacamole/}}) even if they were requesting
> another Guacamole resource such as a Connection link. It would be nice if the
> user could be routed to the requested resource after successful
> authentication.
> This way, if they were to click a direct link to a guacamole Connection they
> have access too, the successful authentication via the IDP can reroute them
> directly to the requested connection URL rather than the guacamole UI.
> Typically this is done with encoding the request URL with the "state"
> parameter of OIDC and verifying with the nonce.
> This feature could be really useful for relying on custom frontends without
> having to modify or reimplement the web app.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GUACAMOLE-859) Incorrect Caps Lock keysym sent to Windows via RDP
[
https://issues.apache.org/jira/browse/GUACAMOLE-859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900442#comment-16900442
]
Michael Jumper commented on GUACAMOLE-859:
--
{quote}
Can you submit a pull request under issue GUACAMOLE-801? I still think this
likely a duplicate of that, so if you can do that, it would be great.
{quote}
I'm not entirely sure this is a duplicate. Since this issue is clean in scope
and explicit in what it fixes (compared to GUACAMOLE-801 which is a bit
nebulous), I suggest keeping this issue open and using it as the basis for the
PR. If it turns out that GUACAMOLE-801 is fixed by this, then we can close
GUACAMOLE-801 as such once it's merged.
> Incorrect Caps Lock keysym sent to Windows via RDP
> --
>
> Key: GUACAMOLE-859
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-859
> Project: Guacamole
> Issue Type: Bug
>Affects Versions: 1.0.0
> Environment: macOS Mojave
> Windows 10
>Reporter: Weston Thayer
>Priority: Minor
>
> 1. On a Mac, connect to a Windows machine via an RDP connection in Guacamole
> 2. On the Windows machine, open Chrome or Firefox and navigate to
> https://jsbin.com/reviciceke/2/edit?js,console,output
> 3. Click the "Run with JS" button
> 4. Click the output pane to make sure it has keyboard focus
> 5. Press the Caps Lock key on your Mac (you may need to press it twice if
> it's already on)
> Actual: The JSBin's console outputs KeyboardEvent.code and KeyboardEvent.key
> for the "keypress" event. Note how KeyboardEvent.code is an empty string and
> KeyboardEvent.key is "Unidentified"
> Expected: KeyboardEvent.code should be "CapsLock", as should KeyboardEvent.key
> I believe the keysym being sent by guacamole-common-js's Keyboard.js is
> 0xffe5. I'm guessing the guacd RDP plugin has a bug, where that keysym is not
> mapped to the correct RDP scancode(?).
> For reference, using Microsoft's RDP client for macOS, KeyboardEvent.code and
> key are correctly "CapsLock".
> Note that this bug probably went un-noticed for a long time because Caps Lock
> still "works" in that future characters typed are capitalized. But in my use
> case, I need Windows to handle the Caps Lock key down itself.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (GUACAMOLE-861) Drive Redirection: WINDOWS_TIME wrong calculation
[ https://issues.apache.org/jira/browse/GUACAMOLE-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-861: - Component/s: (was: guacd) RDP > Drive Redirection: WINDOWS_TIME wrong calculation > - > > Key: GUACAMOLE-861 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-861 > Project: Guacamole > Issue Type: Bug > Components: RDP >Affects Versions: 1.0.0 >Reporter: gabriel sztejnworcel >Priority: Minor > Fix For: 1.2.0 > > > There is a mistake in the conversion from UNIX time to FILETIME. See the > following page: > [https://support.microsoft.com/en-us/help/167296/how-to-convert-a-unix-time-t-to-a-win32-filetime-or-systemtime]. > With the current calculation, checking the properties of a file in a > redirected drive/folder gives invalid file dates. Changing the '-' to '+' > fixes the issue. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GUACAMOLE-623) Add support for attaching to Kubernetes pods
[ https://issues.apache.org/jira/browse/GUACAMOLE-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper resolved GUACAMOLE-623. -- Resolution: Done > Add support for attaching to Kubernetes pods > > > Key: GUACAMOLE-623 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-623 > Project: Guacamole > Issue Type: New Feature > Components: Documentation, guacamole, guacamole-ext, guacamole-server >Reporter: Michael Jumper >Assignee: Michael Jumper >Priority: Minor > Fix For: 1.1.0 > > > Currently, guacd can only access the terminals of containers in Kubernetes > pods if those containers host services that use the protocols guacd already > supports, such as an SSH daemon. This works, but is suboptimal: a container > should ideally be dedicated to one logical application. > Kubernetes provides a web service / API through which an application can > attach to the terminal of a container. Leveraging this API, support for > attaching to a container and accessing its terminal could be added to guacd, > functioning essentially identically to the way SSH and telnet support > currently works. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GUACAMOLE-623) Add support for attaching to Kubernetes pods
[ https://issues.apache.org/jira/browse/GUACAMOLE-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-623: - Component/s: guacamole-ext guacamole Documentation > Add support for attaching to Kubernetes pods > > > Key: GUACAMOLE-623 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-623 > Project: Guacamole > Issue Type: New Feature > Components: Documentation, guacamole, guacamole-ext, guacamole-server >Reporter: Michael Jumper >Assignee: Michael Jumper >Priority: Minor > Fix For: 1.1.0 > > > Currently, guacd can only access the terminals of containers in Kubernetes > pods if those containers host services that use the protocols guacd already > supports, such as an SSH daemon. This works, but is suboptimal: a container > should ideally be dedicated to one logical application. > Kubernetes provides a web service / API through which an application can > attach to the terminal of a container. Leveraging this API, support for > attaching to a container and accessing its terminal could be added to guacd, > functioning essentially identically to the way SSH and telnet support > currently works. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GUACAMOLE-860) Support for TN5250 terminal
[ https://issues.apache.org/jira/browse/GUACAMOLE-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-860: - Component/s: Terminal > Support for TN5250 terminal > --- > > Key: GUACAMOLE-860 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-860 > Project: Guacamole > Issue Type: New Feature > Components: Telnet, Terminal > Environment: IBM AS400 >Reporter: Alessandro Sironi >Priority: Minor > Labels: features > > In a scenario to give the possibility to work on IBM AS400 with all function > keys working properly, there is the need to have Emulator 5250, the "simple" > telnet could not support all the functions required to work properly on AS400 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (GUACAMOLE-858) Need pop up for userid and password for NLA RDP Sessions
[ https://issues.apache.org/jira/browse/GUACAMOLE-858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper closed GUACAMOLE-858. Resolution: Duplicate > Need pop up for userid and password for NLA RDP Sessions > > > Key: GUACAMOLE-858 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-858 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Affects Versions: 1.0.0 >Reporter: xuguilin >Priority: Major > > When RDC sessions with NLA are created the user must hard code user and > password each session. This is a major inconvenience when users have to > change their passwords because they have to go into each connection and > change it manually. > If the userid and password fail guacamole should present a pop-up like > Windows RDC that asks them to enter a userid, password and domain or accept > the domain\userid and password as does Windows RDC. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GUACAMOLE-574) Allow terminal input to be read from an inbound pipe stream
[
https://issues.apache.org/jira/browse/GUACAMOLE-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper resolved GUACAMOLE-574.
--
Resolution: Done
> Allow terminal input to be read from an inbound pipe stream
> ---
>
> Key: GUACAMOLE-574
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-574
> Project: Guacamole
> Issue Type: New Feature
> Components: Documentation, SSH, Telnet, Terminal
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>Priority: Major
> Fix For: 1.1.0
>
>
> Similar to how Guacamole's terminal emulator allows output to be temporarily
> redirected to a pipe stream, the terminal emulator should also accept the
> creation of an inbound pipe stream to serve as the source of user input.
> For this to work correctly:
> * The behavior of the inbound pipe stream would need to be predictable from
> the perspective of client-side JavaScript, presumably requiring a
> standardized name for the stream ("STDIN"?)
> * Handling of keyboard input while the pipe stream is redirected would need
> to be paused, to ensure that keyboard events cannot interfere with the
> interpretation of the stream by whatever is running within the SSH/telnet
> session.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GUACAMOLE-857) Add Docker Image Support for HTTP Header-Based Authentication
[
https://issues.apache.org/jira/browse/GUACAMOLE-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897739#comment-16897739
]
Michael Jumper commented on GUACAMOLE-857:
--
{quote}
Guacamole now has support for authenticating users via http header, but there
is no way to use this in the current Docker image.
{quote}
There is. You can use any extension with the Docker images, regardless of
whether the image bundles explicit support for that extension:
http://guacamole.apache.org/doc/gug/guacamole-docker.html#guacamole-docker-guacamole-home
{quote}
I propose adding an environment variable such as "HTTP_AUTH_HEADER" to the
Docker image which will enable http header authentication.
{quote}
Sure. Not a bad idea.
> Add Docker Image Support for HTTP Header-Based Authentication
> -
>
> Key: GUACAMOLE-857
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-857
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-auth-header, guacamole-docker
>Affects Versions: 1.0.0
>Reporter: Matt Grochowalski
>Priority: Minor
>
> Guacamole now has support for authenticating users via http header, but there
> is no way to use this in the current Docker image.
> I propose adding an environment variable such as "HTTP_AUTH_HEADER" to the
> Docker image which will enable http header authentication.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GUACAMOLE-623) Add support for attaching to Kubernetes pods
[
https://issues.apache.org/jira/browse/GUACAMOLE-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897617#comment-16897617
]
Michael Jumper commented on GUACAMOLE-623:
--
Besides adding the documentation for this, I also need to update the Kubernetes
support to make use of the {{argv}} instruction in the same way as SSH/telnet.
The same support present via GUACAMOLE-630 for SSH/telnet should be present
here.
> Add support for attaching to Kubernetes pods
>
>
> Key: GUACAMOLE-623
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-623
> Project: Guacamole
> Issue Type: New Feature
> Components: guacamole-server
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>Priority: Minor
> Fix For: 1.1.0
>
>
> Currently, guacd can only access the terminals of containers in Kubernetes
> pods if those containers host services that use the protocols guacd already
> supports, such as an SSH daemon. This works, but is suboptimal: a container
> should ideally be dedicated to one logical application.
> Kubernetes provides a web service / API through which an application can
> attach to the terminal of a container. Leveraging this API, support for
> attaching to a container and accessing its terminal could be added to guacd,
> functioning essentially identically to the way SSH and telnet support
> currently works.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (GUACAMOLE-649) Allow SSH locale to be explicitly set
[
https://issues.apache.org/jira/browse/GUACAMOLE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper resolved GUACAMOLE-649.
--
Resolution: Fixed
> Allow SSH locale to be explicitly set
> -
>
> Key: GUACAMOLE-649
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-649
> Project: Guacamole
> Issue Type: Improvement
> Components: Documentation, guacamole-ext, SSH
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>Priority: Trivial
> Fix For: 1.1.0
>
>
> Common SSH clients like Putty seems to automatically forward the user's
> locale settings during the connection process. The mechanism which allows
> this appears to be the standard POSIX {{LANG}} environment variable.
> Without providing some mechanism for specifying the locale, the language on
> the remote side may not match expectations, and the character set may be set
> to something which is not UTF-8, resulting in compatibility issues.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (GUACAMOLE-629) Stream protocol argument values
[ https://issues.apache.org/jira/browse/GUACAMOLE-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper resolved GUACAMOLE-629. -- Resolution: Done > Stream protocol argument values > --- > > Key: GUACAMOLE-629 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-629 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-common-js, libguac >Reporter: Michael Jumper >Assignee: Michael Jumper >Priority: Major > Fix For: 1.1.0 > > > The Guacamole protocol as designed currently imposes limitations on the > configuration of a connection: > # Connection configuration can be applied only during the initial protocol > handshake. If the user wishes to change aspects of the connection while the > connection is in progress, such as to alter the terminal appearance or > provide a username/password in response to a request from the remote desktop > server, this cannot be done. > # Connection parameters are inherently limited by the maximum length of an > instruction element and the overall maximum length of instructions. Providing > lengthy SSH keys for authentication, for example, is problematic > (GUACAMOLE-350). > With relatively minor changes to the Guacamole protocol, the above > limitations can be addressed. By sending connection parameters using > streaming instructions rather than as elements of a single, monolithic > "connect" instruction, parameter values can have unlimited length. By > extending the use of that parameter streaming instruction such that it can be > used both during a connection and during the handshake, protocol plugins can > choose to allow certain parameters to be set or updated while the connection > is in progress. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GUACAMOLE-29) Add support for requesting HTTP Basic Authentication
[
https://issues.apache.org/jira/browse/GUACAMOLE-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894161#comment-16894161
]
Michael Jumper commented on GUACAMOLE-29:
-
I'm definitely OK with closing this out as "Won't Do". Unless other members of
the community can speak to this as something that's needed, it still feels like
too much of a corner case to me.
If there does prove to be a community need, then we'll have to consider whether
there should be a means of adding headers to exceptions, or whether there
really should be some magic {{enable-http-basic-auth}} option.
> Add support for requesting HTTP Basic Authentication
>
>
> Key: GUACAMOLE-29
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-29
> Project: Guacamole
> Issue Type: Improvement
>Reporter: Michael Jumper
>Priority: Minor
>
> {panel:bgColor=#EE}
> *The description of this issue was copied from
> [GUAC-1489|https://glyptodon.org/jira/browse/GUAC-1489], an issue in the JIRA
> instance used by the Guacamole project prior to its acceptance into the
> Apache Incubator.*
> Comments, attachments, related issues, and history from prior to acceptance
> *have not been copied* and can be found instead at the original issue.
> {panel}
> Some reverse proxies support SSO via HTTP Basic authentication if the server
> requests it with 401 Unauthorized response.
> As Guacamole already reads Authorization header, it looks trivial to add
> guacamole.properties option such as "enable-http-basic-auth", to tell
> Guacamole to request HTTP Basic Authentication .
> PR on its way :)
> Thanks!
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GUACAMOLE-854) Debug level guacd logs spammed with "Handler not found for"
[
https://issues.apache.org/jira/browse/GUACAMOLE-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16891220#comment-16891220
]
Michael Jumper commented on GUACAMOLE-854:
--
I would say:
# Yes to {{TRACE}} level, and that should probably be part of GUACAMOLE-422.
# We should add an empty handler for {{nop}}, as it's a legit instruction.
# Those empty opcodes are handled by the Java side of the tunnel
implementation. There's something strange about this deployment if they are
being received by guacd. They are explicitly filtered:
https://github.com/apache/guacamole-client/blob/0484a4e485904625d924b796145ff341523677cd/guacamole-common/src/main/java/org/apache/guacamole/websocket/GuacamoleWebSocketTunnelEndpoint.java#L313-L334
> Debug level guacd logs spammed with "Handler not found for"
> ---
>
> Key: GUACAMOLE-854
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-854
> Project: Guacamole
> Issue Type: Bug
>Affects Versions: 1.1.0
> Environment: guacd: staging/1.1.0
> guacamole-common-js: staging/1.1.0
>Reporter: Richard Lancaster
>Priority: Minor
>
> When running guacd with DEBUG level logs, the logs are spammed with:
> {noformat}
> guacd[9]: DEBUG: Handler not found for "nop"
> guacd[9]: DEBUG: Handler not found for ""
> guacd[9]: DEBUG: Handler not found for ""
> guacd[9]: DEBUG: Handler not found for ""
> guacd[9]: DEBUG: Handler not found for ""
> guacd[9]: DEBUG: Handler not found for ""
> guacd[9]: DEBUG: Handler not found for "nop"
> guacd[9]: DEBUG: Handler not found for ""
> guacd[9]: DEBUG: Handler not found for ""
> guacd[9]: DEBUG: Handler not found for ""
> guacd[9]: DEBUG: Handler not found for ""
> guacd[9]: DEBUG: Handler not found for ""
> {noformat}
> I think the empty strings are caused by these instructions:
> `0.,4.ping,13.1563882935963`.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (GUACAMOLE-854) Debug level guacd logs spammed with "Handler not found for"
[
https://issues.apache.org/jira/browse/GUACAMOLE-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16891220#comment-16891220
]
Michael Jumper edited comment on GUACAMOLE-854 at 7/23/19 5:16 PM:
---
I would say:
# Yes to {{TRACE}} level, and that should probably be part of GUACAMOLE-422.
# We should add an empty handler for {{nop}}, as it's a legit instruction
(probably makes sense to be part of GUACAMOLE-422 there, too).
# Those empty opcodes are handled by the Java side of the tunnel
implementation. There's something strange about this deployment if they are
being received by guacd. They are explicitly filtered:
https://github.com/apache/guacamole-client/blob/0484a4e485904625d924b796145ff341523677cd/guacamole-common/src/main/java/org/apache/guacamole/websocket/GuacamoleWebSocketTunnelEndpoint.java#L313-L334
was (Author: mike.jumper):
I would say:
# Yes to {{TRACE}} level, and that should probably be part of GUACAMOLE-422.
# We should add an empty handler for {{nop}}, as it's a legit instruction.
# Those empty opcodes are handled by the Java side of the tunnel
implementation. There's something strange about this deployment if they are
being received by guacd. They are explicitly filtered:
https://github.com/apache/guacamole-client/blob/0484a4e485904625d924b796145ff341523677cd/guacamole-common/src/main/java/org/apache/guacamole/websocket/GuacamoleWebSocketTunnelEndpoint.java#L313-L334
> Debug level guacd logs spammed with "Handler not found for"
> ---
>
> Key: GUACAMOLE-854
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-854
> Project: Guacamole
> Issue Type: Bug
>Affects Versions: 1.1.0
> Environment: guacd: staging/1.1.0
> guacamole-common-js: staging/1.1.0
>Reporter: Richard Lancaster
>Priority: Minor
>
> When running guacd with DEBUG level logs, the logs are spammed with:
> {noformat}
> guacd[9]: DEBUG: Handler not found for "nop"
> guacd[9]: DEBUG: Handler not found for ""
> guacd[9]: DEBUG: Handler not found for ""
> guacd[9]: DEBUG: Handler not found for ""
> guacd[9]: DEBUG: Handler not found for ""
> guacd[9]: DEBUG: Handler not found for ""
> guacd[9]: DEBUG: Handler not found for "nop"
> guacd[9]: DEBUG: Handler not found for ""
> guacd[9]: DEBUG: Handler not found for ""
> guacd[9]: DEBUG: Handler not found for ""
> guacd[9]: DEBUG: Handler not found for ""
> guacd[9]: DEBUG: Handler not found for ""
> {noformat}
> I think the empty strings are caused by these instructions:
> `0.,4.ping,13.1563882935963`.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GUACAMOLE-853) Translation do not work correctly
[
https://issues.apache.org/jira/browse/GUACAMOLE-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890305#comment-16890305
]
Michael Jumper commented on GUACAMOLE-853:
--
{quote}
Why i have to create a branch for pull request?
{quote}
>From strictly our side, you don't have to and it makes no difference. Whether
>you use a topic branch has no bearing on review nor on where it gets merged.
On your side, it will make a major difference. It allows you to keep your
changes isolated. Using topic branches is a development best practice. You
don't technically have to, but you would be doing yourself a disservice if you
don't.
https://github.com/dchelimsky/rspec/wiki/Topic-Branches
{quote}
I played a little bit with the translatation files to understand how it work.
Is it possible, that not every area can be translated? For example i translated
the mask to create a new user. Over there is a section with the title "Account
Restrictions". I don't found the required field names in the en.json on my
server or in the latest master on Github.
{quote}
No. With the exception of a few error messages that remain untranslated,
absolutely all text within the web application is driven by translations. It is
possible for extensions to add their own sections/fields/components to the user
interface, in which case they provide their own translations. The "Account
Restrictions" section you refer to is actually defined by the database
authentication extensions, as is the translation for its title:
https://github.com/apache/guacamole-client/blob/20ad54c840ce7599bd1ef511c318e45849310eb0/extensions/guacamole-auth-jdbc/modules/guacamole-auth-jdbc-base/src/main/resources/translations/en.json#L100
> Translation do not work correctly
> -
>
> Key: GUACAMOLE-853
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-853
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole
>Affects Versions: 1.0.0
> Environment: Ubuntu 18.04.2 LTS (x64)
> Tomcat 8
> Guacamole 1.0.0
>Reporter: Whitemoon
>Priority: Minor
> Labels: Languages
> Attachments: guacamole-language-english.png,
> guacamole-language-german.png, guacamole-language-italiano.png
>
>
> We use Guacamole with Database Backend (MySQL). We are logged in with the
> default user (=admin) on the web interface. Some menu names (History or
> Grousps) are always in English. I changed the the display language under
> settings.
> The fields (ACTION_MANAGE_USER_GROUPS, ACTION_VIEW_HISTORY) are defined in
> each language file (for example: de.json or it.json).
> Restart of Tomcat and server brought nothing.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Closed] (GUACAMOLE-853) Translation do not work correctly
[ https://issues.apache.org/jira/browse/GUACAMOLE-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper closed GUACAMOLE-853. > Translation do not work correctly > - > > Key: GUACAMOLE-853 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-853 > Project: Guacamole > Issue Type: Bug > Components: guacamole >Affects Versions: 1.0.0 > Environment: Ubuntu 18.04.2 LTS (x64) > Tomcat 8 > Guacamole 1.0.0 >Reporter: Whitemoon >Priority: Minor > Labels: Languages > Attachments: guacamole-language-english.png, > guacamole-language-german.png, guacamole-language-italiano.png > > > We use Guacamole with Database Backend (MySQL). We are logged in with the > default user (=admin) on the web interface. Some menu names (History or > Grousps) are always in English. I changed the the display language under > settings. > The fields (ACTION_MANAGE_USER_GROUPS, ACTION_VIEW_HISTORY) are defined in > each language file (for example: de.json or it.json). > Restart of Tomcat and server brought nothing. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GUACAMOLE-853) Translation do not work correctly
[ https://issues.apache.org/jira/browse/GUACAMOLE-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper resolved GUACAMOLE-853. -- Resolution: Invalid > Translation do not work correctly > - > > Key: GUACAMOLE-853 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-853 > Project: Guacamole > Issue Type: Bug > Components: guacamole >Affects Versions: 1.0.0 > Environment: Ubuntu 18.04.2 LTS (x64) > Tomcat 8 > Guacamole 1.0.0 >Reporter: Whitemoon >Priority: Minor > Labels: Languages > Attachments: guacamole-language-english.png, > guacamole-language-german.png, guacamole-language-italiano.png > > > We use Guacamole with Database Backend (MySQL). We are logged in with the > default user (=admin) on the web interface. Some menu names (History or > Grousps) are always in English. I changed the the display language under > settings. > The fields (ACTION_MANAGE_USER_GROUPS, ACTION_VIEW_HISTORY) are defined in > each language file (for example: de.json or it.json). > Restart of Tomcat and server brought nothing. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GUACAMOLE-821) update translation ja.json for guacamole
[ https://issues.apache.org/jira/browse/GUACAMOLE-821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16889576#comment-16889576 ] Michael Jumper commented on GUACAMOLE-821: -- Reopening to additionally translate the name of the language option: https://github.com/apache/guacamole-client/pull/429 > update translation ja.json for guacamole > > > Key: GUACAMOLE-821 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-821 > Project: Guacamole > Issue Type: New Feature > Components: guacamole, guacamole-auth-cas, guacamole-auth-duo, > guacamole-auth-jdbc, guacamole-auth-jdbc-mysql, > guacamole-auth-jdbc-postgresql, guacamole-auth-jdbc-sqlserver, > guacamole-auth-openid, guacamole-auth-radius, guacamole-auth-totp, > guacamole-client >Reporter: chisato hasimoto >Priority: Minor > Fix For: 1.2.0 > > > See > https://github.com/apache/guacamole-client/pull/413 > 日本語対応の言語ファイル（ja.json）を新たに追加しました。 > また、日本語に切り替えができるよう各マニュフェストファイルに以下を追加しました。 > "translations/ja.json" -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GUACAMOLE-821) Add Japanese translation
[ https://issues.apache.org/jira/browse/GUACAMOLE-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-821: - Summary: Add Japanese translation (was: update translation ja.json for guacamole) > Add Japanese translation > > > Key: GUACAMOLE-821 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-821 > Project: Guacamole > Issue Type: New Feature > Components: guacamole, guacamole-auth-cas, guacamole-auth-duo, > guacamole-auth-jdbc, guacamole-auth-jdbc-mysql, > guacamole-auth-jdbc-postgresql, guacamole-auth-jdbc-sqlserver, > guacamole-auth-openid, guacamole-auth-radius, guacamole-auth-totp, > guacamole-client >Reporter: chisato hasimoto >Priority: Minor > Fix For: 1.2.0 > > > See > https://github.com/apache/guacamole-client/pull/413 > 日本語対応の言語ファイル（ja.json）を新たに追加しました。 > また、日本語に切り替えができるよう各マニュフェストファイルに以下を追加しました。 > "translations/ja.json" -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Reopened] (GUACAMOLE-821) update translation ja.json for guacamole
[ https://issues.apache.org/jira/browse/GUACAMOLE-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper reopened GUACAMOLE-821: -- > update translation ja.json for guacamole > > > Key: GUACAMOLE-821 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-821 > Project: Guacamole > Issue Type: New Feature > Components: guacamole, guacamole-auth-cas, guacamole-auth-duo, > guacamole-auth-jdbc, guacamole-auth-jdbc-mysql, > guacamole-auth-jdbc-postgresql, guacamole-auth-jdbc-sqlserver, > guacamole-auth-openid, guacamole-auth-radius, guacamole-auth-totp, > guacamole-client >Reporter: chisato hasimoto >Priority: Minor > Fix For: 1.2.0 > > > See > https://github.com/apache/guacamole-client/pull/413 > 日本語対応の言語ファイル（ja.json）を新たに追加しました。 > また、日本語に切り替えができるよう各マニュフェストファイルに以下を追加しました。 > "translations/ja.json" -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GUACAMOLE-847) Memory leak when using RDP with audio data
[ https://issues.apache.org/jira/browse/GUACAMOLE-847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper resolved GUACAMOLE-847. -- Resolution: Fixed Fix Version/s: 1.2.0 > Memory leak when using RDP with audio data > -- > > Key: GUACAMOLE-847 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-847 > Project: Guacamole > Issue Type: Bug > Components: guacd >Affects Versions: 1.0.0 >Reporter: Frank Riley >Priority: Major > Fix For: 1.2.0 > > Attachments: Capture.PNG, Capture2.PNG > > > I use guacamole to RDP to a windows box and monitor a camera in my home. When > I have the audio from the camera turned off, guacamole uses very little > memory. However, when I turn on audio, guacd is leaking memory very badly. I > monitor process memory usage with telegraf and grafana, and attached is the > grafana plot showing the guacd memory usage over two days. I only connect to > guacamole when I'm at work, and you can easily see when I connect to > guacamole when I arrive and when I disconnect before I leave. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GUACAMOLE-821) update translation ja.json for guacamole
[ https://issues.apache.org/jira/browse/GUACAMOLE-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper resolved GUACAMOLE-821. -- Resolution: Done Fix Version/s: 1.2.0 > update translation ja.json for guacamole > > > Key: GUACAMOLE-821 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-821 > Project: Guacamole > Issue Type: New Feature > Components: guacamole, guacamole-auth-cas, guacamole-auth-duo, > guacamole-auth-jdbc, guacamole-auth-jdbc-mysql, > guacamole-auth-jdbc-postgresql, guacamole-auth-jdbc-sqlserver, > guacamole-auth-openid, guacamole-auth-radius, guacamole-auth-totp, > guacamole-client >Reporter: chisato hasimoto >Priority: Minor > Fix For: 1.2.0 > > > See > https://github.com/apache/guacamole-client/pull/413 > 日本語対応の言語ファイル（ja.json）を新たに追加しました。 > また、日本語に切り替えができるよう各マニュフェストファイルに以下を追加しました。 > "translations/ja.json" -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GUACAMOLE-536) Add support for arbitrary LDAP bind patterns
[
https://issues.apache.org/jira/browse/GUACAMOLE-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper updated GUACAMOLE-536:
-
Summary: Add support for arbitrary LDAP bind patterns (was: Enhance
restrictive LDAP authentication configuration requirements)
> Add support for arbitrary LDAP bind patterns
>
>
> Key: GUACAMOLE-536
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-536
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-auth-ldap
>Reporter: Joseph L. Casale
>Priority: Minor
>
> The current LDAP authentication scheme can recursively search the base DN
> only when a bind DN is used. When biding with the user attempting to log on,
> the bind DN format pattern is not exposed through configuration which imposes
> unnatural restrictions forcing the user to exist in a single container.
> If the format pattern was exposed for configuration, for DSA's which allow
> flexible bind patterns such as Active Directory, configuration could allow
> "DOMAIN
> %s" or "%s...@domain.com" and for those DSA's which do not, you would simply
> configure the restrictive full DN as the pattern.
> The use case is that we use Active Directory anddo not allow bind accounts so
> the restriction prevents all users from accessing the application as our
> topology is not flat (we need to pick a single container therefor excluding
> everyone else).
> A working Java implementation of an LDAP auth scheme that facilitates this is
> [Gitblit|http://gitblit.com/properties.html], see the realm.ldap.*
> configuration properties. Setting the bind pattern to the UPN such as:
> {code:java}
> realm.ldap.bindpattern = ${username}@domain.com
> {code}
> allows the flexible configuration in our Active Directory environment.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GUACAMOLE-847) Memory leak when using RDP with audio data
[
https://issues.apache.org/jira/browse/GUACAMOLE-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888280#comment-16888280
]
Michael Jumper commented on GUACAMOLE-847:
--
{quote}
I monitor process memory usage with telegraf and grafana, and attached is the
grafana plot showing the guacd memory usage over two days. I only connect to
guacamole when I'm at work, and you can easily see when I connect to guacamole
when I arrive and when I disconnect before I leave.
{quote}
The graph is actually fairly unclear. There are several graph lines and no
legend indicating which line represents what:
!Screen Shot 2019-07-17 at 8.43.12 PM.png!
Are you saying the dark green line with the large sawtooth pattern is a guacd
process? What are the other lines? Do you perhaps have a screenshot that has a
legend?
> Memory leak when using RDP with audio data
> --
>
> Key: GUACAMOLE-847
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-847
> Project: Guacamole
> Issue Type: Bug
> Components: guacd
>Affects Versions: 1.0.0
>Reporter: Frank Riley
>Priority: Major
> Attachments: Screen Shot 2019-07-17 at 8.43.12 PM.png
>
>
> I use guacamole to RDP to a windows box and monitor a camera in my home. When
> I have the audio from the camera turned off, guacamole uses very little
> memory. However, when I turn on audio, guacd is leaking memory very badly. I
> monitor process memory usage with telegraf and grafana, and attached is the
> grafana plot showing the guacd memory usage over two days. I only connect to
> guacamole when I'm at work, and you can easily see when I connect to
> guacamole when I arrive and when I disconnect before I leave.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GUACAMOLE-844) RDP without username and password failed on Win 2016
[
https://issues.apache.org/jira/browse/GUACAMOLE-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886356#comment-16886356
]
Michael Jumper commented on GUACAMOLE-844:
--
Hi [~nico564122],
No, it's definitely a configuration issue and a matter of figuring out what's
wrong. RDP support within Guacamole isn't fundamentally broken. There are no
known versions of Windows which do not work with Guacamole, and in this case I
can confirm that Windows Server 2016 is specifically known to work. I have
several connections for Windows 2016 myself.
The mailing list is the proper place, and people should be able to help you
figure it out.
> RDP without username and password failed on Win 2016
>
>
> Key: GUACAMOLE-844
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-844
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole
>Affects Versions: 1.0.0
>Reporter: Nicolas CHARREL
>Priority: Minor
> Attachments: image-2019-07-16-17-04-14-631.png,
> image-2019-07-16-17-05-15-064.png
>
>
> Hello
> I want to allow my user to log on a windows server with their ids. So I have
> configured the connexion like that :
> !image-2019-07-16-17-04-14-631.png!
>
> !image-2019-07-16-17-05-15-064.png!
> All other fields are empty.
> So I expect to open a terminal server connexion and be on the windows logon
> screen. (I disabled NLA, and checked with mstsc client).
>
> But it seems Guacamole doesn't work. The only way I found to do it work: use
> a space password ?!
> With the same configuration but a space password I reach the server screen !
> Logs without password (doesn't work):
> {code:java}
> root@bastion:~# guacd -L trace -f
> guacd[2634]: INFO: Guacamole proxy daemon (guacd) version 1.0.0 started
> guacd[2634]: DEBUG: Unable to bind socket to host ::1, port 4822: Address
> family not supported by protocol
> guacd[2634]: DEBUG: Successfully bound socket to host 127.0.0.1, port 4822
> guacd[2634]: INFO: Listening on host 127.0.0.1, port 4822
> guacd[2634]: INFO: Creating new client for protocol "rdp"
> guacd[2634]: INFO: Connection ID is "$614a72e9-7d6a-4e61-998d-1c0bcb633e76"
> guacd[2634]: INFO: Creating new client for protocol "rdp"
> guacd[2634]: INFO: Connection ID is "$2d378536-7a5b-4eb5-998c-5225f80aa02d"
> guacd[2638]: WARNING: Guacamole handshake failed: Timed out
> guacd[2638]: DEBUG: Error reading "size": Timeout while waiting for data on
> socket
> guacd[2638]: INFO: Last user of connection
> "$614a72e9-7d6a-4e61-998d-1c0bcb633e76" disconnected
> guacd[2638]: DEBUG: Requesting termination of client...
> guacd[2638]: DEBUG: Client terminated successfully.
> guacd[2634]: INFO: Connection "$614a72e9-7d6a-4e61-998d-1c0bcb633e76" removed.
> guacd[2647]: WARNING: Guacamole handshake failed: Timed out
> guacd[2647]: DEBUG: Error reading "size": Timeout while waiting for data on
> socket
> guacd[2647]: INFO: Last user of connection
> "$2d378536-7a5b-4eb5-998c-5225f80aa02d" disconnected
> guacd[2647]: DEBUG: Requesting termination of client...
> guacd[2647]: DEBUG: Client terminated successfully.
> guacd[2634]: INFO: Connection "$2d378536-7a5b-4eb5-998c-5225f80aa02d"
> removed.{code}
> Logs with space password:
> {code:java}
> guacd[2657]: INFO: Guacamole proxy daemon (guacd) version 1.0.0 started
> guacd[2657]: DEBUG: Unable to bind socket to host ::1, port 4822: Address
> family not supported by protocol
> guacd[2657]: DEBUG: Successfully bound socket to host 127.0.0.1, port 4822
> guacd[2657]: INFO: Listening on host 127.0.0.1, port 4822
> guacd[2657]: INFO: Creating new client for protocol "rdp"
> guacd[2657]: INFO: Connection ID is "$2b264e1b-c1f5-4832-bbf6-094bd413886c"
> guacd[2661]: DEBUG: Parameter "console" omitted. Using default value of 0.
> guacd[2661]: DEBUG: Parameter "console-audio" omitted. Using default value of
> 0.
> guacd[2661]: INFO: Security mode: RDP
> guacd[2661]: DEBUG: User resolution is 1920x938 at 96 DPI
> guacd[2661]: DEBUG: Parameter "dpi" omitted. Using default value of 96.
> guacd[2661]: DEBUG: Using resolution of 1920x938 at 96 DPI
> guacd[2661]: DEBUG: Parameter "read-only" omitted. Using default value of 0.
> guacd[2661]: DEBUG: Parameter "client-name" omitted. Using default value of
> "Guacamole RDP".
> guacd[2661]: DEBUG: Parameter "enable-wallpaper" omitted. Using default value
> of 0.
> guacd[2661]: DEBUG: Parameter "enable-theming" omitted. Using default value
> of 0.
> guacd[2661]: DEBUG: Parameter "enable-font-smoothing" omitted. Using default
> value of 0.
> guacd[2661]: DEBUG: Parameter "enable-full-window-drag" omitted. Using
> default value of 0.
> guacd[2661]: DEBUG: Parameter "enable-desktop-composition" omitted. Using
> default value of 0.
> guacd[2661]: DEBUG: Parameter "enable-menu-animations" omitted. Using
[jira] [Updated] (GUACAMOLE-610) Allow scrollback buffer size to be configured
[
https://issues.apache.org/jira/browse/GUACAMOLE-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper updated GUACAMOLE-610:
-
Component/s: guacamole-ext
Documentation
> Allow scrollback buffer size to be configured
> -
>
> Key: GUACAMOLE-610
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-610
> Project: Guacamole
> Issue Type: Improvement
> Components: Documentation, guacamole-ext, SSH, Telnet
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>Priority: Minor
> Fix For: 1.1.0
>
>
> The scrollback buffer for both SSH and telnet is currently hard-coded to a
> static value which cannot be changed. This value should instead be a default,
> with the size of the scrollback buffer being modifiable via connection
> parameters or while the session is active (presumably via {{guacctl}}).
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (GUACAMOLE-798) Mouse support for ssh
[ https://issues.apache.org/jira/browse/GUACAMOLE-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-798: - Component/s: (was: guacamole) Telnet SSH > Mouse support for ssh > - > > Key: GUACAMOLE-798 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-798 > Project: Guacamole > Issue Type: Improvement > Components: SSH, Telnet >Reporter: Abolfazl Kazemi >Priority: Minor > > Mouse can be used in some of command-line applications such as htop. > It would be nice if we could use mouse for these kinds of applications inside > guacamole when connected to the remote node by ssh. > Thanks. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Comment Edited] (GUACAMOLE-547) Add support for the "none" SSH authentication method
[
https://issues.apache.org/jira/browse/GUACAMOLE-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881714#comment-16881714
]
Michael Jumper edited comment on GUACAMOLE-547 at 7/10/19 4:19 AM:
---
{quote}
... loop with a _Handler not found for "nop"_ message.
{quote}
This is unrelated to SSH and isn't a loop nor a bug. The "nop" message is sent
by the client to the server as a sort of keep-alive ping. Since the "nop"
instruction doesn't do anything by definition, the server doesn't actually
implement a handler for it. Recent changes from GUACAMOLE-422 added a
debug-level message to let us know if an instruction is not handled because it
has no handler, as that may indicate an incompatibility between client and
server that's worth noting, but in this case it's just benign noise.
was (Author: mike.jumper):
{quote}
... loop with a _Handler not found for "nop"_ message.
{quote}
This is unrelated to SSH and isn't a loop nor a bug. The "nop" message is sent
by the client to the server as a sort of keep-alive ping. Since the "nop"
instruction doesn't do anything by definition, the server doesn't actually
implement a handler for it. Recent changes from GUACAMOLE-422 added a
debug-level message to let us know if an instruction is not handled because it
has no handler, as that may indicate an incompatibility between client and
server that's worth noting, but this in this case it's just benign noise.
> Add support for the "none" SSH authentication method
>
>
> Key: GUACAMOLE-547
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-547
> Project: Guacamole
> Issue Type: New Feature
> Components: Documentation, SSH
> Environment: Linux 4.13.0-1012-azure #15-Ubuntu SMP Thu Mar 8
> 10:47:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: David Hauk
>Assignee: Michael Jumper
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: guacd-1.0.0.log, guacd-master.log, guacd_debug_fail.txt,
> openssh_verbose_successful connection.txt, sshd_config
>
>
> When connecting to embedded devices that implicitly allow SSH access guacd
> fails when the authentication method is (none). The devices permit any SSH
> user with no password access to the console, and then provide authentication
> internally via their interactive shell.
> Test cases:
> # no username and no password configured: Guacamole requests both, then
> fails to connect.
> # username but no password: Guacamole requests password, and then fails to
> connect.
> # username and password: Guacamole asks for no input, and then fails to
> connect.
> I've attached guacd debug logs from the failed connection attempts, plus
> OpenSSH (-vv) logs from a successful connection. (Files have been suitably
> redacted). The bit they share in common is they both state "Authentication
> (none)" but OpenSSH proceeds with the connection, while guacd terminates the
> connection:
> Guacd:
> {code:java}
> guacd[100079]: DEBUG: Successfully connected to host 192.168.233.20, port 22
> guacd[100079]: DEBUG: Supported authentication methods: (null)
> guacd[100066]: INFO: Connection "$abc52848-a11c-4397-a657-7c2d4bfdb5e9"
> removed.{code}
> OpenSSH:
> {code:java}
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentication succeeded (none).
> Authenticated to 192.168.233.20 ([192.168.233.20]:22).
> debug1: channel 0: new [client-session]
> debug2: channel 0: send open
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-547) Add support for the "none" SSH authentication method
[
https://issues.apache.org/jira/browse/GUACAMOLE-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881714#comment-16881714
]
Michael Jumper commented on GUACAMOLE-547:
--
{quote}
... loop with a _Handler not found for "nop"_ message.
{quote}
This is unrelated to SSH and isn't a loop nor a bug. The "nop" message is sent
by the client to the server as a sort of keep-alive ping. Since the "nop"
instruction doesn't do anything by definition, the server doesn't actually
implement a handler for it. Recent changes from GUACAMOLE-422 added a
debug-level message to let us know if an instruction is not handled because it
has no handler, as that may indicate an incompatibility between client and
server that's worth noting, but this in this case it's just benign noise.
> Add support for the "none" SSH authentication method
>
>
> Key: GUACAMOLE-547
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-547
> Project: Guacamole
> Issue Type: New Feature
> Components: Documentation, SSH
> Environment: Linux 4.13.0-1012-azure #15-Ubuntu SMP Thu Mar 8
> 10:47:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: David Hauk
>Assignee: Michael Jumper
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: guacd-1.0.0.log, guacd-master.log, guacd_debug_fail.txt,
> openssh_verbose_successful connection.txt, sshd_config
>
>
> When connecting to embedded devices that implicitly allow SSH access guacd
> fails when the authentication method is (none). The devices permit any SSH
> user with no password access to the console, and then provide authentication
> internally via their interactive shell.
> Test cases:
> # no username and no password configured: Guacamole requests both, then
> fails to connect.
> # username but no password: Guacamole requests password, and then fails to
> connect.
> # username and password: Guacamole asks for no input, and then fails to
> connect.
> I've attached guacd debug logs from the failed connection attempts, plus
> OpenSSH (-vv) logs from a successful connection. (Files have been suitably
> redacted). The bit they share in common is they both state "Authentication
> (none)" but OpenSSH proceeds with the connection, while guacd terminates the
> connection:
> Guacd:
> {code:java}
> guacd[100079]: DEBUG: Successfully connected to host 192.168.233.20, port 22
> guacd[100079]: DEBUG: Supported authentication methods: (null)
> guacd[100066]: INFO: Connection "$abc52848-a11c-4397-a657-7c2d4bfdb5e9"
> removed.{code}
> OpenSSH:
> {code:java}
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentication succeeded (none).
> Authenticated to 192.168.233.20 ([192.168.233.20]:22).
> debug1: channel 0: new [client-session]
> debug2: channel 0: send open
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (GUACAMOLE-547) Add support for the "none" SSH authentication method
[
https://issues.apache.org/jira/browse/GUACAMOLE-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper reopened GUACAMOLE-547:
--
Assignee: Michael Jumper (was: Nick Couchman)
I will try retesting with the provided sshd config.
> Add support for the "none" SSH authentication method
>
>
> Key: GUACAMOLE-547
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-547
> Project: Guacamole
> Issue Type: New Feature
> Components: Documentation, SSH
> Environment: Linux 4.13.0-1012-azure #15-Ubuntu SMP Thu Mar 8
> 10:47:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: David Hauk
>Assignee: Michael Jumper
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: guacd-1.0.0.log, guacd-master.log, guacd_debug_fail.txt,
> openssh_verbose_successful connection.txt, sshd_config
>
>
> When connecting to embedded devices that implicitly allow SSH access guacd
> fails when the authentication method is (none). The devices permit any SSH
> user with no password access to the console, and then provide authentication
> internally via their interactive shell.
> Test cases:
> # no username and no password configured: Guacamole requests both, then
> fails to connect.
> # username but no password: Guacamole requests password, and then fails to
> connect.
> # username and password: Guacamole asks for no input, and then fails to
> connect.
> I've attached guacd debug logs from the failed connection attempts, plus
> OpenSSH (-vv) logs from a successful connection. (Files have been suitably
> redacted). The bit they share in common is they both state "Authentication
> (none)" but OpenSSH proceeds with the connection, while guacd terminates the
> connection:
> Guacd:
> {code:java}
> guacd[100079]: DEBUG: Successfully connected to host 192.168.233.20, port 22
> guacd[100079]: DEBUG: Supported authentication methods: (null)
> guacd[100066]: INFO: Connection "$abc52848-a11c-4397-a657-7c2d4bfdb5e9"
> removed.{code}
> OpenSSH:
> {code:java}
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentication succeeded (none).
> Authenticated to 192.168.233.20 ([192.168.233.20]:22).
> debug1: channel 0: new [client-session]
> debug2: channel 0: send open
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-819) Documented Duo secret key length is incorrect
[
https://issues.apache.org/jira/browse/GUACAMOLE-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper updated GUACAMOLE-819:
-
Priority: Trivial (was: Minor)
> Documented Duo secret key length is incorrect
> -
>
> Key: GUACAMOLE-819
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-819
> Project: Guacamole
> Issue Type: Bug
> Components: Documentation
>Reporter: Stephen Jenkins
>Priority: Trivial
>
> The length of the Duo secret key is documented within the Guacamole manual as
> exactly 20 characters. This is incorrect. The _integration_ key is exactly 20
> characters, but the secret key is 40 characters.
> This can be seen in the definition and usage of the constants in [Duo's
> {{DuoWeb}}
> class|https://github.com/duosecurity/duo_java/blob/de98f6cece74a3097fb6018417084ea4d069dbf2/DuoWeb/src/main/java/com/duosecurity/duoweb/DuoWeb.java]:
> {code:java}
> public final class DuoWeb {
> ...
> private static final int IKEY_LEN = 20;
> private static final int SKEY_LEN = 40;
> private static final int AKEY_LEN = 40;
> ...
> public static String signRequest(final String ikey, final String
> skey, final String akey, final String username, final long time) {
> ...
> if (ikey.equals("") || ikey.length() != IKEY_LEN) {
> return ERR_IKEY;
> }
> if (skey.equals("") || skey.length() != SKEY_LEN) {
> return ERR_SKEY;
> }
> if (akey.equals("") || akey.length() < AKEY_LEN) {
> return ERR_AKEY;
> }
> ...
> {code}
> Note that the lengths of the various keys are not actually enforced by the
> guacamole-auth-duo extension, so while the manual is incorrect, the extension
> should still function as long as correct key values are provided.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-819) Documented Duo secret key length is incorrect
[
https://issues.apache.org/jira/browse/GUACAMOLE-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper updated GUACAMOLE-819:
-
Summary: Documented Duo secret key length is incorrect (was: DUO secret
key for Web SDK is now 40 characters, Guacamole instructions state must be 20
characters)
> Documented Duo secret key length is incorrect
> -
>
> Key: GUACAMOLE-819
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-819
> Project: Guacamole
> Issue Type: Bug
> Components: Documentation
>Reporter: Stephen Jenkins
>Priority: Minor
>
> The length of the Duo secret key is documented within the Guacamole manual as
> exactly 20 characters. This is incorrect. The _integration_ key is exactly 20
> characters, but the secret key is 40 characters.
> This can be seen in the definition and usage of the constants in [Duo's
> {{DuoWeb}}
> class|https://github.com/duosecurity/duo_java/blob/de98f6cece74a3097fb6018417084ea4d069dbf2/DuoWeb/src/main/java/com/duosecurity/duoweb/DuoWeb.java]:
> {code:java}
> public final class DuoWeb {
> ...
> private static final int IKEY_LEN = 20;
> private static final int SKEY_LEN = 40;
> private static final int AKEY_LEN = 40;
> ...
> public static String signRequest(final String ikey, final String
> skey, final String akey, final String username, final long time) {
> ...
> if (ikey.equals("") || ikey.length() != IKEY_LEN) {
> return ERR_IKEY;
> }
> if (skey.equals("") || skey.length() != SKEY_LEN) {
> return ERR_SKEY;
> }
> if (akey.equals("") || akey.length() < AKEY_LEN) {
> return ERR_AKEY;
> }
> ...
> {code}
> Note that the lengths of the various keys are not actually enforced by the
> guacamole-auth-duo extension, so while the manual is incorrect, the extension
> should still function as long as correct key values are provided.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-819) DUO secret key for Web SDK is now 40 characters, Guacamole instructions state must be 20 characters
[ https://issues.apache.org/jira/browse/GUACAMOLE-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-819: - Flags: (was: Important) > DUO secret key for Web SDK is now 40 characters, Guacamole instructions state > must be 20 characters > --- > > Key: GUACAMOLE-819 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-819 > Project: Guacamole > Issue Type: Bug > Components: Documentation >Reporter: Stephen Jenkins >Priority: Minor > > Been trying to integrate the DUO authentication into Guacamole following the > guacamole instructions and it was not working. Got the guac login screen, log > in and would not be prompted with a DUO authentication. > On closer inspection and double checking my config. I have spotted that > Guacamole in its instructions is stating the DUO secret key must be 20 > characters. The DUO provided key is now 40 characters. > Is guac coded to only work with 20 character as a limit in the secret key > field length. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-819) DUO secret key for Web SDK is now 40 characters, Guacamole instructions state must be 20 characters
[ https://issues.apache.org/jira/browse/GUACAMOLE-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-819: - Component/s: (was: guacamole-auth-duo) Documentation > DUO secret key for Web SDK is now 40 characters, Guacamole instructions state > must be 20 characters > --- > > Key: GUACAMOLE-819 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-819 > Project: Guacamole > Issue Type: Bug > Components: Documentation >Reporter: Stephen Jenkins >Priority: Minor > > Been trying to integrate the DUO authentication into Guacamole following the > guacamole instructions and it was not working. Got the guac login screen, log > in and would not be prompted with a DUO authentication. > On closer inspection and double checking my config. I have spotted that > Guacamole in its instructions is stating the DUO secret key must be 20 > characters. The DUO provided key is now 40 characters. > Is guac coded to only work with 20 character as a limit in the secret key > field length. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-834) okta client secret to be configured in guacamole
[ https://issues.apache.org/jira/browse/GUACAMOLE-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-834: - Fix Version/s: (was: 1.0.0) > okta client secret to be configured in guacamole > > > Key: GUACAMOLE-834 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-834 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-openid >Affects Versions: 1.0.0 > Environment: Ubuntu 16.06 (64 bit) >Reporter: Ram Prashath >Priority: Minor > > there is no option for client secret to be configured in guacamole. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-834) okta client secret to be configured in guacamole
[
https://issues.apache.org/jira/browse/GUACAMOLE-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876414#comment-16876414
]
Michael Jumper commented on GUACAMOLE-834:
--
Guacamole uses the "implicit flow" for its OpenID Connect support. The client
secret is not used in this case, as the secret would end up exposed. From
[https://www.oauth.com/oauth2-servers/single-page-apps/]:
{quote}
Single-page apps (or browser-based apps) run entirely in the browser after
loading the Javascript and HTML source code from a web page. Since the entire
source is available to the browser, they cannot maintain the confidentiality of
a client secret, so the secret is not used for these apps. ...
{quote}
I have never used Okta, but Okta's documentation lists this as supported:
https://developer.okta.com/docs/guides/implement-implicit/overview/
I suggest following the above. You shouldn't need a client secret unless you're
using an IDP that strictly does not support the implicit flow. In that case,
the path forward would be adding support for the OpenID "authorization code
flow". I don't believe that is the case here.
> okta client secret to be configured in guacamole
>
>
> Key: GUACAMOLE-834
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-834
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-auth-openid
>Affects Versions: 1.0.0
> Environment: Ubuntu 16.06 (64 bit)
>Reporter: Ram Prashath
>Priority: Minor
> Fix For: 1.0.0
>
>
> there is no option for client secret to be configured in guacamole.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GUACAMOLE-822) Balancing group links are missing client identifier
[
https://issues.apache.org/jira/browse/GUACAMOLE-822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper resolved GUACAMOLE-822.
--
Resolution: Fixed
Fix Version/s: 1.2.0
> Balancing group links are missing client identifier
> ---
>
> Key: GUACAMOLE-822
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-822
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole
>Affects Versions: 1.2.0
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>Priority: Major
> Fix For: 1.2.0
>
>
> Testing against the latest {{master}}, the URL of balancing groups for links
> within the Guacamole home page is {{#/client/}}, rather than
> {{#/client/IDENTIFIER}}. This appears to be a regression, with a build of
> 1.0.0 not producing this behavior, but I have not yet determined whether this
> is due to a 1.1.0 change or 1.2.0.
> To reproduce:
> # As an administrator, create a balancing group.
> # Navigate to the home page.
> # Hover the mouse over the newly-created balancing group. Note that the URL
> does not contain the client identifier.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-827) BlobWrite FileReader Busy State When Writing Data To VM
[ https://issues.apache.org/jira/browse/GUACAMOLE-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-827: - Priority: Trivial (was: Major) > BlobWrite FileReader Busy State When Writing Data To VM > --- > > Key: GUACAMOLE-827 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-827 > Project: Guacamole > Issue Type: Bug > Components: guacamole-common-js >Affects Versions: 1.0.0 > Environment: Google Chrome >Reporter: James Caple >Priority: Trivial > Labels: newbie, patch > > When creating a custom HTML/JS Guacamole client to write files to a VM using > the BlobWriter JS class, an error similar to the following is generated > (error is from running the code in Google Chrome): > > zone.js:1495 Uncaught (in promise) DOMException: Failed to execute > 'readAsArrayBuffer' on 'FileReader': The object is already busy reading Blobs. > at _global.. [as readAsArrayBuffer] > (https://redacted/polyfills.6e39da16eddfecb84434.js:3830:60) > at readNextChunk (https://redacted/main.51a4f7c78afe09ae8d5e.js:168269:20) > at > push../src/app/components/core/desktop/js/BlobWriter.js.redacted.ArrayBufferWriter.sendMoreChunks > [as onack] (https://redacted/main.51a4f7c78afe09ae8d5e.js:168295:17) > at > push../node_modules/guacamole-common-js/dist/guacamole-common.js.Guacamole.OutputStream.stream.onack > (https://redacted/main.51a4f7c78afe09ae8d5e.js:168396:25) > at ack (https://redacted/main.51a4f7c78afe09ae8d5e.js:114024:28) > at > push../node_modules/guacamole-common-js/dist/guacamole-common.js.Guacamole.HTTPTunnel.tunnel.oninstruction > (https://redacted/main.51a4f7c78afe09ae8d5e.js:114685:13) > at XMLHttpRequest.parseResponse [as > __zone_symbol__ON_PROPERTYreadystatechange] > (https://redacted/main.51a4f7c78afe09ae8d5e.js:123910:40) > at XMLHttpRequest.wrapFn > (https://redacted/polyfills.6e39da16eddfecb84434.js:3667:39) > at > ZoneDelegate.push../node_modules/zone.js/dist/zone.js.ZoneDelegate.invokeTask > (https://redacted/polyfills.6e39da16eddfecb84434.js:2758:31) > at Object.onInvokeTask > ([https://redacted/main.51a4f7c78afe09ae8d5e.js:33312:33)] > > While a file would ultimately get written to the remote VM, it is never a > complete file given the error above, which seems to be indicative of the > asynchronous nature of the file transfer activity and the contentious use of > the BlobWriter FileReader object. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-827) BlobWrite FileReader Busy State When Writing Data To VM
[ https://issues.apache.org/jira/browse/GUACAMOLE-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-827: - Component/s: (was: guacamole-client) guacamole-common-js > BlobWrite FileReader Busy State When Writing Data To VM > --- > > Key: GUACAMOLE-827 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-827 > Project: Guacamole > Issue Type: Bug > Components: guacamole-common-js >Affects Versions: 1.0.0 > Environment: Google Chrome >Reporter: James Caple >Priority: Major > Labels: newbie, patch > > When creating a custom HTML/JS Guacamole client to write files to a VM using > the BlobWriter JS class, an error similar to the following is generated > (error is from running the code in Google Chrome): > > zone.js:1495 Uncaught (in promise) DOMException: Failed to execute > 'readAsArrayBuffer' on 'FileReader': The object is already busy reading Blobs. > at _global.. [as readAsArrayBuffer] > (https://redacted/polyfills.6e39da16eddfecb84434.js:3830:60) > at readNextChunk (https://redacted/main.51a4f7c78afe09ae8d5e.js:168269:20) > at > push../src/app/components/core/desktop/js/BlobWriter.js.redacted.ArrayBufferWriter.sendMoreChunks > [as onack] (https://redacted/main.51a4f7c78afe09ae8d5e.js:168295:17) > at > push../node_modules/guacamole-common-js/dist/guacamole-common.js.Guacamole.OutputStream.stream.onack > (https://redacted/main.51a4f7c78afe09ae8d5e.js:168396:25) > at ack (https://redacted/main.51a4f7c78afe09ae8d5e.js:114024:28) > at > push../node_modules/guacamole-common-js/dist/guacamole-common.js.Guacamole.HTTPTunnel.tunnel.oninstruction > (https://redacted/main.51a4f7c78afe09ae8d5e.js:114685:13) > at XMLHttpRequest.parseResponse [as > __zone_symbol__ON_PROPERTYreadystatechange] > (https://redacted/main.51a4f7c78afe09ae8d5e.js:123910:40) > at XMLHttpRequest.wrapFn > (https://redacted/polyfills.6e39da16eddfecb84434.js:3667:39) > at > ZoneDelegate.push../node_modules/zone.js/dist/zone.js.ZoneDelegate.invokeTask > (https://redacted/polyfills.6e39da16eddfecb84434.js:2758:31) > at Object.onInvokeTask > ([https://redacted/main.51a4f7c78afe09ae8d5e.js:33312:33)] > > While a file would ultimately get written to the remote VM, it is never a > complete file given the error above, which seems to be indicative of the > asynchronous nature of the file transfer activity and the contentious use of > the BlobWriter FileReader object. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-827) BlobWrite FileReader Busy State When Writing Data To VM
[ https://issues.apache.org/jira/browse/GUACAMOLE-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-827: - Flags: (was: Patch,Important) Remaining Estimate: (was: 48h) Original Estimate: (was: 48h) > BlobWrite FileReader Busy State When Writing Data To VM > --- > > Key: GUACAMOLE-827 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-827 > Project: Guacamole > Issue Type: Bug > Components: guacamole-client >Affects Versions: 1.0.0 > Environment: Google Chrome >Reporter: James Caple >Priority: Major > Labels: newbie, patch > > When creating a custom HTML/JS Guacamole client to write files to a VM using > the BlobWriter JS class, an error similar to the following is generated > (error is from running the code in Google Chrome): > > zone.js:1495 Uncaught (in promise) DOMException: Failed to execute > 'readAsArrayBuffer' on 'FileReader': The object is already busy reading Blobs. > at _global.. [as readAsArrayBuffer] > (https://redacted/polyfills.6e39da16eddfecb84434.js:3830:60) > at readNextChunk (https://redacted/main.51a4f7c78afe09ae8d5e.js:168269:20) > at > push../src/app/components/core/desktop/js/BlobWriter.js.redacted.ArrayBufferWriter.sendMoreChunks > [as onack] (https://redacted/main.51a4f7c78afe09ae8d5e.js:168295:17) > at > push../node_modules/guacamole-common-js/dist/guacamole-common.js.Guacamole.OutputStream.stream.onack > (https://redacted/main.51a4f7c78afe09ae8d5e.js:168396:25) > at ack (https://redacted/main.51a4f7c78afe09ae8d5e.js:114024:28) > at > push../node_modules/guacamole-common-js/dist/guacamole-common.js.Guacamole.HTTPTunnel.tunnel.oninstruction > (https://redacted/main.51a4f7c78afe09ae8d5e.js:114685:13) > at XMLHttpRequest.parseResponse [as > __zone_symbol__ON_PROPERTYreadystatechange] > (https://redacted/main.51a4f7c78afe09ae8d5e.js:123910:40) > at XMLHttpRequest.wrapFn > (https://redacted/polyfills.6e39da16eddfecb84434.js:3667:39) > at > ZoneDelegate.push../node_modules/zone.js/dist/zone.js.ZoneDelegate.invokeTask > (https://redacted/polyfills.6e39da16eddfecb84434.js:2758:31) > at Object.onInvokeTask > ([https://redacted/main.51a4f7c78afe09ae8d5e.js:33312:33)] > > While a file would ultimately get written to the remote VM, it is never a > complete file given the error above, which seems to be indicative of the > asynchronous nature of the file transfer activity and the contentious use of > the BlobWriter FileReader object. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-827) BlobWrite FileReader Busy State When Writing Data To VM
[ https://issues.apache.org/jira/browse/GUACAMOLE-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-827: - Fix Version/s: (was: 1.2.0) (was: 1.1.0) > BlobWrite FileReader Busy State When Writing Data To VM > --- > > Key: GUACAMOLE-827 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-827 > Project: Guacamole > Issue Type: Bug > Components: guacamole-client >Affects Versions: 1.0.0 > Environment: Google Chrome >Reporter: James Caple >Priority: Major > Labels: newbie, patch > Original Estimate: 48h > Remaining Estimate: 48h > > When creating a custom HTML/JS Guacamole client to write files to a VM using > the BlobWriter JS class, an error similar to the following is generated > (error is from running the code in Google Chrome): > > zone.js:1495 Uncaught (in promise) DOMException: Failed to execute > 'readAsArrayBuffer' on 'FileReader': The object is already busy reading Blobs. > at _global.. [as readAsArrayBuffer] > (https://redacted/polyfills.6e39da16eddfecb84434.js:3830:60) > at readNextChunk (https://redacted/main.51a4f7c78afe09ae8d5e.js:168269:20) > at > push../src/app/components/core/desktop/js/BlobWriter.js.redacted.ArrayBufferWriter.sendMoreChunks > [as onack] (https://redacted/main.51a4f7c78afe09ae8d5e.js:168295:17) > at > push../node_modules/guacamole-common-js/dist/guacamole-common.js.Guacamole.OutputStream.stream.onack > (https://redacted/main.51a4f7c78afe09ae8d5e.js:168396:25) > at ack (https://redacted/main.51a4f7c78afe09ae8d5e.js:114024:28) > at > push../node_modules/guacamole-common-js/dist/guacamole-common.js.Guacamole.HTTPTunnel.tunnel.oninstruction > (https://redacted/main.51a4f7c78afe09ae8d5e.js:114685:13) > at XMLHttpRequest.parseResponse [as > __zone_symbol__ON_PROPERTYreadystatechange] > (https://redacted/main.51a4f7c78afe09ae8d5e.js:123910:40) > at XMLHttpRequest.wrapFn > (https://redacted/polyfills.6e39da16eddfecb84434.js:3667:39) > at > ZoneDelegate.push../node_modules/zone.js/dist/zone.js.ZoneDelegate.invokeTask > (https://redacted/polyfills.6e39da16eddfecb84434.js:2758:31) > at Object.onInvokeTask > ([https://redacted/main.51a4f7c78afe09ae8d5e.js:33312:33)] > > While a file would ultimately get written to the remote VM, it is never a > complete file given the error above, which seems to be indicative of the > asynchronous nature of the file transfer activity and the contentious use of > the BlobWriter FileReader object. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GUACAMOLE-826) Publish web-applications in Guacamole?
[ https://issues.apache.org/jira/browse/GUACAMOLE-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper closed GUACAMOLE-826. Resolution: Duplicate > Publish web-applications in Guacamole? > -- > > Key: GUACAMOLE-826 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-826 > Project: Guacamole > Issue Type: Wish >Reporter: Michael Boman >Priority: Minor > > I've been using Guacamole as a jump-server-solution where endpoints doesn't > have access directly to the servers but has to go though Guacamole first. > This works great for SSH and RDP/VNC-sessions but I'd love to be able to > publish websites though Guacamole, i.e. if the admin tool is a web > application I would like to publish it in Guacamole as well. Right now the > users has to go to a RDP-server and browse from there, and it has some > drawbacks not to talk about performance loss. > Would that be possible to implement such a feature? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-826) Publish web-applications in Guacamole?
[ https://issues.apache.org/jira/browse/GUACAMOLE-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872746#comment-16872746 ] Michael Jumper commented on GUACAMOLE-826: -- Possible, yes, but out of scope for the project. See GUACAMOLE-57. > Publish web-applications in Guacamole? > -- > > Key: GUACAMOLE-826 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-826 > Project: Guacamole > Issue Type: Wish >Reporter: Michael Boman >Priority: Minor > > I've been using Guacamole as a jump-server-solution where endpoints doesn't > have access directly to the servers but has to go though Guacamole first. > This works great for SSH and RDP/VNC-sessions but I'd love to be able to > publish websites though Guacamole, i.e. if the admin tool is a web > application I would like to publish it in Guacamole as well. Right now the > users has to go to a RDP-server and browse from there, and it has some > drawbacks not to talk about performance loss. > Would that be possible to implement such a feature? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-302) Refocus relevant in-progress login fields after auth failure
[ https://issues.apache.org/jira/browse/GUACAMOLE-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872496#comment-16872496 ] Michael Jumper commented on GUACAMOLE-302: -- Also, when the typical username/password login form initially appears, the username field doesn't always received focus. Whether focus is received by the username field seems random, though for me it almost always remains unfocused. The password field is consistently focused if an invalid username/password combination is provided, and the username field is consistently focused if a blank form is submitted, but focus on initial page load is inconsistent. > Refocus relevant in-progress login fields after auth failure > > > Key: GUACAMOLE-302 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-302 > Project: Guacamole > Issue Type: Improvement > Components: guacamole > Environment: Ubuntu Xenial >Reporter: Matt Prager >Priority: Minor > Fix For: 1.2.0 > > Attachments: guac-focus-angular-error-nonassign.png > > > After mistyping a Guacamole login password, the current behavior moves the > cursor out of the password box (I'm not sure where specifically it moves it - > there's no cursor on the screen anymore without clicking back into the > username or password box). As, on numerous occasions, I have immediately > retyped my password after seeing the "Invalid login" banner only to discover > that I then had to type it yet again because I had forgotten to first click > into the password box a second time, I think leaving the cursor in the > password box for immediate retyping of mistyped passwords would seem to make > sense. Thanks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (GUACAMOLE-302) Refocus relevant in-progress login fields after auth failure
[ https://issues.apache.org/jira/browse/GUACAMOLE-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper reopened GUACAMOLE-302: -- > Refocus relevant in-progress login fields after auth failure > > > Key: GUACAMOLE-302 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-302 > Project: Guacamole > Issue Type: Improvement > Components: guacamole > Environment: Ubuntu Xenial >Reporter: Matt Prager >Priority: Minor > Fix For: 1.2.0 > > > After mistyping a Guacamole login password, the current behavior moves the > cursor out of the password box (I'm not sure where specifically it moves it - > there's no cursor on the screen anymore without clicking back into the > username or password box). As, on numerous occasions, I have immediately > retyped my password after seeing the "Invalid login" banner only to discover > that I then had to type it yet again because I had forgotten to first click > into the password box a second time, I think leaving the cursor in the > password box for immediate retyping of mistyped passwords would seem to make > sense. Thanks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-550) Add autocomplete attributes to inputs
[ https://issues.apache.org/jira/browse/GUACAMOLE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872481#comment-16872481 ] Michael Jumper commented on GUACAMOLE-550: -- [~mkhan], I think you need to enable the "Verbose" log level to see the warning. Once that's done, the following appears in the dev tools console for any page with a password field, regardless of whether that field is involved with login or with connection configuration: !chrome-autocomplete-warning.png! For reference, the link in the warning resolves to: https://www.chromium.org/developers/design-documents/create-amazing-password-forms > Add autocomplete attributes to inputs > - > > Key: GUACAMOLE-550 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-550 > Project: Guacamole > Issue Type: New Feature >Reporter: Nick Couchman >Priority: Trivial > Attachments: chrome-autocomplete-warning.png > > > I see this suggestion show up in the Chrome Developer Tools window > periodically, and figured I'd create a JIRA issue for it. We should add > autocomplete to the various input fields to control whether or not we expect > the browsers to keep track of information for those fields, including storing > credentials within the browser's password save function if desired. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-550) Add autocomplete attributes to inputs
[ https://issues.apache.org/jira/browse/GUACAMOLE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-550: - Attachment: chrome-autocomplete-warning.png > Add autocomplete attributes to inputs > - > > Key: GUACAMOLE-550 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-550 > Project: Guacamole > Issue Type: New Feature >Reporter: Nick Couchman >Priority: Trivial > Attachments: chrome-autocomplete-warning.png > > > I see this suggestion show up in the Chrome Developer Tools window > periodically, and figured I'd create a JIRA issue for it. We should add > autocomplete to the various input fields to control whether or not we expect > the browsers to keep track of information for those fields, including storing > credentials within the browser's password save function if desired. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-380) Automatically select "text input" on mobile devices
[ https://issues.apache.org/jira/browse/GUACAMOLE-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-380: - Priority: Minor (was: Major) > Automatically select "text input" on mobile devices > --- > > Key: GUACAMOLE-380 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-380 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Reporter: Fx Chef >Priority: Minor > > Selecting an appropriate input method on mobile devices can be difficult, > particularly when the browser in use does not allow JavaScript to take > control of the swipe-from-the-left gesture that Guacamole uses to show the > menu. Ideally, a mechanism should be provided which allows the "text input" > method to be selected automatically, either by default or based on context. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-380) Automatically select "text input" on mobile devices
[ https://issues.apache.org/jira/browse/GUACAMOLE-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16871794#comment-16871794 ] Michael Jumper commented on GUACAMOLE-380: -- Relevant to this, I recently looked into alternative ways that "text input" might automatically show/hide based on context. While it's been asked on the mailing list whether it's possible to have this happen automatically when an input field is focused, and we've explained that, no, it's not possible for Guacamole to know that you've clicked in an input field within the remote desktop (as the remote desktop does not expose this information), I think we _may_ be able to determine this heuristically. It occurred to me that there is one indicator of context that remote desktops are fairly consistent with: the mouse cursor. If it were possible to identify when the mouse cursor changes to the typical "I" bar indicating text input, then the client side of Guacamole could use that as a hint to select a more appropriate input method on touch devices. I've had some success with a proof-of-concept JavaScript neural network that recognizes "I" bar cursors. It's an unexpected application of machine learning, to be sure, but it seems to work pretty darn well. > Automatically select "text input" on mobile devices > --- > > Key: GUACAMOLE-380 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-380 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Reporter: Fx Chef >Priority: Major > > Is this possible, or is there another way to do it? I can't seem to get the > guac menu to show when connecting to a desktop through an ipad. > thanks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-380) Automatically select "text input" on mobile devices
[
https://issues.apache.org/jira/browse/GUACAMOLE-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16871791#comment-16871791
]
Michael Jumper commented on GUACAMOLE-380:
--
{quote}
Is this possible, or is there another way to do it?
{quote}
You can set the default input method on a per-browser basis within the
"Preferences" tab of the settings screen. Once selected, that will be the
default within the browser from that point forward.
{quote}
I can't seem to get the guac menu to show when connecting to a desktop through
an ipad.
{quote}
Unfortunately, this is because iOS uses the swipe-from-the-left gesture to
navigate backward in the browser history, and this gesture takes priority over
JavaScript handling of the same. For Guacamole to see the gesture and open the
menu, you would need to:
* Open the connection in a new tab, such that there _is_ no history.
* Bookmark the application to the device's home screen. Doing this grants the
application greater control of what keyboard events can be captured, what
gestures can be overridden, etc. I believe this would allow Guacamole to take
full control of the relevant swipe gesture.
> Automatically select "text input" on mobile devices
> ---
>
> Key: GUACAMOLE-380
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-380
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole
>Reporter: Fx Chef
>Priority: Major
>
> Is this possible, or is there another way to do it? I can't seem to get the
> guac menu to show when connecting to a desktop through an ipad.
> thanks
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-380) Automatically select "text input" on mobile devices
[ https://issues.apache.org/jira/browse/GUACAMOLE-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-380: - Environment: (was: Linux desktop) > Automatically select "text input" on mobile devices > --- > > Key: GUACAMOLE-380 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-380 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Reporter: Fx Chef >Priority: Major > > Is this possible, or is there another way to do it? I can't seem to get the > guac menu to show when connecting to a desktop through an ipad. > thanks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-380) Automatically select "text input" on mobile devices
[ https://issues.apache.org/jira/browse/GUACAMOLE-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-380: - Summary: Automatically select "text input" on mobile devices (was: For mobile devices, Automatically select "text Input" on connect to desktop) > Automatically select "text input" on mobile devices > --- > > Key: GUACAMOLE-380 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-380 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-client > Environment: Linux desktop >Reporter: Fx Chef >Priority: Major > > Is this possible, or is there another way to do it? I can't seem to get the > guac menu to show when connecting to a desktop through an ipad. > thanks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-380) Automatically select "text input" on mobile devices
[ https://issues.apache.org/jira/browse/GUACAMOLE-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-380: - Component/s: (was: guacamole-client) guacamole > Automatically select "text input" on mobile devices > --- > > Key: GUACAMOLE-380 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-380 > Project: Guacamole > Issue Type: Improvement > Components: guacamole > Environment: Linux desktop >Reporter: Fx Chef >Priority: Major > > Is this possible, or is there another way to do it? I can't seem to get the > guac menu to show when connecting to a desktop through an ipad. > thanks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-731) When accessing the login page of Guacamole, Set the cursor focus on the username field
[ https://issues.apache.org/jira/browse/GUACAMOLE-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-731: - External issue URL: (was: https://a.stephaneboulet.com/guacamole/) > When accessing the login page of Guacamole, Set the cursor focus on the > username field > -- > > Key: GUACAMOLE-731 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-731 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Reporter: Stephane Boulet >Priority: Minor > Attachments: Guacamole.png, image-2019-05-02-14-47-01-565.png > > > Set the default focus / cursor on the Username Field when loading the login > page > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GUACAMOLE-731) When accessing the login page of Guacamole, Set the cursor focus on the username field
[ https://issues.apache.org/jira/browse/GUACAMOLE-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper closed GUACAMOLE-731. Resolution: Duplicate > When accessing the login page of Guacamole, Set the cursor focus on the > username field > -- > > Key: GUACAMOLE-731 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-731 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Reporter: Stephane Boulet >Priority: Minor > Attachments: Guacamole.png, image-2019-05-02-14-47-01-565.png > > > Set the default focus / cursor on the Username Field when loading the login > page > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-731) When accessing the login page of Guacamole, Set the cursor focus on the username field
[ https://issues.apache.org/jira/browse/GUACAMOLE-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16871709#comment-16871709 ] Michael Jumper commented on GUACAMOLE-731: -- Merging this into GUACAMOLE-302. > When accessing the login page of Guacamole, Set the cursor focus on the > username field > -- > > Key: GUACAMOLE-731 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-731 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Reporter: Stephane Boulet >Priority: Minor > Attachments: Guacamole.png, image-2019-05-02-14-47-01-565.png > > > Set the default focus / cursor on the Username Field when loading the login > page > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-302) Refocus relevant in-progress login fields after auth failure
[ https://issues.apache.org/jira/browse/GUACAMOLE-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-302: - Summary: Refocus relevant in-progress login fields after auth failure (was: Cursor placement for incorrect password) > Refocus relevant in-progress login fields after auth failure > > > Key: GUACAMOLE-302 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-302 > Project: Guacamole > Issue Type: Improvement > Components: guacamole > Environment: Ubuntu Xenial >Reporter: Matt Prager >Priority: Minor > > After mistyping a Guacamole login password, the current behavior moves the > cursor out of the password box (I'm not sure where specifically it moves it - > there's no cursor on the screen anymore without clicking back into the > username or password box). As, on numerous occasions, I have immediately > retyped my password after seeing the "Invalid login" banner only to discover > that I then had to type it yet again because I had forgotten to first click > into the password box a second time, I think leaving the cursor in the > password box for immediate retyping of mistyped passwords would seem to make > sense. Thanks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-820) Filters containing IP addresses do not match connection properties/parameters
[ https://issues.apache.org/jira/browse/GUACAMOLE-820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-820: - Summary: Filters containing IP addresses do not match connection properties/parameters (was: IP address filters do not match connection parameters) > Filters containing IP addresses do not match connection properties/parameters > - > > Key: GUACAMOLE-820 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-820 > Project: Guacamole > Issue Type: Bug > Components: guacamole-client >Affects Versions: 1.0.0 >Reporter: Nicolas CHARREL >Priority: Minor > Attachments: image-2019-06-19-17-11-43-136.png, > image-2019-06-19-17-12-53-087.png > > > Hello, > All my connections are named "HOSTNAME - IP". By example "GUAC - 127.0.0.1" > When I'm looking for this entry, I type in the filter 127.0.0.1 and I find > nothing. But when I type 127.0.0. I find my entry. > It's seems when I'm looking for a full IP there is a bug and the search > always return empty list. > First case (with 127.0.0), I find my connection: > !image-2019-06-19-17-11-43-136.png! > > Second case (with all the ip), there is no answer: > !image-2019-06-19-17-12-53-087.png! > Thanks for your help ! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-820) IP address filters do not match connection parameters
[ https://issues.apache.org/jira/browse/GUACAMOLE-820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16871555#comment-16871555 ] Michael Jumper commented on GUACAMOLE-820: -- Sure enough. The intent is there, but connection parameters are not searched, nor are the parameters generally exposed until explicitly retrieved when a specific connection is being edited. It may be that the IP address matching has only ever had an effect when searching the usage history. If we want to match against addresses in parameters, that needs to be corrected. If matching against parameter contents can't reasonably be allowed, filter behavior should be corrected such that searching for addresses behaves more intuitively, even when those addresses are substrings within a connection name. > IP address filters do not match connection parameters > - > > Key: GUACAMOLE-820 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-820 > Project: Guacamole > Issue Type: Bug > Components: guacamole-client >Affects Versions: 1.0.0 >Reporter: Nicolas CHARREL >Priority: Minor > Attachments: image-2019-06-19-17-11-43-136.png, > image-2019-06-19-17-12-53-087.png > > > Hello, > All my connections are named "HOSTNAME - IP". By example "GUAC - 127.0.0.1" > When I'm looking for this entry, I type in the filter 127.0.0.1 and I find > nothing. But when I type 127.0.0. I find my entry. > It's seems when I'm looking for a full IP there is a bug and the search > always return empty list. > First case (with 127.0.0), I find my connection: > !image-2019-06-19-17-11-43-136.png! > > Second case (with all the ip), there is no answer: > !image-2019-06-19-17-12-53-087.png! > Thanks for your help ! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-820) IP address filters do not match connection parameters
[ https://issues.apache.org/jira/browse/GUACAMOLE-820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-820: - Summary: IP address filters do not match connection parameters (was: connections and groups connection filter does not work correctly) > IP address filters do not match connection parameters > - > > Key: GUACAMOLE-820 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-820 > Project: Guacamole > Issue Type: Bug > Components: guacamole-client >Affects Versions: 1.0.0 >Reporter: Nicolas CHARREL >Priority: Minor > Attachments: image-2019-06-19-17-11-43-136.png, > image-2019-06-19-17-12-53-087.png > > > Hello, > All my connections are named "HOSTNAME - IP". By example "GUAC - 127.0.0.1" > When I'm looking for this entry, I type in the filter 127.0.0.1 and I find > nothing. But when I type 127.0.0. I find my entry. > It's seems when I'm looking for a full IP there is a bug and the search > always return empty list. > First case (with 127.0.0), I find my connection: > !image-2019-06-19-17-11-43-136.png! > > Second case (with all the ip), there is no answer: > !image-2019-06-19-17-12-53-087.png! > Thanks for your help ! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (GUACAMOLE-820) connections and groups connection filter does not work correctly
[ https://issues.apache.org/jira/browse/GUACAMOLE-820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper reopened GUACAMOLE-820: -- > connections and groups connection filter does not work correctly > > > Key: GUACAMOLE-820 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-820 > Project: Guacamole > Issue Type: Bug > Components: guacamole-client >Affects Versions: 1.0.0 >Reporter: Nicolas CHARREL >Priority: Minor > Attachments: image-2019-06-19-17-11-43-136.png, > image-2019-06-19-17-12-53-087.png > > > Hello, > All my connections are named "HOSTNAME - IP". By example "GUAC - 127.0.0.1" > When I'm looking for this entry, I type in the filter 127.0.0.1 and I find > nothing. But when I type 127.0.0. I find my entry. > It's seems when I'm looking for a full IP there is a bug and the search > always return empty list. > First case (with 127.0.0), I find my connection: > !image-2019-06-19-17-11-43-136.png! > > Second case (with all the ip), there is no answer: > !image-2019-06-19-17-12-53-087.png! > Thanks for your help ! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-825) Loading SSH private key from Active Directory LDAP fails
[
https://issues.apache.org/jira/browse/GUACAMOLE-825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16871549#comment-16871549
]
Michael Jumper commented on GUACAMOLE-825:
--
{quote}
{code:none}
guacd[1582]: ERROR: Auth key import failed: no start line
{code}
{quote}
Assuming that {{attribute: < URI}} syntax does pull the value of the LDAP
attribute from a file when the LDIF file is imported, you need to ensure that
the private key is indeed an SSH private key in OpenSSH format. The error you
are seeing is occurring because the private key is missing the {{--- BEGIN RSA
PRIVATE KEY ---}} (or similar) line. If you are sure the key is in the correct
format, the next thing to check would be whether the key was actually correctly
imported to LDAP through executing an LDAP query from the command line. You
should see the actual key present.
If after the above you're unable to figure out why your private key is not
working, please open a thread on the u...@guacamole.apache.org mailing list.
> Loading SSH private key from Active Directory LDAP fails
>
>
> Key: GUACAMOLE-825
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-825
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole
>Affects Versions: 1.0.0
> Environment: Docker connected to Active Directory 2019
>Reporter: Ian Reinhart Geiser
>Priority: Major
> Attachments: docker-compose.yml, guacamole.conf, guacamole.ldif
>
>
> I have imported an ldif file to my active directory for a SSH account.
> Password authentication works just fine, but no matter how I import it I
> cannot get the SSH private key to be loaded. It keeps asking me for a key
> passphrase, when in fact it should have none. When I press the enter key on
> the terminal i see the error below:
> {code:java}
> guacd[6]: INFO: Creating new client for protocol "ssh"
> guacd[6]: INFO: Connection ID is "$dfe3c6c8-7f5f-4e35-b48c-724d6bdbe135"
> guacd[1582]: INFO: User "@45ad52dc-8118-4a72-ac51-71ab0eedec18" joined
> connection "$dfe3c6c8-7f5f-4e35-b48c-724d6bdbe135" (1 users now present)
> guacd[1582]: ERROR: Auth key import failed: no start line
> guacd[1582]: INFO: User "@45ad52dc-8118-4a72-ac51-71ab0eedec18"
> disconnected (0 users remain)
> guacd[1582]: INFO: Last user of connection
> "$dfe3c6c8-7f5f-4e35-b48c-724d6bdbe135" disconnected
> guacd[6]: INFO: Connection "$dfe3c6c8-7f5f-4e35-b48c-724d6bdbe135" removed.
> {code}
> I have attached the ldif file, the docker compose, and the configuration
> file. I have confirmed that password interactive does work correctly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GUACAMOLE-723) Support display of multiple connections within same tab
[ https://issues.apache.org/jira/browse/GUACAMOLE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper resolved GUACAMOLE-723. -- Resolution: Done Each of the above issues is now resolved. > Support display of multiple connections within same tab > --- > > Key: GUACAMOLE-723 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-723 > Project: Guacamole > Issue Type: New Feature > Components: guacamole >Reporter: Michael Jumper >Assignee: Michael Jumper >Priority: Minor > Fix For: 1.2.0 > > > Currently, switching between connections within Guacamole requires going back > and forth between the current connection and the home screen. While multiple > connections may technically be open simultaneously, and thumbnails of those > connections update in real-time on the home screen, switching between > connections still requires navigation between two pages. > There should exist a convenient mechanism for: > * Displaying multiple active connections within the same tab for monitoring > and fast switching (iconified / thumbnailed connections ... like > picture-in-picture) > * Splitting the current tab vertically or horizontally such that multiple > active connections are equivalently visible (with keyboard focus following > mouse interaction) > * Quickly opening a new connection without going all the way back to the home > screen > Besides being convenient and powerful in itself, such an interface can form > the foundation of support for broadcasting input events across multiple > connections, as is commonly necessary when managing multiple servers via > several open terminals. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-103) SAML 2.0 support for user authentication
[
https://issues.apache.org/jira/browse/GUACAMOLE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870841#comment-16870841
]
Michael Jumper commented on GUACAMOLE-103:
--
{quote}
What I mean is that I'm under the impression there are issues with group
support unless you use the LDAP module (see #696). eg the openid and "http
header" auth module don't work that well (associating connection profiles with
groups don't work like it does for LDAP)
{quote}
No, there are no issues specifically with groups. LDAP and the database auth
are the only extensions that implement group support at the moment. The OpenID
and header extensions do not implement groups.
{quote}
Orgs that use SAML will not use LDAP, ...
{quote}
That's not necessarily true.
{quote}
... so I was assuming bits of code like that in the LDAP module would need
transplanting into a new SAML module
{quote}
No, code wouldn't need to be transplanted. The SAML module would need to
implement the part of the Guacamole extension API that allows extensions to
expose groups.
> SAML 2.0 support for user authentication
>
>
> Key: GUACAMOLE-103
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-103
> Project: Guacamole
> Issue Type: New Feature
>Reporter: Justin P
>Assignee: Nick Couchman
>Priority: Minor
>
> It'd be great if Guacamole supported SAML 2.0 so it could integrate with an
> organization's single sign-on (SSO) solution (especially popular platforms
> like OneLogin, Okta, Bitium, etc.)
> This would make authenticating to Guacamole easier for an organization's
> users, and it would make organization's IT/IS admins happier being able to
> apply authentication security controls to guacamole, such as password
> complexity rules, two-factor authentication rules, etc.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GUACAMOLE-824) Guacamole ignoring GUACAMOLE_HOME in Docker
[
https://issues.apache.org/jira/browse/GUACAMOLE-824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870745#comment-16870745
]
Michael Jumper edited comment on GUACAMOLE-824 at 6/24/19 2:08 AM:
---
{quote}
Can anyone see what I'm doing wrong here?
{quote}
Please don't open a bug report if you simply have a question about Guacamole.
Use the u...@guacamole.apache.org mailing list instead:
http://guacamole.apache.org/support/#mailing-lists
{quote}
It appears to be ignoring the GUACAMOLE_HOME variable.
{quote}
It isn't ignoring the variable; the Docker image simply has its own behavior
layered on top of that variable.
Setting {{GUACAMOLE_HOME}} on the Docker image tells the image what to use as
the template for {{GUACAMOLE_HOME}}. It does not have the same effect as
{{GUACAMOLE_HOME}} would under normal circumstances. The {{GUACAMOLE_HOME}}
used by Guacamole within the Docker image will always be {{/root/.guacamole}},
however the directory you specify via {{-e GUACAMOLE_HOME=/some/directory}}
will be copied over during startup to form the basis of the {{GUACAMOLE_HOME}}
that is ultimately used.
http://guacamole.apache.org/doc/gug/guacamole-docker.html#guacamole-docker-guacamole-home
was (Author: mike.jumper):
{quote}
Can anyone see what I'm doing wrong here?
{quote}
Please don't open a bug report if you simply have a question about Guacamole.
Use the u...@guacamole.apache.org mailing list instead:
http://guacamole.apache.org/support/#mailing-lists
{quote}
It appears to be ignoring the GUACAMOLE_HOME variable.
{quote}
It isn't ignoring the variable; the Docker image simply has its own behavior
layered on top of that variable.
Setting {{GUACAMOLE_HOME}} on the Docker image tells the image what to use as
the template for {{GUACAMOLE_HOME}}. It does not have the same effect as
{{GUACAMOLE_HOME}} would under normal circumstances. The {{GUACAMOLE_HOME}}
used by Guacamole within the Docker image will always be {{/root/.guacamole}},
however the directory you specify via {{-e GUACAMOLE_HOME=/some/directory}}
will be copied over during startup to form the basis of the {{GUACAMOLE_HOME}}
that ultimately used.
http://guacamole.apache.org/doc/gug/guacamole-docker.html#guacamole-docker-guacaamole-home
> Guacamole ignoring GUACAMOLE_HOME in Docker
> ---
>
> Key: GUACAMOLE-824
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-824
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-client
>Reporter: Chris Walker
>Priority: Major
>
> Hi,
> Can anyone see what I'm doing wrong here? It appears to be ignoring the
> GUACAMOLE_HOME variable.
> I have tried using both the version from Docker Hub and the one from Github.
> If I add the -e GUACD_HOSTNAME and -e GUACD_PORT, I no longer get the error,
> but the Docker logs show the home is "/root/.guacamole"
> {code:none}
> root@rdpext:~/guacamole-client/guacamole-client-master$ docker build
> --tag=guacamole-client-master .
> Sending build context to Docker daemon 17MB
> Step 1/13 : ARG TOMCAT_VERSION=8.5
> Step 2/13 : ARG TOMCAT_JRE=jre8
> Step 3/13 : FROM maven:3-jdk-8 AS builder
> ---> 23d9c051cfbe
> Step 4/13 : ARG BUILD_PROFILE
> ---> Using cache
> ---> 7f35aa577267
> Step 5/13 : ENV BUILD_DIR=/tmp/guacamole-docker-BUILD
> ---> Using cache
> ---> 565fcc2ce579
> Step 6/13 : COPY guacamole-docker/bin/ /opt/guacamole/bin/
> ---> Using cache
> ---> 44a94bd2530d
> Step 7/13 : COPY . "$BUILD_DIR"
> ---> Using cache
> ---> 0b7ced7e3535
> Step 8/13 : RUN /opt/guacamole/bin/build-guacamole.sh "$BUILD_DIR"
> /opt/guacamole "$BUILD_PROFILE"
> ---> Using cache
> ---> 1ffc8f73b54b
> Step 9/13 : FROM tomcat:${TOMCAT_VERSION}-${TOMCAT_JRE}
> ---> 3639174793ba
> Step 10/13 : WORKDIR /opt/guacamole
> ---> Using cache
> ---> e950afe8e728
> Step 11/13 : COPY --from=builder /opt/guacamole/ .
> ---> Using cache
> ---> 9071c3b297fb
> Step 12/13 : EXPOSE 8080
> ---> Using cache
> ---> 508dc0161724
> Step 13/13 : CMD ["/opt/guacamole/bin/start.sh" ]
> ---> Using cache
> ---> cfc265b66e10
> Successfully built cfc265b66e10
> Successfully tagged guacamole-client-master:latest
> root@rdpext:~/guacamole-client/guacamole-client-master$ docker images
> REPOSITORY TAG IMAGE ID CREATED
> SIZE
> guacamole-client-master latest cfc265b66e10 24 hours
> ago 501MB
> 1ffc8f73b54b 24 hours
> ago 826MB
> maven 3-jdk-8 23d9c051cfbe 12 days ago
> 499MB
> tomcat 8.5-jre8 3639174793ba 5 weeks ago
> 463MB
> guacamole/guacd latest 57f6ce568e0d 6 months
> ago 395MB
>
