Community
Participate
Working Groups
The ssh service has its own method of dealing with passwords (or passphrases), typically the user has set up a private key so no password is required. It is disturbing that the password dialog FORCES entering a dummy password even if ssh is set up not to need one. RSE should allow the subsystems to specify that they do not need a password, or not even a username (as may be the case for communication with embedded devices). If no subsystem configured for the given system type needs a password (or not even a username), these should not be queried from the user upon connect. More specifically, it might be that even the connector service is responsible for deciding whether user id and / or password is required or not.
duplicate of 147532
Both userid and password should be independently promptable from the same dialog. The connector service should make the decision. Thus, I think we need a new API in the connector service. public boolean requiresPassword(); public boolean requiresUserId(); AbstractConnectorService.promptForPassword would query these from the subclasses and provide default implementations that return true. The dialog class would have to be amended to present the appropriate fields formatted in nice fashion. Since this probably uses a grid layout, it should be just a matter of not creating new rows in the grid.
I think there is a 3rd option: a connector _supports_ passwords but does not _require_ it, e.g. the password may be empty. That's the case for the ssh connector, and I believe others like telnet may also fall in that case. I would suggest the interface to be named supportsUserId() supportsPassword() instead of requires(). And I think that whenever a password is supported, it should be allowed to leave it empty -- i.e. empty password should always be a valid choice that can also be saved. Using the current dialog, but allowing to continue with empty password is in fact exactly what bug 147532 requests, and may be a first step towards better supporting connectors that have no concept of user and password.
Marking as [api] because Subsystems or Connectorservices will need properties or methods to return whether they need user id / password or not.
Thanks to the fix in bug 150929, it is now possible that a subsystem overrides ISubSystem.supportsUserId() == false When this is done, the user / password dialog will not come up on connecting, so this is the first part of the solution. Next part will be to allow subsystems (or connector services?) to specify that * user id is supported, but no password is supported * user and password is supported, but the password may be empty This could be done by declaring API in boolean ISubSystem.supportsPassword() boolean ISubSystem.supportsPasswordEmpty() But perhaps the API could be simplified, since supportsPasswordEmpty() REQURES supportsPassword(), and supportsPassword() REQUIRES supportsUserId().
Current state The supports* methods are done in SubsystemConfiguration. It has a supportsUserId() method. If specified it will prompt for userid/password. If a prompt is made, the password field is shown and it must not be empty when the prompt is finished. Summary of requirements There needs to be a way to suppress both password and userid (and thus the entire login prompt) There needs to be a way to specify that one or both of these are allowed to be prompted There needs to be a way to specify that one or both of these may be left empty on the prompt If it is valid to leave both empty then this subsystem supports purely anonymous login. New additions Without introducing a new type of "supports" mechanism, for example, one based on returned bit vectors the simplest API that supports these changes is something like this: supportsPassword() - defaults to true in SubSystemConfiguration. requiresPassword() - defaults to true in SubSystemConfiguration, ignored if supportsPassword is false. requiresUserID() - defaults to true in SubSystemConfiguration, ignored if supportsUserId is false. The connector service determines the login prompt state from the subsystem configuration of the primary subsystem - that is, the first subsystem registered for this system type that uses this connector service. AbstractConnectorService will use a slightly different prompt dialog that makes the userId and password fields (and their "save" checkboxes) optional.
Moved password/userid configuration from ISubSystemConfiguration to IConnectorService. Updated all subsystem configurations and connector services. Rewrote login dialog to make password or user id optional. Rewrote AbstractConnectorService.promptForPassword to take advantage of new configuration parameters.
I've tested all the scenarios I can think of using the daytime subsystem - supporting/not supporting passwords and user ids and saving/not saving passwords. They all seem to function correctly now. The DStore based implementations also work fine. SSH and FTP probably need some work to recover from authorization failures.
The "Enter Password" dialog is shown every time, when the stored password is empty. In case of implicit connect by expanding a node, when an empty password has been stored (e.g. because ssh public key authentication is used), the dialog should not be shown. Supposedly, the correct fix is to allow different handling for "null" and "empty" passwords, and to allow storing empty passwords persistently. In other words, when the password field is empty, the "store password" box should be enabled. Testcase: * Use Preferences > Team > CVS > SSH2 connection to setup ssh2 public key authentication * Connect to a server (enter correct user id, leave password empty) * Disconnect * Expand a filters node to reconnect --> No password dialog should be shown.
Fix added to allow an empty password to be saved (i.e. enable the checkbox on the prompt) if the connector service does not require a password.
with I20061102-1200 I can connect to SSH using an empty password, but the password dialog does not let me save the (empty) password; the "Save password" checkbox is disabled. Every time I Disconnect/Connect I get the password dialog again.
Bug 158756 covers not being able to tick the "save password" box for an emtpy password. I verified, however, that the functionality is there. Thus closing.
[target cleanup] 1.0 M4 was the original target milestone for this bug
