Re: Console ID Cache issue when using user-mapping.xml
On Fri, Oct 21, 2016 at 2:56 AM, Rishi <2rushike...@gmail.com> wrote: > Hi Mike, > > I did wrote a separate authentication module inspired from noauth however > the problem still persists. > It is the cookie that connects to original console and not new one. If I > remove cookie and try for new console, it works fine. > > Authentication/session state is tied to the authentication token, which is stored in memory and, yes, within a cookie by JavaScript. The cookie is not used in the traditional sense, and is ignored by the server. The part of HTTP requests which the web application uses to tie a request to a session is the "token" parameter. Any ideas how can I force flush cookie and let it go through authentication > module ? > > First, to clarify, I think it's important to avoid fixating on the cookie. While it is part of the issue you're encountering, it is not actually the cause. Both the built-in extension which uses user-mapping.xml and the NoAuth extension cache the connections available to a user, so if you're basing your authentication extension on NoAuth, there is a good chance you inherited that behavior. The caching is internal to SimpleAuthenticationProvider. If you implement AuthenticationProvider directly, rather than using the SimpleAuthenticationProvider class, the level of caching (if any) can be dictated by your implementation. Beyond that, if you find yourself fighting the authentication/extension subsystem, you might want to look into integrating the core of Guacamole rather than the entire web application. The authentication system is specific to the web application we wrote around our own APIs, and those APIs are intentionally kept independent. If you integrate the remote desktop functionality of Guacamole using those APIs, then you can dictate how connections are established entirely yourself: http://guacamole.incubator.apache.org/doc/gug/writing-you-own-guacamole-app.html - Mike
Re: Console ID Cache issue when using user-mapping.xml
Hi Mike, I did wrote a separate authentication module inspired from noauth however the problem still persists. It is the cookie that connects to original console and not new one. If I remove cookie and try for new console, it works fine. Any ideas how can I force flush cookie and let it go through authentication module ? Regards, Rishi On Tue, Oct 18, 2016 at 1:55 PM, Rishi <2rushike...@gmail.com> wrote: > Thanks Mike for detailed information and saving hours in pursuing wrong > path. > > I'd definitely look into custom auth and build something for us. > I'm simply looking for a web callback as authentication mechanism. Let me > know if its already present while I proceed to develop one. And in case I'm > getting it working, can I contribute it back ? > > - Rishi > > On Tue, Oct 18, 2016 at 3:54 AM, Mike Jumper > wrote: > >> On Tue, Oct 11, 2016 at 3:41 AM, Rishi <2rushike...@gmail.com> wrote: >> >>> Hello All, >>> >>> >> Hello Rishi, >> >> >>> I'm using guacamole in an automated fashion such that after completing >>> the external authentication, a new user-mapping.xml is generated. >>> >> >> The intended mechanism for integrating Guacamole with external >> authentication is not through auto-generating XML, but rather through >> extensions: >> >> http://guacamole.incubator.apache.org/doc/gug/guacamole-ext.html >> >> http://guacamole.incubator.apache.org/doc/gug/custom-auth.html >> >> More on this below. >> >> The guacamole authentication in this case works correct however websocket >>> connection for console happens to the last consoled vm. It is not able to >>> properly disconnect last websocket session upon generation of new >>> user-mapping.xml. I suspect its the cookies ! >>> >>> >> Guacamole doesn't use cookies in this way, but the authentication >> mechanism that uses user-mapping.xml will cache the connections available >> to a particular user once they log in, associating that information with >> their session from that point forward. They will not see the results of >> changes to that file until after they log out (or until they log in >> elsewhere). >> >> If a new browser is used then the problem does not seem to appear. >>> >> >> Yep. See above. >> >> >>> So, would like to know how can I force flush cookies (if thats the >>> problem) whenever guacamole UI is reloaded ? >>> >> >> I don't think you should continue pursuing a solution driven by >> user-mapping.xml. That authentication method is intentionally simple, and >> not intended to serve as the middle ground between Guacamole and an >> external authentication system. It's really aimed at simple deployments, or >> as a quick way to verify that Guacamole works as expected before moving on >> to something like LDAP or a database. >> >> In your case, where the idea is to integrate Guacamole with an external >> system, I highly recommend developing an extension which does so. Guacamole >> provides an API to achieve exactly this, and it's how the other >> authentication extensions were written. There's no need to hack things >> together using XML as an intermediary. >> >> - Mike >> >> >
Re: Console ID Cache issue when using user-mapping.xml
Thanks Mike for detailed information and saving hours in pursuing wrong path. I'd definitely look into custom auth and build something for us. I'm simply looking for a web callback as authentication mechanism. Let me know if its already present while I proceed to develop one. And in case I'm getting it working, can I contribute it back ? - Rishi On Tue, Oct 18, 2016 at 3:54 AM, Mike Jumper wrote: > On Tue, Oct 11, 2016 at 3:41 AM, Rishi <2rushike...@gmail.com> wrote: > >> Hello All, >> >> > Hello Rishi, > > >> I'm using guacamole in an automated fashion such that after completing >> the external authentication, a new user-mapping.xml is generated. >> > > The intended mechanism for integrating Guacamole with external > authentication is not through auto-generating XML, but rather through > extensions: > > http://guacamole.incubator.apache.org/doc/gug/guacamole-ext.html > > http://guacamole.incubator.apache.org/doc/gug/custom-auth.html > > More on this below. > > The guacamole authentication in this case works correct however websocket >> connection for console happens to the last consoled vm. It is not able to >> properly disconnect last websocket session upon generation of new >> user-mapping.xml. I suspect its the cookies ! >> >> > Guacamole doesn't use cookies in this way, but the authentication > mechanism that uses user-mapping.xml will cache the connections available > to a particular user once they log in, associating that information with > their session from that point forward. They will not see the results of > changes to that file until after they log out (or until they log in > elsewhere). > > If a new browser is used then the problem does not seem to appear. >> > > Yep. See above. > > >> So, would like to know how can I force flush cookies (if thats the >> problem) whenever guacamole UI is reloaded ? >> > > I don't think you should continue pursuing a solution driven by > user-mapping.xml. That authentication method is intentionally simple, and > not intended to serve as the middle ground between Guacamole and an > external authentication system. It's really aimed at simple deployments, or > as a quick way to verify that Guacamole works as expected before moving on > to something like LDAP or a database. > > In your case, where the idea is to integrate Guacamole with an external > system, I highly recommend developing an extension which does so. Guacamole > provides an API to achieve exactly this, and it's how the other > authentication extensions were written. There's no need to hack things > together using XML as an intermediary. > > - Mike > >
Re: Console ID Cache issue when using user-mapping.xml
On Tue, Oct 11, 2016 at 3:41 AM, Rishi <2rushike...@gmail.com> wrote: > Hello All, > > Hello Rishi, > I'm using guacamole in an automated fashion such that after completing the > external authentication, a new user-mapping.xml is generated. > The intended mechanism for integrating Guacamole with external authentication is not through auto-generating XML, but rather through extensions: http://guacamole.incubator.apache.org/doc/gug/guacamole-ext.html http://guacamole.incubator.apache.org/doc/gug/custom-auth.html More on this below. The guacamole authentication in this case works correct however websocket > connection for console happens to the last consoled vm. It is not able to > properly disconnect last websocket session upon generation of new > user-mapping.xml. I suspect its the cookies ! > > Guacamole doesn't use cookies in this way, but the authentication mechanism that uses user-mapping.xml will cache the connections available to a particular user once they log in, associating that information with their session from that point forward. They will not see the results of changes to that file until after they log out (or until they log in elsewhere). If a new browser is used then the problem does not seem to appear. > Yep. See above. > So, would like to know how can I force flush cookies (if thats the > problem) whenever guacamole UI is reloaded ? > I don't think you should continue pursuing a solution driven by user-mapping.xml. That authentication method is intentionally simple, and not intended to serve as the middle ground between Guacamole and an external authentication system. It's really aimed at simple deployments, or as a quick way to verify that Guacamole works as expected before moving on to something like LDAP or a database. In your case, where the idea is to integrate Guacamole with an external system, I highly recommend developing an extension which does so. Guacamole provides an API to achieve exactly this, and it's how the other authentication extensions were written. There's no need to hack things together using XML as an intermediary. - Mike