Closed reprogrammer closed 13 years ago
The good news is that in Indigo a user would not need to do anything additional in order to avoid Eclipse asking for the password each time. I installed CodingSpectator on a clean Indigo, was prompted once for the user name and password, checked the box to remember the password and that's it - I closed Eclipse and started it again a couple of times, each time uploading CodingSpectator data, and I was not asked for my authentication info any more. This is because Indigo has Windows Integration (64 bit) password provider (used with the highest priority by default), whose comment "The provider uses Windows APIs to encrypt a randomly generated 'master' password in a way specific to the login credentials. Users who can log into the Windows account can access contents of the secure storage." shows that it does exactly what we want it to do.
Also, it is supposed to work in a similar way for Eclipse Helios, unless the OS is 64 bits. I can not double check right now that it indeed works for a 32 bits Windows since my only Windows OS on the laptop is 64 bits. In the case of 64 bits Windows, a user would need to follow the instructions from comments 27 and 28 of Bug 226482. If a user did not use a master password for CodingSpectator prior to dropping the downloaded .jar into "dropins" folder of Eclipse, then he/she would not need to perform any additional actions. Otherwise, the user will have to delete the existing master passwords as it is described in the comment 27 of Bug 226482. I followed the referenced instructions, and now it works in my Helios installation the same way as it does in Indigo.
@Wanderer777: Could you write up the instructions for setting up Eclipse secure storage in Windows? Please either post your text to this issue or add it directly to the user guide.
The following applies to Windows OS users only:
If you are using Eclipse Indigo with any Windows OS, or Eclipse Helios with 32 bits Windows, and you would like Eclipse to remember your CodingSpectator password such that it does not prompt for your password every time you start to upload CodingSpectator data, just mark the "Save password" check box of the CodingSpectator authentication dialog window the next time you upload CodingSpectator data.
If you are using Windows 64 bits and Eclipse Helios, then you would need to perform additional steps to avoid Eclipse prompting for your password each time you upload CodingSpectator data. You can either upgrade to Eclipse Indigo, or perform the following steps:
@Wanderer777: Thanks for posting the instructions for enabling secure storage on Eclipse Helios run on Windows 32 bits. Screenshots would make it easier for the users to follow the steps. Could you take the following two screenshots on your windows machine?
[Default Secure Storage]
option.dropins
folder on the preferences dialog of Eclipse.Please put the screenshots into the documentation/user-guide/figs/
folder of the repostory.
@reprogrammer:
Instructions are for Eclipse Helios on Windows 64 bits, not 32 bits.
I uploaded the screenshots, including two screenshots that show Eclipse secure storage preferences before and after copying the above referenced JAR into the dropins
folder.
@Wanderer777: Thanks for your clear instructions on how to properly set up the secure storage for Eclipse Helios on Windows 64 bits. I've added your instructions to the user guide in 6f9509d8ba359a50e006d70b029fc1a3b388e275. But, I didn't include the figure documentation/user-guide/figs/PreferencesBeforeCopyingJarToDropinsFolder.png
because I found documentation/user-guide/figs/PreferencesAfterCopyingJarToDropinsFolder.png
sufficient. Please review the new section of the user guide and let me know if you find any problems.
@reprogrammer: The new section looks good, thanks.
@Wanderer777: I published the new user guide with a section on saving passwords. But, I've found the sizes of the screenshots a bit odd in the HTML version of the user guide. One of your screenshots of the preference page is much bigger than the other one. And, both screenshots are a little bigger than the rest of the screenshots of the user guide. Could you please make the screenshots a bit smaller to make them consistent with the rest of the figures?
@reprogrammer: Unfortunately, this was the minimum size before scroll bars appear (and make the image ugly). I could reduce the font size, but this would make the text less readable. So, instead of capturing new screenshots, I shrank the existing images to make them smaller and look more in the line with the other figures. The size of the images is still different since they are showing different text that has to fit in the message box without scroll bars. Please let me know if this is fine.
@Wanderer777: Your new images look good in the HTML but not PDF.
The screenshots of @vazexqi and @Wanderer777 are of similar sizes but they scale differently in the PDF file. Do you have any ideas why the screenshots of @Wanderer777 become smaller than the others in the PDF file?
@vazexqi: You're right. The resolutions of the screenshots of @Wanderer777 are about 120x120 ppi and those of @vazexqi are 72x72 ppi.
I noticed that in the .tex file for the user guide we do not specify the sizes of figures. I think that if we do that for my screenshots we can ensure that they are big enough (at least as big as other screenshots). Or we could do it differently - restore the previous, bigger screenshots (which looked good in the .pdf) and shrink them explicitly in the .html file (though I am not quite sure how to do that).
@Wanderer777: It might be possible to specify the sizes of the figures in the TeX files. But, I remember it was difficult to do mainly because we'd like to generate the user guide in two formats (HTML and PDF). I think it's easier to make the resolutions of the screenshots consistent.
@reprogrammer. I reduced DPI of my screenshots to 72. Please check if this helped.
@Wanderer777 and @vazexqi: I regenerated the user guide and published it on the home page. The screen shots look good. Thanks!
Eclipse secure storage integrates well with the Mac OS X, and Eclipse uses the system wide keyring to access the secure storage. Therefore, once the user saves the CodingSpectator password in Eclipse secure storage, CodingSpectator will no longer prompt the user for password. @vazexqi and some of our participants are using this feature.
Currently, if a Linux users saves his/her CodingSpectator password into the secure storage of Eclipse, he/she will still have to provide the master password of Eclipse secure storage every time CodingSpectator tries to submit data. There's an open Eclipse bug for integrating the Eclipse secure storage with the system-wide keyring of Linux (See Bug 234509).
I'm not sure if the secure storage of Eclipse can use the system wide keyring of Windows. I've found a closed Eclipse Bug (Bug 226482) that implies this feature is supported on Windows. However, it looks like this feature is not turned on by default on Eclipse and the user has to set it up.
@vazexqi: Do Mac users have to follow certain steps to make the secure storage of Eclipse use the system wide keyring? If so, it would be nice to add the instructions to our user guide so that we free our Mac users from remember their CodingSpectator password.
@Wanderer777: Can you take a look at Bug 226482 and follow the instructions mentioned in this bug report on Windows to make the secure storage of Eclipse use the system wide keyring of Windows? Please let us know if you find a way to avoid the Eclipse secure storage dialog that asks for the master password every time the user tries to upload CodingSpectator data. If you find a solution for this on Windows, we'll add the instructions to our user guide because it will free our Windows users from remembering their CodingSpectator passwords.