Open the VPN - openconnect Juniper dialog and start a conection to the VPN host. The frmLogin widget apears where the realm, username and password have to be set. If the realm is changed, the widget starts to reload endlessly, making it impossible to fill in the rest of the fields. Happens all the time.
I wonder whether this bugzilla is actually working. No replies, not assigned, no comments. Anybody there?
Bugzilla is working fine. You have to wait until a developer who uses Juniper can reproduce the issue to propose a fix.
Can I try with the server you use? I don't need your credentials, just server address so I can attempt to connect and reproduce the issue?
May I send the address privately? I don't want it to appear publicly
Sure, you can send it to jgrulich@redhat.com and I will take a look as soon as possible.
Created attachment 116306 [details] Proposed patch to fix this issue I figured out why this is happening and have a solution for this, however I'm not sure if this will have any side-effect, because I'm not the original author of the openconnect VPN plugin. Basically if you change the group, it will reset the form and try to contruct it again, but this time it will go to the condition which can be seen in the patch and will immediately call that the group changed, resulting again into form reset and this is happening over and over. Can you test this patch to verify it works?
Glad to. However, I'll need too compile the code, which I have not downloaded. Would you point me to the source code?
The code can be found here: https://cgit.kde.org/plasma-nm.git/
Works like a charm. No side effects that I have noticed. Thanks a lot.
Git commit 00d18e2d9cef69cd8066b63c2c5dc40748c8e61e by Jan Grulich. Committed on 18/11/2018 at 18:12. Pushed by grulich into branch 'Plasma/5.14'. Openconnect: do not reload the auth dialog endlessly when group changes I'm not completely sure if this will effect something else, but seems to work just fine. M +0 -3 vpn/openconnect/openconnectauth.cpp https://commits.kde.org/plasma-nm/00d18e2d9cef69cd8066b63c2c5dc40748c8e61e
Created attachment 116644 [details] Proposed patch to fix this issue It looks that the previous fix was not correct and had some side effects, see bug 401554. Can you please try this patch?
You can ignore the proposed patch, it won't work if we need to reload the dialog in case we change the group initially.
(In reply to Jan Grulich from comment #12) > You can ignore the proposed patch, it won't work if we need to reload the > dialog in case we change the group initially. I tried this second patch and it did not work (no endless loop, but no login). However, your original patch did work for me: I was able to change the group and log in. Hope you get the issue straight.
Now, this endless loop comes up when using a Juniper server. I had previously used a Cisco Openconnect server with no issues. Apparently Cisco openconnect needs redrawing the widget, while the juniper variant does not, since the dialog already contains all information needed. So I'd suggest testing for the protocol before placing the QTimer::singleShot(). Sadly, openconnect_get_protocol only comes with version 5.5, that has not yet reached my distribution.
Created attachment 116677 [details] Working, but ugly, patch Building on your patches and on my idea, I came up with the patch in the attachment. It is not all that elegant but works both for my openconnect-juniper issue and bug 401554, at least from what I have been able to test through a self-configured Cisco openconnect (anyconnect) server on localhost. It would be nice to have it tested against a proper server. In my opinion, openconnect_get_protocol() should be used, but we will have to wait (and set the dependencies)
Are you sure that Juniper VPN doesn't need to reload if you change the group? If so, there is also slot connected to group change below, causing the dialog to reload for the first time and later on it goes to this QTimer::singleShot() causing it to reload endlessly.
(In reply to Jan Grulich from comment #16) > Are you sure that Juniper VPN doesn't need to reload if you change the > group? If so, there is also slot connected to group change below, causing > the dialog to reload for the first time and later on it goes to this > QTimer::singleShot() causing it to reload endlessly. I tried commenting out the connection, but the endless loop comes again. That connection doesn't seem to be needed nor harmful in this case. Removing it together with my ugly patch still works. The way it works as I understand it is as follows. We need a first connection to the server to get the groups and populate the ComboBox. The QTimer::singleShot() call makes it reload as soon as the index of the ComboBox changes, which will occur immediately if there is an entry different from the first in the configuration (i.e. in the last successful connection), or when the user selects the group. This triggers a formGroupChanged(), establishing a new connection with the server. I am unsure as to how this is done but the form is deleted in formLoginClicked and afterwards a d->workerWaiting.wakeAll() call probably does the trick. So the only way for Juniper VPN seems to be not to reload the form. I do not have the specs (all of the above is experimental) but since we get all info needed with the first connection to the server, I see no need to reload the form.
(In reply to Jan Grulich from comment #16) > Are you sure that Juniper VPN doesn't need to reload if you change the > group? If so, there is also slot connected to group change below, causing > the dialog to reload for the first time and later on it goes to this > QTimer::singleShot() causing it to reload endlessly. The connection you mention makes no harm because it is only triggered when the ComboBox changes after the form is initialized, that is, after the configuration has been read and the form populated. Then formChanged() will reload the form through a connection with the server, but there will be only one such reload. However, the current implementation reloads the form right when the index is changed to any value other than the default because the condition ( i != AUTHGROUP_SELECTION(form) ) will be true, and that condition repeats itself. This implementaton will only work if the user connects to the first entry in the ComboBox, which, alas, is not my case. I assume it works for other VPN flavors because after the first connection, the field is no longer tagged as AUTHGROUP_OPT, but I can't say for sure.
Created attachment 116737 [details] New patch, check form From vpn/openconnect/README: The auth-dialog handles the arbitrary forms as the server presents them, and spits out the cookie after a successful authentication. It's just a really simple web-browser, effectively. This is why reconnections are needed: the auth-dialog fills in the forms with the stored information, reconnects the server and receives the next form. The the process is repeated until there is no more information available, so that the user can fill in the rest if the connection is still not successful. So the key to solve this issue in a more general way would be to check the form and block the reconnection if the form has not changed. This is what I have done in the attached patch, and it apparently works (at least works for me). Now I'd appreciate someone checking the code (I'm not a great programmer), and testing it with other openconnect servers. y own testing is successful, but I don't have a real server to test on. I guess there are other possibilities to get this done, but I think the idea is correct.
I reopened the bug to
(In reply to emelenas from comment #20) > I reopened the bug to Sorry, that did not get out well. I reopened the bug because the initial patch was reverted and thus my issue stands. See my analysis and alternatives above.
Hi, thank you for looking into that, can you please open a PR in phabricator so I can review it properly? If you don't know how to use it: https://community.kde.org/Infrastructure/Phabricator
(In reply to Jan Grulich from comment #22) > Hi, > > thank you for looking into that, can you please open a PR in phabricator so > I can review it properly? There you go: https://phabricator.kde.org/D17487
Git commit b2f6422c89c77d80852be1929ff6ca610328b3c1 by Jan Grulich. Committed on 17/12/2018 at 15:18. Pushed by grulich into branch 'Plasma/5.14'. Openconnect: do not reload dialog when group changes for Juniper protocol M +11 -0 vpn/openconnect/openconnectauth.cpp https://commits.kde.org/plasma-nm/b2f6422c89c77d80852be1929ff6ca610328b3c1
Tested and working. Thanks.
Bulk transfer as requested in T17796