Add support for customizable entry layouts

[gagarine]

I'm using https://play.google.com/store/apps/details?id=keepass2android.keepass2android&hl=en on android (sync via dropbox).

Keepass2android let me add entry using template (Standard entry, Credit Card, Secure Note, ...). Those template are recognized by keepassxc for added entry and are listed in the folder "template", but I can't use them to create a new entry from keepassxc.

[droidmonkey]

Nice suggestion. What benefits do the templates give?

[gagarine]

Template are a feature of keepass DB that let you quickly use custom field when you create a new entry: http://keepass.info/help/v2/dbsettings.html#templates

Keepass2android add some default template for you and then let you choose witch template to use when you add a new entry:

Standard:

Custom secure note:

Credit cart:

[droidmonkey]

I see, so it just populates attribute fields, but with a fancy gui presentation. Not a bad idea!

[gagarine]

Exactly :). Template are stored in the /template folder in the database. So in my opinion their is two features:

• be able to create new entry based on template stored in the template folder, and propose a fancy GUI for the attributes fields ;).
• add some "default" template in this folder. In the android application this function is in the settings "create default templates".

[andyleejordan]

I just switched over from LastPass to KeePassXC (having using KeePass many years ago), and would love to have templates again. I have a lot that migrated into plain entries with the notes field populated, so I have the info, but it's not very pretty.

[ckotte]

I would like to switch from 1Password to KeePassXC (and Keepass2Android), but unfortunately there are some nice features missing like multiple URLs, custom attributes/templates used across different implementations (i.e. KeePassXC, Keepass2Android, and Tusk browser add-on), or custom attributes in main view.

This feature as well as #1177 would make KeePassXC more advanced like 1Password or LastPass. Are there any news about a possible implementation?

[droidmonkey]

