Community
Participate
Working Groups
The function to prevent users from saving their passwords has been provided, but is missing. The function is required to satisfy the security policy.
The function has been added. This is an API change. It is a breaking change since it adds new methods to an existing interface. The standard implementations of this interface have been modified to provide implementations of these methods so the changes should be source compatible. Changes to IConnectorService: /** * Sets the attribute for this connector service instance that denies a password to be saved. * If the attribute has never been set it defaults to false. * If set to true, it will clear any saved passwords for this system and not allow any further * passwords to be stored. * This property of a system is persistent from session to session, but is not sharable. * @param deny * If true, forget any saved passwords and do not allow any others to be saved. * If false, allow passwords to be saved in the keychain. * @return the number of saved passwords removed by this operation. * This will always be zero if "deny" is false. * @since org.eclipse.rse.core 3.0 */ public int setDenyPasswordSave(boolean deny); /** * Retrieves the value of the "DENY_PASSWORD_SAVE" property of this connector service. * If the value has never been set, this will return false. * @return true if password saving is denied. * @since org.eclipse.rse.core 3.0 */ public boolean getDenyPasswordSave(); AbstractConnectorService and AbstractDelegatingConnectorService have been modified to implement these. RSEPreferencesManager has added methods for setting this preference since it is a complex preference. Other changes made are not API.
I will be committing this as specified, but I would like to remove the whole notion of a "default" system type from the API. Having one poses several consistency problems. I will be posting on the developer mailing list about this as well.
I've found that there is a requirement for the DEFAULT_SYSTEM_TYPE, but that we probably didn't have it implemented quite correctly. I've made slight modifications to the behavior of the password persistence manager as a result of these discussions. The external behavior of saved should be identical to what we have come to expect. Changes have been committed.
I don't think this is a breaking change, since IConnectorService is marked @noimplement in its class Javadoc. http://wiki.eclipse.org/Evolving_Java-based_APIs#Example_4_-_Adding_an_API_method That's actually a good example how important the @no... API markup in Javadoc is. We should review all our APIs and add these markup where appropriate. The new Platform SDK 3.4M6 API Tooling component helps us with this. To that end, I have reviewed parts of rse.services and rse.core but not yet all of it. http://wiki.eclipse.org/API_Tooling_User_Guide With respect to the API changes made, there are more than those listed in comment 1 - can you please set the required @since tags (hint: use M6 API Tooling) Add RSEPreferencesManager#setDenyPasswordSave(IRSESystemType, String, boolean); Add RSEPreferencesManager#getDenyPasswordSave(IRSESystemType, String); Add PasswordPersistenceManager#RC_DENIED; Add PasswordPersistenceManager#remove(IRSESystemType, String); In general, I'm wondering why the PasswordPersistenceManager methods use (IRSESystemType type, String address) parameters to identify a host. Note that there might eventually be other addressing schemes than TCP/IP which might be hard to serialize into a "String" address. Would it make sense to use an IHost instead of the (IRSESystemType, String) tuple? Or could the password persistence manager ever be needed for remote systems that are not an IHost object yet?
