browserpass
Password templates
The interface is bad, but it's a lot more usable than not having it.
Didn't test on Chrome — will be glad if someone tries it.
Interesting idea! @erayd @patgmiller what are your thoughts on this?
When you say "interface is bad", do you mean the experience of defining such option in the config?
Falling back %container% to username feels unnatural to me, maybe we should just leave it empty? :thinking:
Should we add another placeholder for TLD of the current hostname, i.e. when you are on account.example.com to save it as example.com?
Not sure that we need %user% placeholder altogether - if you defined it in the extension, it's likely because you don't want to define it anywhere in your password store? :thinking:
When you say "interface is bad", do you mean the experience of defining such option in the config?
I mean that I don't like how the explanation in <p> turned out looking, but I kind of wanted to push already, since otherwise I might have just continued sitting on it)
Should we add another placeholder for TLD of the current hostname, i.e. when you are on account.example.com to save it as example.com?
Sounds good. I do think however it's easier to delete than to type.
Falling back
%container%to username feels unnatural to me, maybe we should just leave it empty? 🤔
Oh, I actually wanted to default to %host% — I myself use %container%/%host%, but I doubt that containers are that popular
Not sure that we need %user% placeholder altogether
There is no %user% placeholder — I just use username field as a default if %container% is used and missing
E.g I use identity/site structure of my password store, and my default identity is cab/. But I also have work-related ones.
There is no %user% placeholder — I just use username field as a default if %container% is used and missing
Yeah that's what I meant it felt unusual / unexpected for me, why of all the things the fallback is to username, but I see now that you and me just have different things that we express with containers 😅 In any case it's not going to affect you, but I think it's better to not fall back to anything on missing value, let it be missing.
E.g I use identity/site structure of my password store, and my default identity is cab/. But I also have work-related ones.
By the way you might want to try using multiple password stores for this, you get some colors too and it's kinda nicely follows your structure.
By the way you might want to try using multiple password stores for this, you get some colors too and it's kinda nicely follows your structure.
Multiple password stores as in having multiple separate repositories? That sounds like a lot of hassle when you set up a temporary identity, given you'll have to set it up on all the other devices?
No you can just map your subfolders in browserpass to be treated as separate password stores, like this:
(could still be a lot of hassle, it's just an idea for you to consider)
No you can just map your subfolders in browserpass to be treated as separate password stores, like this:
(could still be a lot of hassle, it's just an idea for you to consider)
that does sound nicer that I thought, I'll try it out!
however I guess that will also require some sort of pairing with containers, so a correct store is chosen when creating a password
I agree and generally I have to say, it could be cool to support containers in more places - for example have frequency (usage history) respect container.
But let's take it one step at a time, try these custom containers and let me know how it goes and in what direction we should take this PR forward?
and immediately I want to add relative paths to stores and colors don't get auto randomized (and for some reason you need two) — so it's hard to add new ones
and you lose access to root entries (or get duplicated entries by adding root)
so, not that great so far(
Interesting idea! @erayd @patgmiller what are your thoughts on this?
I think the idea to allow / provide a personal default path to create secrets is interesting. However I don't think browserpass should set a default value for it. This is one of those things that is subjectively personal for the most part. To me it's like the "default username",
however it sounds like maybe with the "container/username/identity" case, the value is configured per store, while the "default username" is global; if that is the case it would require a little more work.
By the way you might want to try using multiple password stores for this, you get some colors too and it's kinda nicely follows your structure.
Multiple password stores as in having multiple separate repositories? That sounds like a lot of hassle when you set up a temporary identity, given you'll have to set it up on all the other devices?
I would say you don't have to setup multiple identities, unless it calls for it. However I understand the multiple repositories, the only hassle for me there is I'd like to have them all on my mobile device as well as my computers; and that's something I've been working towards for a while now. I have setup an extra repo to share passwords with my wife since I knew she wouldn't want / need all the files I have in mine.
Though I do think @maximbaz suggestion to add multiple paths is a simple solution as well.
Username as default value is indeed a bit cursed. However, since the default container is not named, I personally need an option to provide a name for it. But yes, it should be split into a separate option.
I guess at this point I only can say that our views on comfort are a bit different, and I will use my fork as daily driver
However, I can try cutting away at this PR if you want/need any features