[jira] [Commented] (GUACAMOLE-715) Permission management based on LDAP groups not working as documented
[
https://issues.apache.org/jira/browse/GUACAMOLE-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751893#comment-16751893
]
Michael Jumper commented on GUACAMOLE-715:
--
This behavior is the result of code in {{JDBCAuthenticationProviderService}}
which was not updated to take groups into account:
https://github.com/apache/guacamole-client/blob/d1e928bea79ca81c827e9b6adedabc98eefdf701/extensions/guacamole-auth-jdbc/modules/guacamole-auth-jdbc-base/src/main/java/org/apache/guacamole/auth/jdbc/JDBCAuthenticationProviderService.java#L97-L138
The login process tests whether database data is applicable by querying based
on username alone. If no user account exists, the database isn't used for the
session. This needs to be updated such that things will work so long as
applicable groups exist, or perhaps to not depend on the user or group existing
at auth time.
> Permission management based on LDAP groups not working as documented
>
>
> Key: GUACAMOLE-715
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-715
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-auth-jdbc-mysql, guacamole-auth-ldap
>Affects Versions: 1.0.0
> Environment: I'm running guacamole in a docker environment using the
> official base images and a MySQL database. Users are authenticated against an
> Active Directory server in combination with the MySQL database.
>Reporter: Micha Kohl
>Priority: Major
>
> From the documentation on user groups in 1.0.0 I expected to be able to
> manage user permissions via LDAP groups like this (using LDAP for
> authentication and MySQL for configuration management as documented
> [here|https://guacamole.apache.org/doc/gug/ldap-auth.html#ldap-and-database]):
> # Create user group in MySQL with the name of a corresponding user group in
> the LDAP directory
> # Create connection in MySQL
> # Grant connection permission to the user group created in 1.
> # LDAP users that are part of the LDAP group (in the directory) are able to
> log in with their LDAP credentials and access that connection
> This does not work at all (the user does not even see the connection). In my
> attempt to narrow down the problem and ensure that I'm not just doing it
> wrong, I tested the following scenarios:
> # _Having just the LDAP group be mirrored in MySQL by creating an_
> _identically named one there_
> -> Login succeeds, but no associated connections are shown.
> # _Having both the LDAP group and the user be mirrored in MySQL by creating_
> _identically named entities there without manually linking the two (MySQL
> user is not part of MySQL user group)_
> -> Login succeeds and guacamole tries to auto-connect to the only available
> connection/shows all available connections and fails when trying to connect
> with a permission error.
> # _Having both the LDAP group and the user be mirrored in MySQL by creating_
> _identically named entities there and manually adding the MySQL user to the_
> _MySQL group_ _(MySQL user is part of MySQL user group)_
> -> Connections are established successfully.
> Either there seems to be a big misunderstanding regarding the way the new
> group system is supposed to work with LDAP, or there's something going wrong
> here. It goes without saying that scenario 3 completely eliminates the
> purpose of relying on existing LDAP groups. Scenario 1 is the configuration I
> outlined above that would allow managing connections based on LDAP groups
> without having to create any MySQL users whatsoever. Scenario 2 in
> combination with similar reports on the mailing list led me to believe that
> this is either based on a common misconception or there's a bug.
> Side-Note: While it has been suggested that this is already covered by
> GUACAMOLE-696, I think this could only be said if this turns out to be
> expected but poorly documented behavior.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-715) Permission management based on LDAP groups not working as documented
[ https://issues.apache.org/jira/browse/GUACAMOLE-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751891#comment-16751891 ] Michael Jumper commented on GUACAMOLE-715: -- This is indeed a bug and is not the same as GUACAMOLE-696. Group membership should work as described above, however when combining LDAP with a database the membership seems to only take proper effect if the user exists in both LDAP and the database. The following works: # User in both LDAP and database # Permission granted to group only in database # User added to group only in LDAP The following *doesn't* work: # User in LDAP only # Permission granted to group only in database # User added to group only in LDAP Something in the permission handling on the database side must still be assuming that a database user will exist. > Permission management based on LDAP groups not working as documented > > > Key: GUACAMOLE-715 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-715 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-jdbc-mysql, guacamole-auth-ldap >Affects Versions: 1.0.0 > Environment: I'm running guacamole in a docker environment using the > official base images and a MySQL database. Users are authenticated against an > Active Directory server in combination with the MySQL database. >Reporter: Micha Kohl >Priority: Major > > From the documentation on user groups in 1.0.0 I expected to be able to > manage user permissions via LDAP groups like this (using LDAP for > authentication and MySQL for configuration management as documented > [here|https://guacamole.apache.org/doc/gug/ldap-auth.html#ldap-and-database]): > # Create user group in MySQL with the name of a corresponding user group in > the LDAP directory > # Create connection in MySQL > # Grant connection permission to the user group created in 1. > # LDAP users that are part of the LDAP group (in the directory) are able to > log in with their LDAP credentials and access that connection > This does not work at all (the user does not even see the connection). In my > attempt to narrow down the problem and ensure that I'm not just doing it > wrong, I tested the following scenarios: > # _Having just the LDAP group be mirrored in MySQL by creating an_ > _identically named one there_ > -> Login succeeds, but no associated connections are shown. > # _Having both the LDAP group and the user be mirrored in MySQL by creating_ > _identically named entities there without manually linking the two (MySQL > user is not part of MySQL user group)_ > -> Login succeeds and guacamole tries to auto-connect to the only available > connection/shows all available connections and fails when trying to connect > with a permission error. > # _Having both the LDAP group and the user be mirrored in MySQL by creating_ > _identically named entities there and manually adding the MySQL user to the_ > _MySQL group_ _(MySQL user is part of MySQL user group)_ > -> Connections are established successfully. > Either there seems to be a big misunderstanding regarding the way the new > group system is supposed to work with LDAP, or there's something going wrong > here. It goes without saying that scenario 3 completely eliminates the > purpose of relying on existing LDAP groups. Scenario 1 is the configuration I > outlined above that would allow managing connections based on LDAP groups > without having to create any MySQL users whatsoever. Scenario 2 in > combination with similar reports on the mailing list led me to believe that > this is either based on a common misconception or there's a bug. > Side-Note: While it has been suggested that this is already covered by > GUACAMOLE-696, I think this could only be said if this turns out to be > expected but poorly documented behavior. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GUACAMOLE-693) Update copyright year to 2019
[
https://issues.apache.org/jira/browse/GUACAMOLE-693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman resolved GUACAMOLE-693.
-
Resolution: Done
> Update copyright year to 2019
> -
>
> Key: GUACAMOLE-693
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-693
> Project: Guacamole
> Issue Type: Task
> Components: Documentation, guacamole-client, guacamole-server,
> Website
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>Priority: Major
> Fix For: 1.1.0
>
>
> Happy New Year! At the beginning of each year, the copyright statements in
> the {{NOTICE}} files and website footer must be updated. They {{NOTICE}}
> files currently state:
> {quote}
> Apache Guacamole
> Copyright 2018 The Apache Software Foundation
> This product includes software developed at
> The Apache Software Foundation (http://www.apache.org/).
> {quote}
> The year needs to be updated to 2019. Similar changes must be made to the
> website footer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (GUACAMOLE-693) Update copyright year to 2019
[
https://issues.apache.org/jira/browse/GUACAMOLE-693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper reopened GUACAMOLE-693:
--
Assignee: Michael Jumper (was: Nick Couchman)
Still need to update guacamole-manual. I'll join the party and make a PR. ;)
> Update copyright year to 2019
> -
>
> Key: GUACAMOLE-693
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-693
> Project: Guacamole
> Issue Type: Task
> Components: Documentation, guacamole-client, guacamole-server,
> Website
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>Priority: Major
> Fix For: 1.1.0
>
>
> Happy New Year! At the beginning of each year, the copyright statements in
> the {{NOTICE}} files and website footer must be updated. They {{NOTICE}}
> files currently state:
> {quote}
> Apache Guacamole
> Copyright 2018 The Apache Software Foundation
> This product includes software developed at
> The Apache Software Foundation (http://www.apache.org/).
> {quote}
> The year needs to be updated to 2019. Similar changes must be made to the
> website footer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-693) Update copyright year to 2019
[
https://issues.apache.org/jira/browse/GUACAMOLE-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751758#comment-16751758
]
Nick Couchman commented on GUACAMOLE-693:
-
Aha. Maybe now we've got it?!
> Update copyright year to 2019
> -
>
> Key: GUACAMOLE-693
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-693
> Project: Guacamole
> Issue Type: Task
> Components: Documentation, guacamole-client, guacamole-server,
> Website
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>Priority: Major
> Fix For: 1.1.0
>
>
> Happy New Year! At the beginning of each year, the copyright statements in
> the {{NOTICE}} files and website footer must be updated. They {{NOTICE}}
> files currently state:
> {quote}
> Apache Guacamole
> Copyright 2018 The Apache Software Foundation
> This product includes software developed at
> The Apache Software Foundation (http://www.apache.org/).
> {quote}
> The year needs to be updated to 2019. Similar changes must be made to the
> website footer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GUACAMOLE-697) Connection Error when permissions assigned to user and to group user is in
[
https://issues.apache.org/jira/browse/GUACAMOLE-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman resolved GUACAMOLE-697.
-
Resolution: Fixed
PR merged, should be fixed in master and make it into the next release.
> Connection Error when permissions assigned to user and to group user is in
> --
>
> Key: GUACAMOLE-697
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-697
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-auth-jdbc
>Affects Versions: 1.0.0
>Reporter: matt nelson
>Assignee: Nick Couchman
>Priority: Critical
> Fix For: 1.1.0
>
>
> If you assign a user permissions to a connection and have the same permission
> assigned to a group that the user is a member of then they cannot connect.
> The error shown on the web client is this:
> {code:java}
> An internal error has occurred within the Guacamole server, and the
> connection has been terminated. If the problem persists, please notify your
> system administrator, or check your system logs.{code}
>
> The catalina log shows this:
>
> {code:java}
> SEVERE: Error reading request, ignored
> org.apache.ibatis.exceptions.TooManyResultsException: Expected one result (or
> null) to be returned by selectOne(), but found: 2
> at
> org.apache.ibatis.session.defaults.DefaultSqlSession.selectOne(DefaultSqlSession.java:81)
> at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.ibatis.session.SqlSessionManager$SqlSessionInterceptor.invoke(SqlSessionManager.java:357)
> at com.sun.proxy.$Proxy30.selectOne(Unknown Source)
> at
> org.apache.ibatis.session.SqlSessionManager.selectOne(SqlSessionManager.java:166)
> at
> org.apache.ibatis.binding.MapperMethod.execute(MapperMethod.java:83)
> at org.apache.ibatis.binding.MapperProxy.invoke(MapperProxy.java:59)
> at com.sun.proxy.$Proxy112.selectOne(Unknown Source)
> at
> org.apache.guacamole.auth.jdbc.permission.ModeledObjectPermissionService.hasPermission(ModeledObjectPermissionService.java:171)
> at
> org.apache.guacamole.auth.jdbc.permission.ObjectPermissionSet.hasPermission(ObjectPermissionSet.java:103)
> at
> org.apache.guacamole.auth.jdbc.base.ModeledDirectoryObjectService.hasObjectPermission(ModeledDirectoryObjectService.java:175)
> at
> org.apache.guacamole.auth.jdbc.connection.ConnectionService.connect(ConnectionService.java:514)
> at
> org.apache.guacamole.auth.jdbc.connection.ModeledConnection.connect(ModeledConnection.java:263)
> at
> org.apache.guacamole.tunnel.TunnelRequestService.createConnectedTunnel(TunnelRequestService.java:219)
> at
> org.apache.guacamole.tunnel.TunnelRequestService.createTunnel(TunnelRequestService.java:393)
> at
> org.apache.guacamole.tunnel.websocket.RestrictedGuacamoleWebSocketTunnelEndpoint.createTunnel(RestrictedGuacamoleWebSocketTunnelEndpoint.java:113)
> at
> org.apache.guacamole.websocket.GuacamoleWebSocketTunnelEndpoint.onOpen(GuacamoleWebSocketTunnelEndpoint.java:200)
> at
> org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.init(WsHttpUpgradeHandler.java:138)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:651)
> at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:748){code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GUACAMOLE-693) Update copyright year to 2019
[
https://issues.apache.org/jira/browse/GUACAMOLE-693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman resolved GUACAMOLE-693.
-
Resolution: Done
> Update copyright year to 2019
> -
>
> Key: GUACAMOLE-693
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-693
> Project: Guacamole
> Issue Type: Task
> Components: Documentation, guacamole-client, guacamole-server,
> Website
>Reporter: Michael Jumper
>Assignee: Nick Couchman
>Priority: Major
> Fix For: 1.1.0
>
>
> Happy New Year! At the beginning of each year, the copyright statements in
> the {{NOTICE}} files and website footer must be updated. They {{NOTICE}}
> files currently state:
> {quote}
> Apache Guacamole
> Copyright 2018 The Apache Software Foundation
> This product includes software developed at
> The Apache Software Foundation (http://www.apache.org/).
> {quote}
> The year needs to be updated to 2019. Similar changes must be made to the
> website footer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-693) Update copyright year to 2019
[
https://issues.apache.org/jira/browse/GUACAMOLE-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751749#comment-16751749
]
Nick Couchman commented on GUACAMOLE-693:
-
I think between [~omgar] and me we've covered everything, here? Going to close
it out - feel free to re-open if something else pops up.
> Update copyright year to 2019
> -
>
> Key: GUACAMOLE-693
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-693
> Project: Guacamole
> Issue Type: Task
> Components: Documentation, guacamole-client, guacamole-server,
> Website
>Reporter: Michael Jumper
>Assignee: Nick Couchman
>Priority: Major
> Fix For: 1.1.0
>
>
> Happy New Year! At the beginning of each year, the copyright statements in
> the {{NOTICE}} files and website footer must be updated. They {{NOTICE}}
> files currently state:
> {quote}
> Apache Guacamole
> Copyright 2018 The Apache Software Foundation
> This product includes software developed at
> The Apache Software Foundation (http://www.apache.org/).
> {quote}
> The year needs to be updated to 2019. Similar changes must be made to the
> website footer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=16751572#comment-16751572 ] Nick Couchman commented on GUACAMOLE-699: - [~leetxyz] Was looking at your commits in your fork of the repo, and have a couple of things you'll need to be aware of before you do a pull request: - Make sure that you tag your commits with the JIRA issue - so, for example "GUACAMOLE-699: Added missing keys and started merging old translations" (for your latest commit). - When you do the pull request it will similarly need to have the JIRA issue in the title. Looking forward to it - thank you for your efforts to translate the interface! > 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 (v7.6.3#76005)
[jira] [Created] (GUACAMOLE-716) Add all LDAP properties to Docker start script
Joel Best created GUACAMOLE-716: --- Summary: Add all LDAP properties to Docker start script Key: GUACAMOLE-716 URL: https://issues.apache.org/jira/browse/GUACAMOLE-716 Project: Guacamole Issue Type: Improvement Components: guacamole-docker Reporter: Joel Best There are still some LDAP properties that are not properly mapped in the start.sh script used for the Docker container: # ldap-group-name-attribute # ldap-dereference-aliases # ldap-max-referral-hops # ldap-operation-timeout # ldap-max-search-results I also noticed some of the set_optional_property calls are broken up over multiple lines but will be less than 80 columns if merged to one line. Finally, I plan to re-order the lines in the script to try to match the [LDAP authentication documentation|https://guacamole.apache.org/doc/gug/ldap-auth.html] as closely as possible. Pull request will be submitted shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-715) Permission management based on LDAP groups not working as documented
[ https://issues.apache.org/jira/browse/GUACAMOLE-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Micha Kohl updated GUACAMOLE-715: - Description: >From the documentation on user groups in 1.0.0 I expected to be able to manage >user permissions via LDAP groups like this (using LDAP for authentication and >MySQL for configuration management as documented >[here|https://guacamole.apache.org/doc/gug/ldap-auth.html#ldap-and-database]): # Create user group in MySQL with the name of a corresponding user group in the LDAP directory # Create connection in MySQL # Grant connection permission to the user group created in 1. # LDAP users that are part of the LDAP group (in the directory) are able to log in with their LDAP credentials and access that connection This does not work at all (the user does not even see the connection). In my attempt to narrow down the problem and ensure that I'm not just doing it wrong, I tested the following scenarios: # _Having just the LDAP group be mirrored in MySQL by creating an_ _identically named one there_ -> Login succeeds, but no associated connections are shown. # _Having both the LDAP group and the user be mirrored in MySQL by creating_ _identically named entities there without manually linking the two (MySQL user is not part of MySQL user group)_ -> Login succeeds and guacamole tries to auto-connect to the only available connection/shows all available connections and fails when trying to connect with a permission error. # _Having both the LDAP group and the user be mirrored in MySQL by creating_ _identically named entities there and manually adding the MySQL user to the_ _MySQL group_ _(MySQL user is part of MySQL user group)_ -> Connections are established successfully. Either there seems to be a big misunderstanding regarding the way the new group system is supposed to work with LDAP, or there's something going wrong here. It goes without saying that scenario 3 completely eliminates the purpose of relying on existing LDAP groups. Scenario 1 is the configuration I outlined above that would allow managing connections based on LDAP groups without having to create any MySQL users whatsoever. Scenario 2 in combination with similar reports on the mailing list led me to believe that this is either based on a common misconception or there's a bug. Side-Note: While it has been suggested that this is already covered by GUACAMOLE-696, I think this could only be said if this turns out to be expected but poorly documented behavior. was: >From the documentation on user groups in 1.0.0 I expected to be able to manage >user permissions via LDAP groups like this (using LDAP for authentication and >MySQL for configuration management as documented >[here|https://guacamole.apache.org/doc/gug/ldap-auth.html#ldap-and-database]): # Create user group in MySQL with the name of a corresponding user group in the LDAP directory # Create connection in MySQL # Grant connection permission to the user group created in 1. # LDAP users that are part of the LDAP group (in the directory) are able to log in with their LDAP credentials and access that connection This does not work at all (the user does not even see the connection). In my attempt to narrow down the problem and ensure that I'm not just doing it wrong, I tested the following scenarios: # _Having just the LDAP group be mirrored in MySQL by creating an_ _identically named one there_ -> Login succeeds, but no associated connections are shown. # _Having both the LDAP group and the user be mirrored in MySQL by creating_ _identically named entities there without manually linking the two (MySQL user is not part of MySQL user group)_ -> Login succeeds and guacamole tries to auto-connect to the only available connection/shows all available connections and fails when trying to connect with a permission error. # _Having both the LDAP group and the user be mirrored in MySQL by creating_ _identically named entities there and manually adding the MySQL user to the_ _MySQL group_ _(MySQL user is part of MySQL user group)_ -> Connections are established successfully. Either there seems to be a big misunderstanding regarding the way the new group system is supposed to work with LDAP, or there's something going wrong here. It goes without saying that scenario 3 completely eliminates the purpose of relying on existing LDAP groups. Scenario 1 is the configuration I outlined above that would allow managing connections based on LDAP groups without having to create any MySQL users whatsoever. Scenario 2 in combination with similar reports on the mailing list led me to believe that this is either based on a common misconception or there's a bug. Side-Note: While it has been suggested that this is already covered by GUACAMOLE-696, I think this could only be said if this turns out to be expected but poorly documente
[jira] [Updated] (GUACAMOLE-715) Permission management based on LDAP groups not working as documented
[ https://issues.apache.org/jira/browse/GUACAMOLE-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Micha Kohl updated GUACAMOLE-715: - Description: >From the documentation on user groups in 1.0.0 I expected to be able to manage >user permissions via LDAP groups like this (using LDAP for authentication and >MySQL for configuration management as documented >[here|https://guacamole.apache.org/doc/gug/ldap-auth.html#ldap-and-database]): # Create user group in MySQL with the name of a corresponding user group in the LDAP directory # Create connection in MySQL # Grant connection permission to the user group created in 1. # LDAP users that are part of the LDAP group (in the directory) are able to log in with their LDAP credentials and access that connection This does not work at all (the user does not even see the connection). In my attempt to narrow down the problem and ensure that I'm not just doing it wrong, I tested the following scenarios: # _Having just the LDAP group be mirrored in MySQL by creating an_ _identically named one there_ -> Login succeeds, but no associated connections are shown. # _Having both the LDAP group and the user be mirrored in MySQL by creating_ _identically named entities there without manually linking the two (MySQL user is not part of MySQL user group)_ -> Login succeeds and guacamole tries to auto-connect to the only available connection/shows all available connections and fails when trying to connect with a permission error. # _Having both the LDAP group and the user be mirrored in MySQL by creating_ _identically named entities there and manually adding the MySQL user to the_ _MySQL group_ _(MySQL user is part of MySQL user group)_ -> Connections are established successfully. Either there seems to be a big misunderstanding regarding the way the new group system is supposed to work with LDAP, or there's something going wrong here. It goes without saying that scenario 3 completely eliminates the purpose of relying on existing LDAP groups. Scenario 1 is the configuration I outlined above that would allow managing connections based on LDAP groups without having to create any MySQL users whatsoever. Scenario 2 in combination with similar reports on the mailing list led me to believe that this is either based on a common misconception or there's a bug. Side-Note: While it has been suggested that this is already covered by GUACAMOLE-696, I think this could only be said if this turns out to be expected but poorly documented behavior. was: >From the documentation on user groups in 1.0.0 I expected to be able to manage >user permissions via LDAP groups like this (using LDAP for authentication and >MySQL for configuration management as documented >[here|https://guacamole.apache.org/doc/gug/ldap-auth.html#ldap-and-database]): # Create user group in MySQL with the name of a corresponding user group in the LDAP directory # Create connection in MySQL # Grant connection permission to the user group created in 1. # LDAP users that are part of the LDAP group (in the directory) are able to log in with their LDAP credentials and access that connection This does not work at all (the user does not even see the connection). In my attempt to narrow down the problem and ensure that I'm not just doing it wrong, I tested the following scenarios: # _Having just the LDAP group be mirrored in MySQL by creating an_ _identically named one there_ -> Login succeeds, but no associated connections are shown. # _Having both the LDAP group and the user be mirrored in MySQL by creating_ _identically named entities there without manually linking the two (MySQL user is not part of MySQL user group)_ -> Login succeeds and guacamole tries to auto-connect to the only available connection/shows all available connections and fails when trying to connect with a permission error. # _Having both the LDAP group and the user be mirrored in MySQL by creating_ _identically named entities there and manually adding the MySQL user to the_ _MySQL group_ _(MySQL user is part of MySQL user group)_ -> Connections are established successfully. Either there seems to be a big misunderstanding regarding the way the new group system is supposed to work with LDAP, or there's something going wrong here. It goes without saying that scenario 3 completely eliminates the purpose of relying on existing LDAP groups. Scenario 1 is the configuration I outlined above that would allow managing connections based on LDAP groups without having to create any MySQL users whatsoever. Scenario 2 in combination with similar reports on the mailing list led me to believe that this is either based on a common misconception or there's a bug. Side-Note: While it has been suggested that this is already covered by GUACAMOLE-696, I think this could only be said if this turns out to be expected but poorly documented be
[jira] [Created] (GUACAMOLE-715) Permission management based on LDAP groups not working as documented
Micha Kohl created GUACAMOLE-715: Summary: Permission management based on LDAP groups not working as documented Key: GUACAMOLE-715 URL: https://issues.apache.org/jira/browse/GUACAMOLE-715 Project: Guacamole Issue Type: Bug Components: guacamole-auth-jdbc-mysql, guacamole-auth-ldap Affects Versions: 1.0.0 Environment: I'm running guacamole in a docker environment using the official base images and a MySQL database. Users are authenticated against an Active Directory server in combination with the MySQL database. Reporter: Micha Kohl >From the documentation on user groups in 1.0.0 I expected to be able to manage >user permissions via LDAP groups like this (using LDAP for authentication and >MySQL for configuration management as documented >[here|https://guacamole.apache.org/doc/gug/ldap-auth.html#ldap-and-database]): # Create user group in MySQL with the name of a corresponding user group in the LDAP directory # Create connection in MySQL # Grant connection permission to the user group created in 1. # LDAP users that are part of the LDAP group (in the directory) are able to log in with their LDAP credentials and access that connection This does not work at all (the user does not even see the connection). In my attempt to narrow down the problem and ensure that I'm not just doing it wrong, I tested the following scenarios: # _Having just the LDAP group be mirrored in MySQL by creating an_ _identically named one there_ -> Login succeeds, but no associated connections are shown. # _Having both the LDAP group and the user be mirrored in MySQL by creating_ _identically named entities there without manually linking the two (MySQL user is not part of MySQL user group)_ -> Login succeeds and guacamole tries to auto-connect to the only available connection/shows all available connections and fails when trying to connect with a permission error. # _Having both the LDAP group and the user be mirrored in MySQL by creating_ _identically named entities there and manually adding the MySQL user to the_ _MySQL group_ _(MySQL user is part of MySQL user group)_ -> Connections are established successfully. Either there seems to be a big misunderstanding regarding the way the new group system is supposed to work with LDAP, or there's something going wrong here. It goes without saying that scenario 3 completely eliminates the purpose of relying on existing LDAP groups. Scenario 1 is the configuration I outlined above that would allow managing connections based on LDAP groups without having to create any MySQL users whatsoever. Scenario 2 in combination with similar reports on the mailing list led me to believe that this is either based on a common misconception or there's a bug. Side-Note: While it has been suggested that this is already covered by GUACAMOLE-696, I think this could only be said if this turns out to be expected but poorly documented behavior. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-707) Missing/Broken RD Connection Broker Support in guacd 1.0.0 Docker based on debian:stable (freerdp suspect)
[
https://issues.apache.org/jira/browse/GUACAMOLE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751150#comment-16751150
]
Nick Couchman commented on GUACAMOLE-707:
-
[~lorengordon] Yes, one of the 1.2.0 branches/tags of FreeRDP supports the
feature correctly, and Guacamole will leverage it when the FreeRDP libraries
correctly implement it.
We can look at either compiling FreeRDP within the Docker image, or see if
there's a version of the package available in a repository that we could add to
the guacd image that would resolve this. [~mike.jumper] Any opinions?
> Missing/Broken RD Connection Broker Support in guacd 1.0.0 Docker based on
> debian:stable (freerdp suspect)
> --
>
> Key: GUACAMOLE-707
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-707
> Project: Guacamole
> Issue Type: Bug
> Components: guacd-docker
>Affects Versions: 1.0.0
>Reporter: Taylor Mulder
>Priority: Minor
>
> Confirmed today that connecting from Guacamole to a RD Connection Broker does
> _not_ work with the docker image for guacd:1.0.0 compiled under the
> `debian:stable` docker base.
> We have had zero issues with this capability under the 0.9.14 guacd docker
> image but noticed connectivity failures after updating to 1.0.0. After lots
> of troubleshooting I ended up reverting the
> [commit|https://github.com/apache/guacamole-server/commit/eb282e49d96c9398908147285744483c52447d1e]
> where guacd’s docker base image was changed from Ubuntu to Debian. I then
> built a docker image from the Ubuntu-based Dockerfile, and our connectivity
> issues have stopped. I strongly suspect that the freerdp version/build is
> somehow to blame, combined perhaps with some changes to how guacd 1.0.0 is
> handling redirects from the connection broker (adding this latter caveat
> since it worked under the 0.9.14 docker image, which was using an older
> version/build of the freerdp library).
> For context, this is being tested against a RD Connection Broker and RD
> Session Host nodes all running Windows 2016.
> Sample of our configuration:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I believe this is directly related to this
> ([GUACAMOLE-370|https://issues.apache.org/jira/browse/GUACAMOLE-370])
> previously closed issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-707) Missing/Broken RD Connection Broker Support in guacd 1.0.0 Docker based on debian:stable (freerdp suspect)
[
https://issues.apache.org/jira/browse/GUACAMOLE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman updated GUACAMOLE-707:
Fix Version/s: 1.1.0
> Missing/Broken RD Connection Broker Support in guacd 1.0.0 Docker based on
> debian:stable (freerdp suspect)
> --
>
> Key: GUACAMOLE-707
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-707
> Project: Guacamole
> Issue Type: Bug
> Components: guacd-docker
>Affects Versions: 1.0.0
>Reporter: Taylor Mulder
>Priority: Minor
> Fix For: 1.1.0
>
>
> Confirmed today that connecting from Guacamole to a RD Connection Broker does
> _not_ work with the docker image for guacd:1.0.0 compiled under the
> `debian:stable` docker base.
> We have had zero issues with this capability under the 0.9.14 guacd docker
> image but noticed connectivity failures after updating to 1.0.0. After lots
> of troubleshooting I ended up reverting the
> [commit|https://github.com/apache/guacamole-server/commit/eb282e49d96c9398908147285744483c52447d1e]
> where guacd’s docker base image was changed from Ubuntu to Debian. I then
> built a docker image from the Ubuntu-based Dockerfile, and our connectivity
> issues have stopped. I strongly suspect that the freerdp version/build is
> somehow to blame, combined perhaps with some changes to how guacd 1.0.0 is
> handling redirects from the connection broker (adding this latter caveat
> since it worked under the 0.9.14 docker image, which was using an older
> version/build of the freerdp library).
> For context, this is being tested against a RD Connection Broker and RD
> Session Host nodes all running Windows 2016.
> Sample of our configuration:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I believe this is directly related to this
> ([GUACAMOLE-370|https://issues.apache.org/jira/browse/GUACAMOLE-370])
> previously closed issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-707) Missing/Broken RD Connection Broker Support in guacd 1.0.0 Docker based on debian:stable (freerdp suspect)
[
https://issues.apache.org/jira/browse/GUACAMOLE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751127#comment-16751127
]
Loren Gordon commented on GUACAMOLE-707:
[~nick.couch...@yahoo.com], Is there a build/commit of FreeRDP that is *known*
to support this feature when used via guacd? While FreeRDP 1.2.0 was only ever
released as a beta, the same appears true of FreeRDP 1.1.0 (according to the
tags on the source code repo, anyway)...
So I guess where I'm going is would Guacamole be willing to compile FreeRDP in
the guacd Docker image, from a known-working patch-level? We could probably
test the Docker image, and _might_ be able to submit the PR, if someone can
provide pointers on how to compile FreeRDP reliably (I've tried in the past and
mostly failed).
> Missing/Broken RD Connection Broker Support in guacd 1.0.0 Docker based on
> debian:stable (freerdp suspect)
> --
>
> Key: GUACAMOLE-707
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-707
> Project: Guacamole
> Issue Type: Bug
> Components: guacd-docker
>Affects Versions: 1.0.0
>Reporter: Taylor Mulder
>Priority: Minor
>
> Confirmed today that connecting from Guacamole to a RD Connection Broker does
> _not_ work with the docker image for guacd:1.0.0 compiled under the
> `debian:stable` docker base.
> We have had zero issues with this capability under the 0.9.14 guacd docker
> image but noticed connectivity failures after updating to 1.0.0. After lots
> of troubleshooting I ended up reverting the
> [commit|https://github.com/apache/guacamole-server/commit/eb282e49d96c9398908147285744483c52447d1e]
> where guacd’s docker base image was changed from Ubuntu to Debian. I then
> built a docker image from the Ubuntu-based Dockerfile, and our connectivity
> issues have stopped. I strongly suspect that the freerdp version/build is
> somehow to blame, combined perhaps with some changes to how guacd 1.0.0 is
> handling redirects from the connection broker (adding this latter caveat
> since it worked under the 0.9.14 docker image, which was using an older
> version/build of the freerdp library).
> For context, this is being tested against a RD Connection Broker and RD
> Session Host nodes all running Windows 2016.
> Sample of our configuration:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I believe this is directly related to this
> ([GUACAMOLE-370|https://issues.apache.org/jira/browse/GUACAMOLE-370])
> previously closed issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-697) Connection Error when permissions assigned to user and to group user is in
[
https://issues.apache.org/jira/browse/GUACAMOLE-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751093#comment-16751093
]
Nick Couchman commented on GUACAMOLE-697:
-
PR submitted.
> Connection Error when permissions assigned to user and to group user is in
> --
>
> Key: GUACAMOLE-697
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-697
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-auth-jdbc
>Affects Versions: 1.0.0
>Reporter: matt nelson
>Assignee: Nick Couchman
>Priority: Major
> Fix For: 1.1.0
>
>
> If you assign a user permissions to a connection and have the same permission
> assigned to a group that the user is a member of then they cannot connect.
> The error shown on the web client is this:
> {code:java}
> An internal error has occurred within the Guacamole server, and the
> connection has been terminated. If the problem persists, please notify your
> system administrator, or check your system logs.{code}
>
> The catalina log shows this:
>
> {code:java}
> SEVERE: Error reading request, ignored
> org.apache.ibatis.exceptions.TooManyResultsException: Expected one result (or
> null) to be returned by selectOne(), but found: 2
> at
> org.apache.ibatis.session.defaults.DefaultSqlSession.selectOne(DefaultSqlSession.java:81)
> at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.ibatis.session.SqlSessionManager$SqlSessionInterceptor.invoke(SqlSessionManager.java:357)
> at com.sun.proxy.$Proxy30.selectOne(Unknown Source)
> at
> org.apache.ibatis.session.SqlSessionManager.selectOne(SqlSessionManager.java:166)
> at
> org.apache.ibatis.binding.MapperMethod.execute(MapperMethod.java:83)
> at org.apache.ibatis.binding.MapperProxy.invoke(MapperProxy.java:59)
> at com.sun.proxy.$Proxy112.selectOne(Unknown Source)
> at
> org.apache.guacamole.auth.jdbc.permission.ModeledObjectPermissionService.hasPermission(ModeledObjectPermissionService.java:171)
> at
> org.apache.guacamole.auth.jdbc.permission.ObjectPermissionSet.hasPermission(ObjectPermissionSet.java:103)
> at
> org.apache.guacamole.auth.jdbc.base.ModeledDirectoryObjectService.hasObjectPermission(ModeledDirectoryObjectService.java:175)
> at
> org.apache.guacamole.auth.jdbc.connection.ConnectionService.connect(ConnectionService.java:514)
> at
> org.apache.guacamole.auth.jdbc.connection.ModeledConnection.connect(ModeledConnection.java:263)
> at
> org.apache.guacamole.tunnel.TunnelRequestService.createConnectedTunnel(TunnelRequestService.java:219)
> at
> org.apache.guacamole.tunnel.TunnelRequestService.createTunnel(TunnelRequestService.java:393)
> at
> org.apache.guacamole.tunnel.websocket.RestrictedGuacamoleWebSocketTunnelEndpoint.createTunnel(RestrictedGuacamoleWebSocketTunnelEndpoint.java:113)
> at
> org.apache.guacamole.websocket.GuacamoleWebSocketTunnelEndpoint.onOpen(GuacamoleWebSocketTunnelEndpoint.java:200)
> at
> org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.init(WsHttpUpgradeHandler.java:138)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:651)
> at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:748){code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-697) Connection Error when permissions assigned to user and to group user is in
[
https://issues.apache.org/jira/browse/GUACAMOLE-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman updated GUACAMOLE-697:
Priority: Critical (was: Major)
> Connection Error when permissions assigned to user and to group user is in
> --
>
> Key: GUACAMOLE-697
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-697
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-auth-jdbc
>Affects Versions: 1.0.0
>Reporter: matt nelson
>Assignee: Nick Couchman
>Priority: Critical
> Fix For: 1.1.0
>
>
> If you assign a user permissions to a connection and have the same permission
> assigned to a group that the user is a member of then they cannot connect.
> The error shown on the web client is this:
> {code:java}
> An internal error has occurred within the Guacamole server, and the
> connection has been terminated. If the problem persists, please notify your
> system administrator, or check your system logs.{code}
>
> The catalina log shows this:
>
> {code:java}
> SEVERE: Error reading request, ignored
> org.apache.ibatis.exceptions.TooManyResultsException: Expected one result (or
> null) to be returned by selectOne(), but found: 2
> at
> org.apache.ibatis.session.defaults.DefaultSqlSession.selectOne(DefaultSqlSession.java:81)
> at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.ibatis.session.SqlSessionManager$SqlSessionInterceptor.invoke(SqlSessionManager.java:357)
> at com.sun.proxy.$Proxy30.selectOne(Unknown Source)
> at
> org.apache.ibatis.session.SqlSessionManager.selectOne(SqlSessionManager.java:166)
> at
> org.apache.ibatis.binding.MapperMethod.execute(MapperMethod.java:83)
> at org.apache.ibatis.binding.MapperProxy.invoke(MapperProxy.java:59)
> at com.sun.proxy.$Proxy112.selectOne(Unknown Source)
> at
> org.apache.guacamole.auth.jdbc.permission.ModeledObjectPermissionService.hasPermission(ModeledObjectPermissionService.java:171)
> at
> org.apache.guacamole.auth.jdbc.permission.ObjectPermissionSet.hasPermission(ObjectPermissionSet.java:103)
> at
> org.apache.guacamole.auth.jdbc.base.ModeledDirectoryObjectService.hasObjectPermission(ModeledDirectoryObjectService.java:175)
> at
> org.apache.guacamole.auth.jdbc.connection.ConnectionService.connect(ConnectionService.java:514)
> at
> org.apache.guacamole.auth.jdbc.connection.ModeledConnection.connect(ModeledConnection.java:263)
> at
> org.apache.guacamole.tunnel.TunnelRequestService.createConnectedTunnel(TunnelRequestService.java:219)
> at
> org.apache.guacamole.tunnel.TunnelRequestService.createTunnel(TunnelRequestService.java:393)
> at
> org.apache.guacamole.tunnel.websocket.RestrictedGuacamoleWebSocketTunnelEndpoint.createTunnel(RestrictedGuacamoleWebSocketTunnelEndpoint.java:113)
> at
> org.apache.guacamole.websocket.GuacamoleWebSocketTunnelEndpoint.onOpen(GuacamoleWebSocketTunnelEndpoint.java:200)
> at
> org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.init(WsHttpUpgradeHandler.java:138)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:651)
> at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:748){code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (GUACAMOLE-714) Add the option to append username to session recording file or path
[ https://issues.apache.org/jira/browse/GUACAMOLE-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman reopened GUACAMOLE-714: - > Add the option to append username to session recording file or path > --- > > Key: GUACAMOLE-714 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-714 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Reporter: Arash Nikoo >Priority: Minor > > It is really helpful if we can organize the session recording files as below: > /thepath/*CONNECTION_NAME*/*USERNAME* > Example: > /var/log/guacamole/myserver.domain.com/myuser/ssh.timing > or > /var/log/guacamole/myserver.domain.com/myuser-ssh.timing > > Currently, we can only set the recording path on the connection. If the > connection is shared between users it is hard to find out which session > recording belongs to which users. > > Thank you! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-714) Add Connection Name Parameter Token
[ https://issues.apache.org/jira/browse/GUACAMOLE-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16750963#comment-16750963 ] Nick Couchman commented on GUACAMOLE-714: - I'm not sure that a connection name token makes much sense, since you can just enter the connection name manually into the recording field at the time you configure the connection? Is there a reason why this would be of any value? > Add Connection Name Parameter Token > --- > > Key: GUACAMOLE-714 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-714 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Reporter: Arash Nikoo >Priority: Minor > > It is really helpful if we can organize the session recording files as below: > /thepath/*CONNECTION_NAME*/*USERNAME* > Example: > /var/log/guacamole/myserver.domain.com/myuser/ssh.timing > or > /var/log/guacamole/myserver.domain.com/myuser-ssh.timing > > Currently, we can only set the recording path on the connection. If the > connection is shared between users it is hard to find out which session > recording belongs to which users. > > Thank you! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GUACAMOLE-714) Add Connection Name Parameter Token
[ https://issues.apache.org/jira/browse/GUACAMOLE-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman closed GUACAMOLE-714. --- Resolution: Invalid > Add Connection Name Parameter Token > --- > > Key: GUACAMOLE-714 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-714 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Reporter: Arash Nikoo >Priority: Minor > > It is really helpful if we can organize the session recording files as below: > /thepath/*CONNECTION_NAME*/*USERNAME* > Example: > /var/log/guacamole/myserver.domain.com/myuser/ssh.timing > or > /var/log/guacamole/myserver.domain.com/myuser-ssh.timing > > Currently, we can only set the recording path on the connection. If the > connection is shared between users it is hard to find out which session > recording belongs to which users. > > Thank you! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-714) Add Connection Name Parameter Token
[ https://issues.apache.org/jira/browse/GUACAMOLE-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-714: Summary: Add Connection Name Parameter Token (was: Add the option to append username to session recording file or path) > Add Connection Name Parameter Token > --- > > Key: GUACAMOLE-714 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-714 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Reporter: Arash Nikoo >Priority: Minor > > It is really helpful if we can organize the session recording files as below: > /thepath/*CONNECTION_NAME*/*USERNAME* > Example: > /var/log/guacamole/myserver.domain.com/myuser/ssh.timing > or > /var/log/guacamole/myserver.domain.com/myuser-ssh.timing > > Currently, we can only set the recording path on the connection. If the > connection is shared between users it is hard to find out which session > recording belongs to which users. > > Thank you! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
