Improve the interface mechanism
Current situation
The interfaces have been added to Manager v0.16.0 to handle Gateway local servers. This added a level of indirection which makes some new features possible. For example: an R66 partner cans be TLS or Clear only, the choice between TLS and Clear is not hard-coded in the flow templates, etc.
However, one can not that it is not optimal:
- Some partner types do not use interfaces, and the code must handle these cases separately
- For some partners, the interfaces are not visible (ex: R66)
- It is impossible to define the interfaces while creating the partners. Interfaces are generated using some conventions by the backend when the partner is saved in database.
- It is not possible to edit the interfaces for any type but Gateway
- One cannot go to the edit page to edit a Gateway's interfaces, but to the view page
In addition to that, the workflow to edit the interfaces after the creation of a Gateway partner is cumbersome, as it needs two steps: 1. create the partner, and save it, and 2. edit the pre-saved interfaces.
This proposal
This issue makes several proposals to improve the situation, which can be implemented separately and track their progress.
-
All the partners must be backed by interfaces. Independently of their type, the processing of all partners should be unified with the use of interfaces, even if they have just a single one. The code handling specific cases should then be removed.
A migration should create interfaces for all partners that do not have any.
-
There should be a verification for the match between a partner type and interfaces protocol. This is so to prevent defining an interface that is not supported by an application.
Valid possibilities are:
Proto R66 Gateway Gateway FTP Gateway SFTP SFTP FTP HTTP R66 ☑ ☑ ☑ ☑ R66TLS ☑ ☑ ☑ ☑ SFTP ☑ ☑ ☑ FTP ☑ ☑ ☑ FTPS ☑ ☑ ☑ HTTP ☑ ☑ HTTPS ☑ ☑ -
All the protocol-specific data must be stored in the interface. All the properties must then be removed from the partner model.
-
Protocol-specific data must be validated when the interface is validated. This is especially true for the presence of required properties (ex: passwords for the r66 protocol), the values that must be in a closed-list (ex: authent mode), and the values with a specific format (ex: SSH keys).
-
Interfaces must be visible for all partners, not just Gateways
-
In the UI, Interfaces should be renamed from "Local servers". This name has meaning only for Gateways, and can be misleading (a partner with only client interfaces has no "Local Servers").
-
The interface definition should be in the new/edit page, instead of the view page. With this, one can click edit to edit interfaces, and the actual interfaces can be defined while creating the partner.
-
When a new partner is created, the list of interfaces in the form is pre-populated with default interfaces that the user can edit.
The list of default interfaces depends on the type (one for each supported protocol listed above, with the secure version having precedence)
-
When the partner form is saved, it must save partner data AND interfaces all together.
-
The partner view page should only show existing interfaces. Edition is not possible on this page.
-
In the interface setting, the protocol must be chosen in a dropdown, so that the user cannot write unsupported or inexistant protocols. The list should respect the valid pairings between partner types and protocols.
-
The interface definition should allow the user to choose the authentication mode: password and/or ssh key for SFTP, etc.
I've uploaded a few design of the new form page (these are just mockups). Note that
- The save button has disappeared from the interface definition tab. The action to add an interface is missing though from the image and must be included.
- The user tab can or cannot be here, this is up for discussion
- the detail tab is highly simplified, since most of its data is now in the interfaces tab