mike-jumper commented on issue #455: GUACAMOLE-361: CAS global logout URL: https://github.com/apache/guacamole-client/pull/455#issuecomment-565554472 > > 1. It's not entirely clear to me how backend user configured values (present in `guacamole.properties`, for instance) are made available to the JS/Angular world. How do these `Field` classes behave exactly? In particular, I'm interested in mimicking the way the `authorizationURI` is passed down as a `$scope.field` value for the logout URL. What's the recommended way to go about this? > Custom fields are serialized to JSON using Jackson. Anything accessible via a getter on the `Field` subclass )and not annotated to be ignored) will be present in the REST response from the authentication service that lists the expected fields. https://github.com/apache/guacamole-client/blob/50b4becab3304cbe2905c23d6e4d64ca4c32d986/extensions/guacamole-auth-cas/src/main/java/org/apache/guacamole/auth/cas/form/CASTicketField.java#L87-L89 > > 2. Without #346, AFAIK, there's no current way to signal to extensions that a Guacamole logout has been successful. The CAS extension would need this for that very same purpose, before redirecting users to its own `/logout`. > On the server side, logout is signaled using {{invalidate()}} on the `UserContext`: http://guacamole.apache.org/doc/guacamole-ext/org/apache/guacamole/net/auth/UserContext.html#invalidate-- On the client side, logout is signaled using the `guacLogout` event. You might need to handle this on `$rootScope`: https://github.com/apache/guacamole-client/blob/4df22ce67bdafc028ed0042cd277b3de6264f7aa/guacamole/src/main/webapp/app/settings/services/preferenceService.js#L200-L203 > > 3. At present, when a user manually logs out, it [triggers a full view reload](https://github.com/apache/guacamole-client/blob/master/guacamole/src/main/webapp/app/navigation/directives/guacUserMenu.js#L148). That creates a problem when listening on broadcasted events (such as `guacLogout`) from different Angular modules, resulting in hard to track race conditions. The CAS logout flow could do without that kind of reloading: the user would need to head straight to `/logout` directly, instead. > The reload you describe is a critical aspect of the client side of the authentication process. It isn't exactly a reload so much as it is a means of forcing AngularJS to reprocess the route. The authentication process is driven by hooks into AngularJS' routing, so this causes the authentication service to reattempt authentication and render the login screen that results from processing the authentication failure. > > 4. The `.reload()` call mentioned above keeps query string parameters in the URL. For the CAS integration, those parameters include `ticket`, which holds a reference to a CAS session. After Guacamole deletes its own token, the reloading triggers an authentication loop where the user gets redirected to CAS -where the session is still valid- and immediately sent back to Guacamole. But since, the Guacamole session was invalidated, users can't continue using the application. > If the CAS session is still valid, then a new Guacamole session should then be created once the server side has validated the CAS token. What you describe is what would be expected if CAS is providing invalid tokens, or if an invalid CAS token is somehow still present. It wouldn't result from the Guacamole session being invalid, as it's the lack of a valid Guacamole session which drives CAS being pinged, and validation of the CAS token which results in a valid Guacamole session.
---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