Some features you mention are limited by the KeePass standard (multiple URL's for one). Also, we do not control any other project's implementations (KeePass2Android/Tusk/etc). There are plans, but everything takes time/people/etc.

[ckotte]

Some features you mention are limited by the KeePass standard (multiple URL's for one). Also, we do not control any other project's implementations (KeePass2Android/Tusk/etc).

Is the KeePass 2.x version for Windows the current "KeePass standard"? I assume you will likely implement new features introduced in this version instead of introducing features that break the "KeePass standard", right?

It would be nice if there could be some kind of coordinated improvement across all the different implementations to have a more common "feature set" across different platforms..

[boweeb]

FWIW, at least KeeWeb, MacPass, KyPass, and even KeePass 2.x itself all implement the "Templates" group pattern. They basically all work the same as @gagarine described in keepass2android except for the creation of default templates (which I think is a neat idea).

[TheZ3ro]

Can someone link/post an example of a template's code?

[phoerious]

It's just a meta data element that says which group contains the templates. It's shortly described in our new KeePass2 XML spec https://github.com/keepassxreboot/keepassxc-specs/blob/master/kdbx-xml/rfc.txt

[TheZ3ro]

I know about that metadata key and the group.

A template is a normal KeePass entry with all required data already entered.

This is what I was asking 😆

[ghost]

Well +1 for this whenever it drops, sadly back to vanilla KeePass that already has the functionality via a plugin.
I imagine EPIC means in a couple years perhaps? Haven't taken a look at a roadmap if any, so just assuming.

What baffles me is if KeePass from the ground was never intended as an alternative to commercial apps? Because to me it seems obvious you wanna store Credit Cards, Router, Bank Account info etc and not all of those conform to "user, password, url" schema. And the top commercial apps have had this for years now. Which is when I migrated my info from 1Password to KeePass 2.x I was baffled to have so many fields gone or in short categories like Credit Cards completely unusable.

[navin09]

+1

I'm missing this feature from Keepass.

[droidmonkey]

This is my next major effort.

[adelphi23]

Newbie here, so apologies in advance if this has been addressed already.
I'm trying to migrate from 1password to keepassxc, so I am facing the same issues raised above bey TehPsychdelic and others. In my case, I am moving my 1200+ entries manually and want to avoid having to do double work. As of Nov/18, Is it possible to create and/or import templates? I started creating my own templates based on 1Password fields, but am afraid that after all the work I would find out that a set of standard templates was implemented and/or will be implemented. An alternative would be to import templates from keepass, but I don't know whether this is feasible and whether keepassxc will keep that template set instead of creating a new one. Any hint would be mostly welcome.

[droidmonkey]

No form of templates is currently supported by KeePassXC.

[adelphi23]

Thanks for the prompt reply!

[MichaelYochpaz]

Any plans of adding templates soon?
Would be very usefull

[droidmonkey]

Slated for 2.5

[strongbox-mark]

HI @varjolintu / @J-Jamet - Would be cool to align on this... In particular as I mentioned in #7097 - If we could really narrow the scope of this issue down I think it would make all of our lives easier. From the Strongbox side I was think it would be good to have something like:

• A custom attribute on an entry indicating what "type" of entry it was
• A well known collection of types (e.g. Credit Card, Secure Note, Identity/Address) - So, "type" = "credit-card"
• For each type a collection of well known/conventional custom fields. e.g. Credit Card type has "name", "number", "cvv", "expiry"

I think by keeping things pretty simple we could make a lot of progress. We could agree on the well known types, their well known field names and formats.

Would you be interested in this? Is there somewhere else I should raise or chat about this with you? Would like to align on this for improving UX and AutoFill functionality.

[varjolintu]

@strongbox-mark Also check out keepassxreboot/keepassxc-browser#1614 where I just made some testing about a possible implementation and used a certain attributes. Although those are now set as KPH attributes, maybe we should need a common prefix/standard for all KeePass clients.

[strongbox-mark]

That looks good! I don't mind about the prefix, happy to use KPH in Strongbox, similar to using KP2A_URL*... As long as we have a convention then we're fine... What does the "H" stand for in KPH anyway :) ?

For the values we should come up with a way of specifying what is valid, e.g. what it should look like. e.g.

"KPH: CC_EXP" = "MM/YYYY" - This would cover any expiry I think?

Similarly I would have questions about "CC_TYPE" - This should be "Mastercard|Visa|AMEX"?

Also, you might want a "Billing Address" = "123 My Street, Awesome Land, Earth".

But this seems like a nice lightweight (perhaps interim) solution to templates, rather than the fully fledged system discussed above. If we can get Credit Cards/Secure Note types then I think a lot of people will be pretty happy with that.

If you like I'd be happy to work with you in the other issue, or in a conversation, Google Doc, or wherever suits if this isn't the ideal location.

[varjolintu]

@strongbox-mark I'm in favor of KP2A_ kind of prefixes instead of KPH ones (which are for special cases anyway). Not sure what the H means here.

Another thing about credit card entries is how they're meant to be accessed by the user? Maybe the Credit Card entries would need a separate group that is always exposed (e.g. to browser extension) and a separate permission is asked to access it (per site). Using a specific URL's for Credit Card entry/entries are not really a usable solution in my opinion. So even a "lightweigth" solution would need some changes how the entry is handled.

[droidmonkey]

I like this approach! The 'system' for this approach is documentation over code since it will be implemented by multiple parties. Need to clearly document:

• The default templates and their ids
• What data types and key names each template requires
• some form of input validation (try not to be too strict)

Then we can move to allow a 'custom' template spec like I wrote above, if necessary.

Some good default templates that would get us 99% there:

• Secure note (title and notes only)
• Credit Card (title, CC numbers, expiration)
• Entry with email (add an email field to the entry)
• identification (Title, name, person data fields, address, etc)

P.S. - the H stood for HTTP, the original plugin for browser integration 😉

[HealsCodes]

Just my 2ct on the usage of Credit Card special entries:

Most password managers don't auto fill those / have no "smart" way to provide auto-fill for them; so exposing that information to browser extensions at all times fells like it would make things a lot more complicated than the average user appreciates.

Entering Credit Card data isn't something you do an a daily basis - like account names / passwords,
having to open up keepass or strongbox to get at that data seems like a tenable trade-off.

Behaviour wise the things most users will need is the CC-number & CCV which could be mapped to the existing shortcuts for copy username and copy password, CC-expiry date could map to copy TOTP for ease of use - CCs don't have any of those fields but equivalents for each.

[P.S. great to see you guys cooperate on this - I'm using KeePassXC on Windows and Strongbox everywhere else]

[strongbox-mark]

P.S. - the H stood for HTTP, the original plugin for browser integration 😉

Interesting :)

OK, yes, what's the best way to cooperate on this? Do you have a preferred shared document editor we could use for these conventions? I like your 4 default templates and the idea of a lightweight low formality convention I think is best for our loosely assembled coalition :)

[J-Jamet]

I tried to reread the whole thread but I may have missed some information so don't hesitate if there are things I misunderstood, I'm just sharing my experience in implementing templates on the android application I'm working on.

I have already implemented the plugin code of KPEntryTemplates for backwards compatibility. But the format is really not great and not very flexible. So I created a simplest pseudo language to overload it while waiting a normalization of the templates. This discussion is a good thing for a new format.

@droidmonkey #863 (comment)

OK for using the templates in JSON in the custom data, but we need to harmonize the implementation of the fields to define each template dynamically.
Keeping the old solution of one template per entry with a special group gives the advantage of not having to redo UI and the user is already used to manage the entries (it's also so much easier for the backward compatibility).
So I had to raise this point, but if we all harmonize the format for a common UI to modify the templates, it's OK for me.
https://github.com/Kunzisoft/KeePassDX/wiki/Templates

@strongbox-mark

A custom attribute on an entry indicating what "type" of entry it was

So it corresponds to one template, so a type = a template instance implementation in your nomenclature. Tell me if I'm wrong.

For each type a collection of well known/conventional custom fields. e.g. Credit Card type has "name", "number", "cvv", "expiry"

I agree :). And this is the biggest part of the work because we have to make a pseudo language generic enough to accept the validations according to the types of fields.

I'm in favor of KP2A_ kind of prefixes instead of KPH ones (which are for special cases anyway). Not sure what the H means here.

I will clearly not put KP2A nor KPH.

• KP2A stands for keepass2Android, I have nothing against the app, on the contrary, but we need a generic nomenclature that everyone can use. We have already discussed the nomenclature for URLs and application names which has been modified accordingly. KDBX 5 Standard #4317 (comment)
• KPH : What does this have to do with templates and HTTP? I don't plan to put connection code to transfer protocols in templates, maybe I missed a discussion but the concepts should be well separated.

Another thing about credit card entries is how they're meant to be accessed by the user? Maybe the Credit Card entries would need a separate group that is always exposed (e.g. to browser extension) and a separate permission is asked to access it (per site). Using a specific URL's for Credit Card entry/entries are not really a usable solution in my opinion. So even a "lightweigth" solution would need some changes how the entry is handled.

Is this for you related to the template? Because for me, autofill is a completely separate concept, so it has nothing to do with formatting credit card data. The filling of credit cards into formatted entries with the Credit card / Debit card template already works on KeePassDX.
Recognition of external forms and URLs does not always work but the logic is in the autofill section and not in the templates. I'm just wondering how you see things.

The default templates and their ids
What data types and key names each template requires
some form of input validation (try not to be too strict)

I agree with all that

Some good default templates that would get us 99% there:

Secure note (title and notes only)
Credit Card (title, CC numbers, expiration)
Entry with email (add an email field to the entry)
identification (Title, name, person data fields, address, etc)

I agree with that too, either way it will be dynamic. We must not take away the possibility for the user to create his own templates, it would be a regression. And as it is possible for the user to create, modify or delete templates with the implementation of the old plugin, the default templates can be harmonized between applications but in my mind, it is rather secondary compared to the harmonisation of the field types and the creation of a standardized pseudo language for the fields.

The thing that makes me weird is that you talk about form recognition, http and template in this thread.
Credit cards are templates like any other and I don't see why there should be any special treatment for this type of entry. If tomorrow we want to recognize other types, there will be lots of special cases. Can you tell me what I did not understand in your discussions. :D

[droidmonkey]

Retaining any form of compatibility with the previous plugin is not on my radar. You are welcome to do that but the former method (which was prior to custom data existing) should not flavor the future. I would entertain a one way conversion of the former template format to the future one though. We did that for keepasshttp.

[J-Jamet]

Retaining any form of compatibility with the previous plugin is not on my radar. You are welcome to do that but the former method (which was prior to custom data existing) should not flavor the future. I would entertain a one way conversion of the former template format to the future one though. We did that for keepasshttp.

Yes I understand very well and compatibility is not an argument for this plugin. I just had to point it out even if it is to be discarded.
Also we need to keep in mind that the current system of templates without plugins already uses a specific group, so this is something to consider. Especially if the new method is the only one retained, perhaps it should be removed from the KeePass format.

I'm OK with JSON, but I was wondering why in favor of XML, the libraries were already built in.
In my mind, the XML schema / DTD would allow a simplified validation.

[strongbox-mark]

So it corresponds to one template, so a type = a template instance implementation in your nomenclature. Tell me if I'm wrong.

Yeah, I guess that's right. Perhaps "Template" is misleading. The way I see it, we need some kind of lightweight indicator that this entry is actually a "Credit Card" and this is a "Secure Note". To my mind, it's an entry "Type".

Following on from having a entry "Type" you can build 2 main features:

• GUI for displaying/editing these types nicely (hiding irrelevant fields, emphasizing important ones, e.g. emphasizing CVV/Expiry for Credit Card, or hiding "Email/username/URL" for a Secure Note)
• AutoFill functionality especially for Credit Cards becomes possible / easier if we know which entries are the Credit Cards and how to read the number/expiry/CVV

So, if you like, forget the word "Template" and consider this an entirely separate feature, one built to be lightweight and get us quick wins with popular "Types" for our users. I think @droidmonkey is concerned with the scope of this "Template" feature, as am I. This is an alternative, that should be easier to build and get us 80-90% of the way there for most users.

I'm OK with JSON, but I was wondering why in favor of XML, the libraries were already built in.
In my mind, the XML schema / DTD would allow a simplified validation.

There wouldn't be JSON/XML or anything like that in what I'm proposing, it's purely a convention that we would abide by - we could have it in a doc somewhere for reference. What we need is:

• A custom attribute for the entry "type"
• 4 default or conventional types = { Credit Card, Secure Note, Identity, Email }
• Set of conventional fields to be used for each of the above types

I will clearly not put KP2A nor KPH.

OK, cool, it can be absolutely anything, it's totally arbitrary i.e. a Convention :)

[J-Jamet]

Yeah, I guess that's right. Perhaps "Template" is misleading. The way I see it, we need some kind of lightweight indicator that this entry is actually a "Credit Card" and this is a "Secure Note". To my mind, it's an entry "Type".

OK, I'm doing the parallel with how the old plugin works:

• Old plugin: An entry has an additional UUID field that indicates which template (which was a special entry in the template group) is associated.
• New implementation: I imagine to bind an entry to a type that is defined in the JSON but you tell me that there is no JSON, that's where I don't understand.

GUI for displaying/editing these types nicely (hiding irrelevant fields, emphasizing important ones, e.g. emphasizing CVV/Expiry for Credit Card, or hiding "Email/username/URL" for a Secure Note)

The GUI is for me created dynamically according to the definition of each template (thus of each type). (But I understood later that you generate 4 static ones)

AutoFill functionality especially for Credit Cards becomes possible / easier if we know which entries are the Credit Cards and how to read the number/expiry/CVV

I don't understand why here, the entries will just contain data, not recognize the forms. This is the code of the autofill section that takes care of recognizing the forms. If there are custom fields that match those of a credit card in a normal entry whose type is not known, this should not prevent it from being offered in the autofill.

So, if you like, forget the word "Template" and consider this an entirely separate feature, one built to be lightweight and get us quick wins with popular "Types" for our users. I think @droidmonkey is concerned with the scope of this "Template" feature, as am I. This is an alternative, that should be easier to build and get us 80-90% of the way there for most users.

Okay, I understand better. You want to create 4 static templates and not dynamic ones.
In this case, it will not be possible to add or delete templates, or even fields in templates.
For me it's not scalable enough and it comes back to the basic problem of having one basic form in the KeePass format (but there will be several static ones) and we thought it would be enough.

Set of conventional fields to be used for each of the above types

There is no reason in my opinion to put prefixes at this level since the fields do not yet exist in the default format. Just put the common names that correspond to the fields and we all use the same between each app. This will be much more readable by other applications that have not implemented the static templates.

[strongbox-mark]

Okay, I understand better. You want to create 4 static templates and not dynamic ones.
In this case, it will not be possible to add or delete templates, or even fields in templates.
For me it's not scalable enough and it comes back to the basic problem of having one basic form in the KeePass format (but there will be several static ones) and we thought it would be enough.

Yes, that's correct. It's a more limited system which will give us quick wins and manageable changes. We can always add dynamics afterwards, following your lead :)

