-
Notifications
You must be signed in to change notification settings - Fork 80
Rewrite to allow matches from multiple stores #239
Rewrite to allow matches from multiple stores #239
Conversation
erayd
commented
Mar 27, 2018
•
edited
Loading
edited
- Rewrite the multiple-store feature to allow files with the same name in different stores
- Add dynamic number of stores
- Rewrite options screen
- Add styling to login entries when multiple stores are enabled
- Various other minor improvements.
@maximbaz Worth clarifying, because this may not be obvious - the browser extension in this branch is backwards-compatible with the current release version of the host app. There are no breaking changes. |
There's also something in this PR which is causing Firefox to occasionally display a horizontal scrollbar. It's not the |
Firefox scroll issues sorted. |
This looks really nice! I particularly like that the label is not displayed when only one password store is configured. |
chrome/options.browserify.js
Outdated
}, | ||
customStore: { | ||
title: "Custom password store locations", | ||
value: [{name: "one", enabled: true, name: "fish", path: "/home/fish"}], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This default entry "fish" is confusing, the first time I saw it I toggled the checkbox twice, closed, and browserpass started showing me error Error: lstat /home/fish: no such file or directory
. I will change this line to this if you don't have objections - the placeholders explain well what needs to be entered where:
value: [{enabled: true, name: "", path: ""}]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops - that was a leftover test value. I've just nuked it. Thanks for picking it up :-).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(To clarify - the default is supposed to be an empty array; it doesn't need to contain a value).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried a few options before writing that comment, and actually I found it quite pleasant for the eye to have one empty line pre-created, only without any hardcoded values 😉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense - I've added your suggested default in f686716.
pass/disk.go
Outdated
@@ -109,11 +114,11 @@ func (s *diskStore) GlobSearch(query string) ([]string, error) { | |||
|
|||
for i, match := range allMatches { | |||
// TODO this does not handle identical file names in multiple s.paths |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now you can remove the TODO, here and below in Open
🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
@@ -14,46 +14,51 @@ import ( | |||
sfuzzy "github.com/sahilm/fuzzy" | |||
) | |||
|
|||
// StoreDefinition defines a password store object | |||
type StoreDefinition struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please also adjust pass/disk_test.go
for these changes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. I just need to figure out what needs doing - I don't work much with Go, so I'm a bit slow with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can fix the tests myself after merging too, that's not a big deal 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That works too :-). If you're happy to do that, I would definitely prefer it - you are likely to pick up things in testing that I may miss due to my lack of familarity.
browserpass.go
Outdated
UseFuzzy bool `json:"use_fuzzy_search"` | ||
Paths []string `json:"paths"` | ||
UseFuzzy bool `json:"use_fuzzy_search"` | ||
CustomStore []pass.StoreDefinition `json:"customStore"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we maybe call it in plural?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you clarify what you mean by "call it in plural" please? I'm not sure what you are asking me to do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry, I meant name it "CustomStores" 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for clarifying - done :-).
@@ -47,6 +49,18 @@ type msg struct { | |||
Entry string `json:"entry"` | |||
} | |||
|
|||
func SendError(err error, stdout io.Writer) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My special THANK YOU for this!
I'm going to separately test this more, but what is your opinion on this as a fix for #164? I personally want to see errors logged and reported back to the extension, this code already sends the message back and logs it to stdout, I would only add logging to a file too (not necessarily in this PR). Anything you would additionally want for better error reporting?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My special THANK YOU for this!
You're most welcome :-).
I think this goes partway to addressing #164, but I don't consider it a full fix.
I added it because I needed a way to get error info out of the host app while I was debugging it, and figured I'd do so in a way that was more generally useful. So it helps - but I don't think that #164 should be closed because of it. I suspect there's still a fair bit of error information that may not be caught.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Besides, my way of doing it here is a little messy ;-). Anything that's returned as a raw string is considered an error. In the longer term, I'd like to see the return message standardised properly, and include a status code. But I couldn't do that without breaking backwards-compatibility, hence the string thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had that idea too, but then I saw your approach with strings and I thought that perhaps this is actually fine, we can log more details in the log file (detailed messages, error code, etc), and have the extension receive just a string error. That way we don't break compatibility, and it's easy to add to ISSUE_TEMPLATE an ask to print the last 100 lines from /var/log/browserpass.log
🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not really fine in the longer term though, because at the moment we can't change much functionality-wise without breaking stuff (and besides, co-opting the entire string
datatype for errors isn't very nice, because nobody can use it for anything else). Switching to a consistent and extensible message format will allow much more scope to add functionality without requiring a host app update every time we do something significant.
I don't think this PR is the right place for such a change, but IMO it definitely needs to happen at some point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, and I will update the ticket with your comment :)