On Fri, Oct 21, 2016 at 2:56 AM, Rishi <[email protected]> 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
