Closed rnkn closed 4 years ago
Hi,
thanks for the issue. The behaviour, however, is actually a bug :D
So in short how the search works is to find (in your case) the string myaccount.myvodafone.com.au
.
If there is not match, I assume that there is no password for the subdomain myaccount
, so I strip away ALL subdomain and search for myvodafone.com.au
.
And there is the bug.
I did not think of the cases, where the TLD consists of two parts (i.e. second-level-domains).
So, in you case, instead of searching for myvodafone.com.au
Pass for macOS searches for com.au
.
That's unfortunate, sorry for the inconvenience.
I will fix this ASAP.
However, I'm not sure how. The reason, why I do this two-step process is to first try to get an exact match. But if the first run is not successful, I want a second run to get all possible results and thats it. My fear is, that if the password store has a lot entries, the search will take too lange if there are more than two passes. Using your approach, however, would likely be the solution with better search results, but could take longer.
So, I will try to implement a hybrid version.
I will search through the files once and get all possible results in an array (e.g. all with .com.au
or .de
or something).
And then I will use this array to refine the search result.
So, in germany, we have 4 days off due to easter. I wondered, how I will spend the days while corona. Here is the answer :D
Thanks for the quick reply!
I'm not a Swift programmer, but I think this is how I would go about it in the abstract sense (which might be terrible 🤷♂️)...
With the password list as oldResults
first split and reverse your query string by the dot so you get something like
["au", "com", "myvodafone", "myaccount"]
Then do the loop:
Pop the first of this array as searchComponent
and join by "\."
with regexp ".*?"
to get ".*?\.au$"
and return the matches as say newResults
.
Then if length of newResults
is 0, there's no match so return oldResults
.
Or else if the length of newResults
is 1, you have a match.
Or else set oldResults
to newResults
and do the loop again (e.g. pop the next of the array and join/concat with searchComponent
as ".*?\.com\.au$"
, etc.)
This would eventually either give the exact match, or the closest in DNS-style. But, this is just off the top of my head...
I later realise the above method will pose the problem of returning a false match, e.g. if searching for vodafone.com.au
and if there is a single password for example.au
.
Fixed in e0c890cbc2bb19525f8417c8324807b32b78af2b
See commit message for more information.
Cool! Works perfectly, thanks!
Summary
Ordering password results by the domain's rear component, e.g. for URL
https://myaccount.myvodafone.com.au
the first result I get iscitibank.com.au
andmyvodafone.com.au
is fifth. Ordering by rear-component I think would improve this.Motivation
I think you'd get more accurate results splitting the string by the dot and using DNS-style rear-first matching, i.e.
au
thencom
thenmyvodafone
. This would improve URL result ordering without affecting passwords not named by URL, e.g.restic-backup
.Is your feature request related to a problem? Please describe.
As above.
Describe alternatives you've considered
Presently just scrolling down to select the correct result.
Additional context