There is no reason in my opinion to put prefixes at this level since the fields do not yet exist in the default format. Just put the common names that correspond to the fields and we all use the same between each app. This will be much more readable by other applications that have not implemented the static templates.

Yes, absolutely, no need for prefixes on the fields. :) We just need the conventional names (e.g. "cvv", "expiry")

We do need an "attribute" to indicate the type, and we could use whatever prefix you would like for this, e.g.

KPEX_ENTRY_TYPE="Credit Card | Secure Note | ... "

[J-Jamet]

KPEX_ENTRY_TYPE="Credit Card | Secure Note | ... "

I see no problem with this nomenclature. (Maybe it's because I don't know what KPEX means :D)

[varjolintu]

I will clearly not put KP2A nor KPH.

KP2A stands for keepass2Android, I have nothing against the app, on the contrary, but we need a generic nomenclature that everyone can use. We have already discussed the nomenclature for URLs and application names which has been modified accordingly. KDBX 5 Standard #4317 (comment)

What I meant here is directly what was written above: I'd prefer some kind of prefix (if it's KPEX for KeePass EXtended/EXtension etc..) to distinquish the attributes from the ones user could possibly add.

Is this for you related to the template? Because for me, autofill is a completely separate concept, so it has nothing to do >with formatting credit card data. The filling of credit cards into formatted entries with the Credit card / Debit card template >already works on KeePassDX.
Recognition of external forms and URLs does not always work but the logic is in the autofill section and not in the templates. I'm just wondering how you see things.

