necouchman commented on code in PR #931:
URL: https://github.com/apache/guacamole-client/pull/931#discussion_r1394541107


##########
guacamole/src/main/java/org/apache/guacamole/tunnel/StandardTokenMap.java:
##########
@@ -102,6 +115,13 @@ public StandardTokenMap(AuthenticatedUser 
authenticatedUser) {
         else
             put(USERNAME_TOKEN, authenticatedUser.getIdentifier());
 
+        if (get(USERNAME_TOKEN).contains("\\")) {
+            put(USERNAME_DOMAIN_TOKEN, get(USERNAME_TOKEN).split("\\\\")[0]);
+            put(USERNAME_ID_TOKEN, get(USERNAME_TOKEN).split("\\\\")[1]);
+        } else {
+            put(USERNAME_DOMAIN_TOKEN, "");
+            put(USERNAME_ID_TOKEN, get(USERNAME_TOKEN));
+        }

Review Comment:
   > If there is to be a new standard token, I think there's some value in 
having one token (GUAC_IDENTIFIER? GUAC_USER_IDENTIFIER?) that represents 
validated identity while the other (GUAC_USERNAME) represents the username 
provided during the auth process, if any.
   
   Sure, that makes sense - it doesn't resolve the issue of getting the domain 
portion out of the overall username, so if there's a need to have the domain, 
that would still have to be handled - which seems more appropriate to be 
LDAP-specific.
   
   > I think that much is already possible with the functionality provided by 
the ldap-user-attributes property.
   
   Yeah, I was looking at that code, but also did a quick search of my local AD 
environment and figured out that the domain is not (obviously) present in any 
attribute without splitting it out of another attribute. So, again, if the 
domain portion is desired/required, it would need to be something LDAP-specific.
   
   If the desire is just to get the Guacamole identifier, I'm good with the 
`GUAC_IDENTIFIER` route.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@guacamole.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to