From user-return-5526-archive-asf-public=cust-asf.ponee.io@guacamole.apache.org Mon Mar 4 23:35:02 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 3A489180627 for ; Tue, 5 Mar 2019 00:35:02 +0100 (CET) Received: (qmail 51792 invoked by uid 500); 4 Mar 2019 23:35:01 -0000 Mailing-List: contact user-help@guacamole.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@guacamole.apache.org Delivered-To: mailing list user@guacamole.apache.org Received: (qmail 51783 invoked by uid 99); 4 Mar 2019 23:35:01 -0000 Received: from mail-relay.apache.org (HELO mailrelay1-lw-us.apache.org) (207.244.88.152) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Mar 2019 23:35:01 +0000 Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 4FE7C448E for ; Mon, 4 Mar 2019 23:35:00 +0000 (UTC) Received: by mail-ot1-f41.google.com with SMTP id i12so5809320otp.12 for ; Mon, 04 Mar 2019 15:35:00 -0800 (PST) X-Gm-Message-State: APjAAAVldC6V3woXloWAspqZSGxklr5TX0FFmcmjavNp4IGF04VHfy5T I+DxnVEWVdmQoFTFYayJ8DFjVpTyUse0eDDq86w/HA== X-Google-Smtp-Source: APXvYqxIt0+yiIkidbd20qIAL4Lg6O7M7KNl478EIMdc3ktXbZEoS0oAQRb9iwkkI6NHZ9g6BoAb/d8h1tWPZ6KX4SI= X-Received: by 2002:a9d:7ad6:: with SMTP id m22mr15213907otn.166.1551742499709; Mon, 04 Mar 2019 15:34:59 -0800 (PST) MIME-Version: 1.0 References: <1551308771018-0.post@n4.nabble.com> <1551323778369-0.post@n4.nabble.com> <1551738759567-0.post@n4.nabble.com> In-Reply-To: <1551738759567-0.post@n4.nabble.com> From: Mike Jumper Date: Mon, 4 Mar 2019 15:34:23 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Authentication Changes in 1.0.0 To: user@guacamole.apache.org Content-Type: multipart/alternative; boundary="0000000000007a7ca305834d3458" --0000000000007a7ca305834d3458 Content-Type: text/plain; charset="UTF-8" On Mon, Mar 4, 2019 at 2:32 PM Lee wrote: > Thanks Nick and Mike. > > The change ended up being on the front end & connection to the > authentication module. We were destroying the users cookie if they tried to > re-connect. With the changes to have that information in local storage, > that > broke our authentication process before it started. I suppose we'll have to > see if deleting the local storage objects as well now will work. I wouldn't recommend destroying local storage objects as a means of achieving this. You old solution (destroying the user's cookie) is built upon a workaround which actively fights the internals of the webapp, and so will be brittle. You should instead look to a solution which is built upon (not against) what's provided. The extension API allows for user data to be derived dynamically (see previous emails in this thread), including based on changes to the request like the cookie that your system generates. I recommend leveraging that aspect of the API to achieve what it's designed to do. You might additionally look into using the anonymous username for your users on the Guacamole side: http://guacamole.apache.org/doc/guacamole-ext/org/apache/guacamole/net/auth/AuthenticatedUser.html#ANONYMOUS_IDENTIFIER The anonymous user has different semantics and will not persist the auth token: https://github.com/apache/guacamole-client/blob/5ce0c0f0358096d87e19c7decdb4d6dfd21aeff5/guacamole/src/main/webapp/app/auth/service/authenticationService.js#L118-L120 - Mike --0000000000007a7ca305834d3458 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon,= Mar 4, 2019 at 2:32 PM Lee <ldoughty= @vt.edu> wrote:
Thanks Nick and Mike.

The change ended up being on the front end & connection to the
authentication module. We were destroying the users cookie if they tried to=
re-connect. With the changes to have that information in local storage, tha= t
broke our authentication process before it started. I suppose we'll hav= e to
see if deleting the local storage objects as well now will work.

I wouldn't recommend destroying local storage obj= ects as a means of achieving this. You old solution (destroying the user= 9;s cookie) is built upon a workaround which actively fights the internals = of the webapp, and so will be brittle. You should instead look to a solutio= n which is built upon (not against) what's provided.

The extension API allows for user data to be derived dynamically (se= e previous emails in this thread), including based on changes to the reques= t like the cookie that your system generates. I recommend leveraging that a= spect of the API to achieve what it's designed to do.

You might additionally look into using the anonymous username for y= our users on the Guacamole side:


The anonymous user has different= semantics and will not persist the auth token:

https://github.com/apache/guacamole-client/blob/= 5ce0c0f0358096d87e19c7decdb4d6dfd21aeff5/guacamole/src/main/webapp/app/auth= /service/authenticationService.js#L118-L120

- Mike

--0000000000007a7ca305834d3458--