On Thu, Jul 5, 2018 at 10:35 AM, Brian J. Johnson <[email protected]> wrote:
> On 07/04/2018 03:12 AM, David Woodhouse wrote:
>> Did you try the suggestion I made? Which would look something like
>> this:
>>
>> --- a/auth-juniper.c
>> +++ b/auth-juniper.c
>> @@ -189,8 +189,6 @@ static int parse_select_node(struct openconnect_info
>> *vpninfo, struct oc_auth_fo
>> xmlnode_get_prop(node, "name", &opt->form.name);
>> opt->form.label = strdup(opt->form.name);
>> opt->form.type = OC_FORM_OPT_SELECT;
>> - if (!strcmp(opt->form.name, "realm"))
>> - form->authgroup_opt = opt;
>> for (child = node->children; child; child = child->next) {
>> struct oc_choice **new_choices;
>>
>>
>> Or if you're not able to build for yourself and you're not using HTTP
>> Digest auth to connect to anything (hint: you aren't), just:
>>
>> sudo s/realm/rXXXm/g -i /usr/lib/x86_64-linux-gnu/libopenconnect.so
>>
>
> David,
David,
You recently applied this patch on master ("Don't treat Juniper
'realm' field as authgroup",
http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/b0a50a7e80e9b6a2d8aaa44c74b350a4aab51dc7).
Unfortunately, it doesn't work…
1) It doesn't fix the "snapback" issue. I tested this version with
both the NM GUI, and Kevin Cernekee's Android client (with
multiprotocol patches add:
https://github.com/dlenski/ics-openconnect)… the snapback still
happens.
2) It prevents Juniper users from doing `--authgroup XYZ` from the
command line, which is necessary for a lot of folks I suspect.
I still don't understand what causes the "snapback" issue. It is a
very strange bug indeed. What I'm hung up on is that *even if*
OC_FORM_RESULT_NEWGROUP triggers an unnecessary reloading of the form…
it should still cause it to reload with the *new* value, not the old
one… right?
I haven't been able to figure out why that happens.
-Dan
_______________________________________________
openconnect-devel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/openconnect-devel
