If your use case requires a precise algorithm, you need to create a custom profile that disables the default policy.
In this context, would you mind clarifying who “you” is? Will individual users have the ability to override defaults in this way, or is this written for developers, or for enterprise admins, or MSPs? I ask, because I recall being disappointed that the recently implemented functionality to customize the generator’s minimum length limits were not made available to individual users.
Will there be any screenshots or mockups published (or beta testing opportunites??) before the overall design is finalized?
This is a technical design, and it’s largely complete. There should be no user-visible changes besides increased stability and consistency.
Will individual users have the ability to override defaults in this way, or is this written for developers, or for enterprise admins, or MSPs?
The audience of the generator deep dive docs are developers and technically-oriented community members. I’ve updated my previous post to make this more clear.
The short answer to your question is that the “who” is a programmer. The short answer is pretty useless, unfortunately, because who isn’t as important as what.
A profile lets part of the application decide how its generator works. They’re not user-visible; they basically just label part of Bitwarden that has specialized credential generation requirements.
The deep dive gives those programmers the tools they need to use the generator, including how to override the profile. Here’s some examples:
There are other places the generator is used—device login, for example—where we never want to apply an enterprise policy. This system lets those use-cases opt out.
Prior to the merge, the generator system didn’t enforce policy. Each caller enforced their policy, and so we had policy implemented all over the place. The new design encapsulates policy enforcement in the CredentialGeneratorService and surfaces policy through GeneratorMetadata. It starts with an application-defined policy outlining what Bitwarden supports. This is augmented by an “enterprise” policy defined in the admin console (when your subscription supports it).
Callers with specialized policy requirements can decide which enterprise policy (if any) applies to their usage. That lets the admin console use stricter policies than we would for the generator at large. It also lets the solutions like device login omit an enterprise policy and instead rely fully on an application-defined policy that is too strict for general password generation.
The PR I mentioned is entirely technical, and the deep dives are for technical users. I mentioned them both here since there’s often a lot of deeply nerdy folks that want to know more. I wanted them to know where to find all of the nitty gritty bits, since I’m usually one of them.
Thanks for clarifying that the quoted passage was addressed to developers who are contributing to the Bitwarden codebase.
Actually, your short answer was sufficient for me, in that I now know that the quoted passage was not relevant to me, personally. I do consider myself a “technical” (and even “nerdy”) user — to borrow your words — and I do have programming experience, but the Bitwarden codebase and the C#/TS/Rust languages used therein are beyond my current expertise. The deep dive docs are written for Bitwarden code contributors, not so much for technically-minded end-users.
Nonetheless, it was interesting to get a glimpse of what goes on behind the scenes. And any efforts to de-spaghettify the codebase are appreciated, as that benefits developers and end-users alike.
The deep dive docs are written for Bitwarden code contributors, not so much for technically-minded end-users.
Just to be clear, I’m writing the generator deep dives for both technical users and contributors. When I say “technical user”, I’m referring to the kind of person that reads LWN’s LKML articles even though they’ll probably never code the Linux kernel, or Niko’s blog even though they won’t be a rust compiler author.
(Hi. I’m talking about me. My interests have turned to LLMs and electronics, but I’m sure there’s folks that are like me 10 years ago. )
IS there any way that when you sign up for a new Account on a Website and it prompts for to generate the password, but in the format selected in the Generator Tab of the Extension. I have Passphrase (3 & .) selected yet if I sing up with the suggested password I get a load of random char and Symbols, Which is the default generator “Password” setting. Rather than the PassPharse setting.
@mad4x4 I moved your post into this thread on the same general topic – though it was originally about the context menu generator, but (as you can see above) the inline autofill generator experienced a similar issue (which you describe) and that was discussed here also… though I’m not sure, if we ever got some confirmation from @audreyality if the inline autofill menu suffers from “the same bug” - and if it will get fixed (soon)…
The inline autofill and context menu are related to each other. Both should be fixed at the same time.
Autofill is one of a few consumers that are presently using the legacy generator. We have upgrades tracked on the backlogs of all remaining consumers of that interface, and are coordinating with those teams to upgrade our clients to use the credential generation framework. I’m a strong advocate from eliminating legacy code, so it’s a personal priority of mine to get everyone ported.
I have selected “Passphrase” in my Firefox Bitwarden extension’s “Generator” tab, and I want to use those passphrase settings for any autofill suggestion for a new password. When I click in a password field, it only suggests generated Passwords.
I don’t know if I’ve changed anything on my side, but it used to suggest the passphrase using the configuration I had in the Generator.
Steps to reproduce:
Add the Bitwarden Firefox extension and sign in.
Click the Generator tab and specify 3 words, hyphens, caps, and numbers.
Navigate to a page that has a password field for a new user.
Click in the password field.
Observe: The suggested password is a password type, not a passphrase type.
This is the version information from my current installation:
PS: I updated the title of this thread to include the inline autofill menu. (from Context menu password generation ignores parameterstoCurrent bug: Context menu & inline autofill menu password generation ignore parameters)
)