Bugzilla – Full Text Bug Listing
| Summary: | 'Save password' unchecks itself without interaction with the user | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Markus Keller <markus.kell.r> | ||||||||
| Component: | Team | Assignee: | Tomasz Zarna <tomasz.zarna> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | daniel_megert, ob1.eclipse, tjwatson, tomasz.zarna | ||||||||
| Version: | 3.7 | ||||||||||
| Target Milestone: | 3.7 M3 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Markus Keller
Oleg, could you take a look at this? The secure storage provides an API for this: ISecurePreferences#flush() it is up to the consumer to call that immediately or rely on saving on shutdown. (As a side note, development of the secure storage was shut down a few releases ago. Hence, it is missing a layer that I would call "accounts" and only provides low-level APIs. I'd love to continue developing that area, but it has not been on the plan for several releases.) Thomas, Oleg did you leave the target milestone set to 3.7 on purpose when moving it to Team? Are you ok with resetting it to something better matching the reality from our perspective i.e. '---'? Markus, is it fine with you? Isn't this just about adding one line of code at the right place(s)? Should be too time consuming compared to the havoc it can cause. >Should be too time consuming
SHOULDN'T.
I agree with Dani, though it will probably need the same method call in 3 locations (new connection wizard, connection properties page, dialog that asks during team operations). Yeah, I guess you're right. Let's leave the target as it is. I think I could skip one coffee break and fix this, right? :) (In reply to comment #0) > The secure storage should be written to disk immediately after the user entered > new information (e.g. a new CVS password). Currently, it looks like this is > only persisted on shutdown. > > For one, I just lost a password update because the machine crashed, and I had > to enter the new password again after restart. I've checked that and in both scenarios I tried (changing password in the CVS Repositories view and setting a password when prompted) as long as the 'Save password' option was checked the new password has been flushed[1] immediately. So, I guess persisting the password on shutdown is not a case here. In other words, this works fine to me. Once I terminated a self-hosted Eclipse just after I entered a new password, after lunching Eclipse again the password was there. Markus, if you disagree please provide detailed steps I could use to reproduce the problem. Maybe I missed something. > Another scenario where this hurts is when you work with 2 workspaces that share > the same secure storage location (the default). After changing a password in > one workspace, the other workspace does not see the update. I would expect it > to read the current contents of the storage at least when a stored password > failed and the user is asked for a new password. > > Currently, the user has to update a password in all open workbenches, or he has > to close all instances of Eclipse except for one, then change the password > there, and then restart also that last Eclipse instance before restarting the > others. Agreed, this sounds like something that needs to be fixed. Re-reading the Secure Storage on password failure could work, but I think a better solution would be to listen to changes in a particular CVS node from secure preferences. Oleg, is there an API for that? [1] org.eclipse.team.internal.ccvs.core.connection.CVSRepositoryLocation.updateCache(String, String) (In reply to comment #8) > I've checked that and in both scenarios I tried (changing password in the CVS > Repositories view and setting a password when prompted) as long as the 'Save > password' option was checked the new password has been flushed[1] immediately. > So, I guess persisting the password on shutdown is not a case here. Setup: - open CVS Repositories view - paste connection: :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse - open Properties - change password to "a", check "Save password", click OK => password saved to disk (good) Password lost on change: - open Properties - change password to "b", (do NOT touch the checked "Save password"), click OK => password is not saved to disk any more => the next time I open the Properties dialog, "Save password" is unchecked (In reply to comment #0) > Currently, it looks like this is only persisted on shutdown. That was probably a wrong observation. I guess in the cases the password was stored after a change, I actually entered the password again in the prompt and checked the "Save password" box there. Created attachment 180602 [details] Fix v01 Fix for the problem from comment 9. Created attachment 180603 [details]
mylyn/context/zip
(In reply to comment #8) > Re-reading the Secure > Storage on password failure could work, but I think a better solution would be > to listen to changes in a particular CVS node from secure preferences. > > Oleg, is there an API for that? Filed bug 327530 to address that. Created attachment 180656 [details]
Fix v02
A safer version of Fix v01.
Fix v02 applied to HEAD, available in builds >=I20101012-0800. (In reply to comment #8) > > Another scenario where this hurts is when you work with 2 workspaces that share > > the same secure storage location (the default). ... > Oleg, is there an API for that? No, sorry. This is a known limitation; we don't have "merge" for the secure storage. If anybody feels like creating a patch for this, it will be given all possible attention. |