Here I'm purely thinking this from the browser extension side. Credit card data is something that we shouldn't give access without any confirmation. And matching certain entry is done using the URL. With Credit Card templates this doesn't really suit for the methods the data is meant to be used. My current idea for any template data concerning browser extension and 3rd party clients using the same API is that template entries can be accessed without URL matching, but they need a separate permission per site, which user has to confirm manually. This of course is out of scope how the template data itself is stored to the database :)

[strongbox-mark]

I see no problem with this nomenclature. (Maybe it's because I don't know what KPEX means :D)

What I meant here is directly what was written above: I'd prefer some kind of prefix (if it's KPEX for KeePass EXtended/EXtension etc..)

Yes, sorry, KPEX was meant to suggest KeePass "Extended" or "Extension"

to distinquish the attributes from the ones user could possibly add.

The attirbute would not be a Custom Field, but part of the "Custom Data" on an entry (I'm not sure if users can add to this? We don't allow it on the Strongbox side). I thought it was purely for developers/plugin authors?

e.g.

<CustomData>
   <Item>
       <Key>KPEX_ENTRY_TYPE</Key>
       <Value>CreditCard</Value>
   </Item>
</CustomData>

[varjolintu]

The attirbute would not be a Custom Field, but part of the "Custom Data" on an entry (I'm not sure if users can add to this? We don't allow it on the Strongbox side). I thought it was purely for developers/plugin authors?

