Bug 229374 - Persist authenticated passwords in secure storage
Summary: Persist authenticated passwords in secure storage
Status: ASSIGNED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Team (show other bugs)
Version: 3.4   Edit
Hardware: PC Windows XP
: P3 enhancement with 4 votes (vote)
Target Milestone: ---   Edit
Assignee: Platform Team Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 115371 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-04-29 11:57 EDT by John Arthorne CLA
Modified: 2015-04-01 09:44 EDT (History)
9 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description John Arthorne CLA 2008-04-29 11:57:52 EDT 
I20080429-0100

1) Connect to a repository that requires login by adding and expanding the site in the available software dialog.
2) Shutdown and restart
3 Try to expand the site again

-> Prompted again for the password. Since we are using secure storage, it should not ask me again.
Comment 1 John Arthorne CLA 2008-04-30 18:07:36 EDT 
This is actually the authentication dialog from org.eclipse.ui.net that is coming up. I'm going to move this to Net team as an enhancement to persist authenticated passwords across sessions in the equinox secure store
Comment 2 Michael Valenta CLA 2008-05-01 10:16:03 EDT 
The issue with this is that the java.net authenticator is not given much context so it doesn't know if it is being asked for a password because of an authentication failure or not. If we use the secure storage, we would need to come up with a strategy for determining whether to provide the password that is stored or not. A simple strategy that may work is this:

- If the authenticator is called and there is no password stored, prompt and record that a password was provided
- If the authenticator is called and there is a password
    - if the password was not previously provided, provide it and record that it was provided
    - if the password was previously provided, assume that authentication failed, discard the password and prompt for a new one
Comment 3 John Arthorne CLA 2008-05-08 10:03:22 EDT 
*** Bug 115371 has been marked as a duplicate of this bug. ***
Comment 4 John Arthorne CLA 2008-09-15 19:31:50 EDT 
*** Bug 247279 has been marked as a duplicate of this bug. ***
Comment 5 Ben Vitale CLA 2009-02-23 10:07:08 EST 
It might be too late for 3.5, but this would be really nice to have. 

For those who need a workaround, it appears that if you just cancel the first dialog, the second one that surfaces has the appropriate check box, and does persist the password. I guess that's what I'll have to tell our users :)
Comment 6 David Kyle CLA 2009-02-23 10:22:12 EST 
(In reply to comment #5)
> For those who need a workaround....

The work around does not work if the Eclipse IDE has been installed as a "shared install" (described in "Eclipse multi-user installs" help page).

In a "shared install" environment the IDE does not save the password.
Comment 7 Szymon Brandys CLA 2015-04-01 09:44:28 EDT 
I am no longer involved in Platform Team/Compare development.