D23384: [WIP] Adding support for mounting KIOFuse URLs for applications that don't use KIO

[Alexander Saoutkin]

feverfew added a comment.


  So before this patch we had the following behaviour:
  
  1. If app is KIO-enabled, pass URLs unchanged.
  2. else for each URL, if app claims to support the protocol pass the original URL, otherwise change the URL to the corresponding KIOExec path.
  
  This causes a problem as noted in 330192 <https://bugs.kde.org/show_bug.cgi?id=330192> and this blog post <https://pointieststick.com/2018/01/17/videos-on-samba-shares>. In particular, if a non-KIO claims to support a certain protocol (e.g., VLC supports smb), then we won't convert to a KIOExec path, but we strip out the stuff that's in `userInfo()` (credentials) before sending it over.
  
  What I previously tried to do was the following, in an attempt to close:
  
  1. If app is KIO-enabled, pass URLs unchanged.
  2. else for each URL, if app claims to support the protocol **AND**  `userInfo()` is empty pass the original URL, otherwise change the URL to the corresponding KIOExec path.
  
  However, that doesn't really help as apparently even if, say, a samba share is password protected, at the point I'm checking the password in `resolveURLs()` or `resultingArguments()` (truth be told, I'm not sure which, if not both, codepaths are being hit in our current testing), `userInfo()` is always empty, so this optimisation isn't possible.
  
  So then one could just always direct non-KIO apps to use KIOFuse. Well that causes another problem, what about stuff like http(s)? It doesn't really make sense as a filesystem and we'd definitely like to forward it to the browser. So currently I can special case http/https. but is that the only one we want to special case?
  
  Ideally, I'd like to know if there is a place where `userInfo` is only empty when there is genuinely no user/pass combo needed to access the resource at the URL. If so, then it can actually be possible to use KIOFuse on apps that support a URL only if it needs to have credentials (which it won't have) such that 330192 can be closed, without needing any hacks.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D23384

To: feverfew, fvogt, davidedmundson, dfaure, ngraham
Cc: broulik, sitter, davidedmundson, kde-frameworks-devel, ngraham, LeGast00n, GB_2, michaelh, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20191203/fa37799f/attachment.html>