At least in KeePassXC you cannot add to Custom Data but you can view and delete browser extension related data from it. We should make clear are we talking custom Attributes or Custom Data here :) The values can still be edited by users, so in that case it doesn't matter where those are?

[droidmonkey]

The JSON format above only applies to custom templates (future capability). I am very much not in favor of re using groups and entries to handle features. It was a bad choice in the past (AutoOpen, KeeShare, Templates, etc) and creates "reserved" names and meanings that are hard to manage.

CustomData should be used to maximum extent possible. What goes in that data is up for debate, I prefer JSON for simplicity.

We should NOT be using custom data to store the values of attributes (ie user data). CustomData is only meant for plugin data (as mark pointed out, use it to store the type of template that should be applied). User data should be in (what we call) advanced attributes with a common prefix.

[strongbox-mark]

The JSON format above only applies to custom templates (future capability). I am very much not in favor of re using groups and entries to handle features. It was a bad choice in the past (AutoOpen, KeeShare, Templates, etc) and creates "reserved" names and meanings that are hard to manage.

Totally agree.

Yes, sorry, I think what you guys call "Attributes" we call "Custom Fields" in Strongbox :) I believe, "Custom Data" is the right place for this single entry "type".

Should we break out a new issue for this, and keep this issue for the original giant fully featured "Templating" system?

[J-Jamet]

What I meant here is directly what was written above: I'd prefer some kind of prefix (if it's KPEX for KeePass EXtended/EXtension etc..) to distinquish the attributes from the ones user could possibly add.

I don't understand how it's useful if it's in a custom field. If the user wants to enter multiple credit card numbers for the same entry, it won't happen often, he will use another custom field name (or a [_N] suffix). Not a big deal.

The JSON format above only applies to custom templates (future capability). I am very much not in favor of re using groups and entries to handle features. It was a bad choice in the past (AutoOpen, KeeShare, Templates, etc) and creates "reserved" names and meanings that are hard to manage.

Also agree with this, but we will have to inform every KeePass dev and convince Dominik. Otherwise there will be other keepass format differences.

Should we break out a new issue for this, and keep this issue for the original giant fully featured "Templating" system?

Another discussion would be clearer in my opinion but you do as you wish.

[varjolintu]

I don't understand how it's useful if it's in a custom field. If the user wants to enter multiple credit card numbers for the same entry, it won't happen often, he will use another custom field name (or a [_N] suffix). Not a big deal.

Seems we agree about this :) Maybe I wasn't clear enough in my comments.

[droidmonkey]

Concur we separate the "default" template discussion into a new issue request (I'll do that) and leave this one for fully custom templates.

[droidmonkey]

Let's continue the conversation on default templates here: #8228