Allow null cipher name to fix collection assignment

[xjohnyknox]

Summary

When a cipher is created without a name (e.g. via alternative clients like Keyguard), assigning it to a collection via the web vault fails with:

Data guard `Json < ShareSelectedCipherData >` failed: Parse("...", Error("invalid type: null, expected a string", line: 1, column: 213))

The root cause is that CipherData.name is typed as String, so serde rejects null during deserialization — causing the entire request (including the collection assignment) to fail.

Changes

• Changed CipherData.name from String to Option<String>
• All usages default to an empty string via unwrap_or_default(), keeping the Cipher model and DB schema unchanged

This follows the same pattern already used by other optional fields in CipherData (e.g. notes, key, fields).

Test plan

• Create a cipher without a name via an alternative client or direct API call
• Verify the cipher can be assigned to a collection from the web vault without errors
• Verify normal cipher creation/update/sharing still works as expected

Fixes #6933

[stefan0xC]

Should this not be fixed in the API call to prevent ciphers from being saved if they are missing a required field?

[BlackDex]

Should this not be fixed in the API call to prevent ciphers from being saved if they are missing a required field?

That is what i think too.

[xjohnyknox]

Good point, updated the approach. Now instead of silently accepting null names, all cipher creation and update paths validate that name is present and return a 400 error ("Cipher Name field is required") if it's missing. This prevents malformed ciphers from being saved in the first place.

[BlackDex]

I think this PR is not needed, and you are (Or maybe AI is) only making it worse by making name an Option from my point of view.
I just tested it via a Python client by setting name as None or null in JSON, and that is blocked by the server.

The server already doesn't accept empty cipher names, so nothing needs to be fixed here.

There was a period where we did not verified this correctly, and during that period those items slipped through, and I really do not hope that KeyGuard still allows to create ciphers without a name, if so, then i think it's better that @AChep would resolve that issue on the client-side too.

So the only issue is that there might be some leftover vault items which do not have a name, and that the server panics on that is ok i think. The user needs to update the cipher so that it will have a name, and that should fix it.

I'm planning on closing this ticket, unless someone has other ideas on what to do with this?

[AChep]

Added a fix on my end, thanks @BlackDex for mentioning me!

[BlackDex]

@AChep no problem!

I also tested this with a Bitwarden server, and it also does not accept a a cipher without a name.
I'm not saying that we could improve on some error messages maybe. But that takes a bit more coding to be done and catching Rocket errors, since that is what currently error's out because there is no Name provided.

And, as long as we do not except it, that should prevent any future issues :)
Therefor, I'm going to close this PR.

But thanks for mentioning it and providing a possible solution!