Cyberduck Mountain Duck CLI

Changes between Initial Version and Version 1 of Ticket #9073


Ignore:
Timestamp:
Oct 27, 2015 8:57:00 AM (5 years ago)
Author:
rok
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #9073

    • Property Type changed from enhancement to defect
  • Ticket #9073 – Description

    initial v1  
    1 In Mountain Duck the BasicAuth header is being sent on first try unlike on Cyberduck, where it tries to login anonymously. So if for an instance you decide to return 403 forbidden error on server in case a user tries to access WebDAV through HTTP it simply aborts the login process in Cyberduck and the user credentials are not being sent. However that is not the case with Mountain duck. I do notice that it warns the user about sending username and password in plain text, but there could be another layer of security that at first tries to connect to server over HTTP and if it gets Forbidden or some sort of an error that it displays it to the user, instead of blindly sending the BasicAuth credentials.
     1In Mountain Duck (and Cyberduck) upon authentication if username and password is given before first request it will automatically try to send the Authorization BasicAuth header on first request. The problem is that if the protocol chosen is HTTP it will send the username and password unprotected on first try. There is no way to protect the user on server side to prevent user credentials from leaking. For example WebDAVFS - Native Mac OSX WebDAV client (and probably davfs) fix this by sending OPTIONS request first and then based on response adjust the settings or show a warning. If for example client gets 301 response to HTTPS, it changes the url to HTTPS and remembers it for next requests. On Cyberduck or Mountain duck this is not the case and every single request first gets sent over HTTP and later after 301 redirect to HTTPS it tries to send it over HTTPS.
     2
     3So what would needed to be done:
     4 - make Mountain duck and Cyberduck first try to send OPTIONS request and acknowledge if the response is 301 (redirect) to HTTPS
     5 - make sure to remember HTTPS or other address if 301 was given to that protocol for next requests
     6 - If 403 (forbidden) was return after first OPTIONS packet, meaning server doesn't allow HTTP connection it should maybe somehow warn the user, but most importantly not allow the client to send user credentials.
     7
     8Mainly it should be possible to protect user credentials by settings on server end side like forbidding access over HTTP or redirecting them to secure connection, without leaking the user credentials.