On Thu, Nov 2, 2017 at 5:48 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
>
> On Wed, 2017-11-01 at 22:19 -0700, Daniel Lenski wrote:
> >
> > The Juniper realm dropdown box ("authgroup" in openconnect-internal
> > parlance) can't be modified when connecting to a Juniper VPN via the
> > OpenConnect NM GUi plugin. If I try to change the realm, it snaps back
> > to the previous value just as Peter describes. Screenshot showing the
> > offending UI element: https://snag.gy/ZGfOWJ.jpg
> >
> > Strangely, this problem does *not* apply to AnyConnect-protocol VPNs,
> > even though I know the form is stored internally in an identical
> > format.
>
> This is probably related to the OC_FORM_RESULT_NEWGROUP handling, where
> the UI 'submits' the form with that result code immediately when the
> user changes the group ? to allow for the other fields which
> appear/disappear according to the authgroup selection.
Aha, that makes sense! When you select a new authgroup choice while
connecting to an AnyConnect VPN, other fields can change.
> It looks like Juniper does *nothing* except looping on
> process_auth_form() while (ret == OC_FORM_RESULT_NEWGROUP). So the
> question is why the UI's setting of the authgroup selection isn't
> actually being saved.
Right.
> One option might simply be *not* to set form->authgroup_opt, which is
> what triggers the UI to treat this option as the special "authgroup"
> option, and return OC_FORM_RESULT_NEWGROUP when it changes. There's no
> *need* for that special handling in this case as it isn't being used
> anyway.
Gotcha. Will skipping that affect the behavior of the CLI form-field
inputs? I think not.
> Dan, where are we with the final cleanups to the GP code to get that
> merged? I spent a little while heckling and thought you were going to
> keep going with the resulting minor cleanups?
I actually was thinking about this recently :-). I went through
previous email threads recently and tried to figure out if there were
any specific changes you were waiting on from me. If this is the
complete list (http://lists.infradead.org/pipermail/openconnect-devel/2017-August/004466.html)
you were waiting for me to:
- Plug any remaining memory leaks
- Move the UserAgent-mangling into a separate function (presumably
customized for each protocol)
Is there anything else that's holding it up?
Thanks,
Dan
