Hide Forgot
Description of problem: If you change the Authentication or inner authentication drop downs in the configuration for a new wireless network connection the "Ask for this password every time" check box gets reset. Version-Release number of selected component (if applicable): NetworkManager-0.8.999-2.git20110509.fc15.x86_64 How reproducible: Always Steps to Reproduce: 1. Start configuring a WPA2 Enterprise connection. 2. Check "Ask for this password every time" 3. Change the connection Authentication from Tunneled TLS to PEAP 4. The check box is reset. 5. Check "Ask for this password every time" 6. Change Inner authentication from MSCHAPv2 to GTC 7. The check box is reset. Actual results: The "Ask for this password every time" check box keeps getting reset Expected results: It stays checked. Additional info: Connections get created as 'Available to all Users' so this has potential to give away a users password if they don't notice the box getting reset.
The value of the "Ask for this password every time" box is basically not reset. Rather, the check box and also other info (username, password, show password) are remembered for each inner authentication type, while editing the dialog. And I see that quite useful when you play around this the options. Even if I see your point and not completely against the change I still prefer the current behaviour. Dan, what do you think?
The checkbox should probably say either checked or unchecked across all EAP methods once set. The problem is that internally each EAP method uses different data in the applet/connection editor, so coordinating those would be hard. One way to do it would be to create a simple GObject in src/wireless-security/ called AlwaysAskController that then EAPMethodPEAP and EAPMethodTTLS would instantiate in their eap_method_*_new() functions. This object would have one property ('always-ask' type BOOLEAN). EAPMethodPEAP/TTLS would initialize the AlwaysAskController with the current value of the always-ask flag, and would then pass this object to each of the EAPMethodSimple objects they create. The Simple methods would attach to the "notify::always-ask" signal of the AlwaysAskController (and detach when they are destroyed) and would control their checkbox based on that value. The other option is to stuff this sort of thing into WirelessSecurity (which the Simple methods have access too) but I'm not sure that's at the right abstraction level here, and as it's not a GObject we'd have to implement some sort of signal-type functionality there anyway. I think the simple GObject mechanism above is pretty encapsulated. Thoughts?
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping