1 Commits

Author	SHA1	Message	Date
Jared Snider	450159a1e2	Auth/PM-37166 - Devices - add client version (#7632) ... * PM-37166 - Add ClientVersion to Device entity and repository contract * PM-37166 - Add ClientVersion SQL schema and refactor bump stored procedures * PM-37166 - Implement combined bump in repositories and add EF migrations EF snapshot regeneration also absorbs Collection / CollectionGroup / CollectionUser namespace moves (Bit.Infrastructure.EntityFramework.Models -> Bit.Infrastructure.EntityFramework.AdminConsole.Models) that were left un-regenerated by PR #7523 (PM-35489). Namespace-only, no SQL impact; flagged with the AC team for awareness. * PM-37166 - Replace DeviceLastActivityCacheService with DeviceDataCacheService * PM-37166 - Replace BumpDeviceLastActivityDateCommand with BumpDeviceDataCommand * PM-37166 - Pass ClientVersion through identity request validators * PM-37166 - Align migration script with SQL style guide Refresh Device_ReadBy* sprocs after DeviceView change so their cached schema picks up ClientVersion, swap retired-sproc drops to DROP PROCEDURE IF EXISTS, and tighten the ALTER TABLE indent in step 1. * PM-37166 - Rename BumpData to UpdateLastActivity across device write pathway The "BumpData" naming was vague — "data" named a category, not the thing being written. Rename to "UpdateLastActivity" everywhere: SP, repositories, command, cache, validators, tests. "Last activity" names the event of the device's most recent appearance; LastActivityDate (when) and ClientVersion (what was running) are facts we observed about that event. ClientVersion is treated as a property of the activity event rather than an independent value, so future last-observed properties (last IP, OS, etc.) slot in without renaming. The SQL layer uses Update* per architect guidance on bitwarden/server#7302; the Bump* SPs in this codebase are legacy and not being extended. The extensibility note lives on IUpdateDeviceLastActivityCommand with short pointers from the SP, repo, and cache. Cache key prefix changes from device:data: to device:last-activity: — safe because the cache is only a write-suppression optimization (SP guards ensure correctness) and entries TTL out within 24h. Migration renamed to 2026-05-14 to reflect the rewrite. * PM-37166 - Add UTF-8 BOM to device last activity cache files Aligns file encoding with the repo's .editorconfig (charset = utf-8-bom for .cs) so dotnet format --verify-no-changes passes. * PM-37166 - Compare LastActivityDate at second precision in device creation test GetManyByUserIdWithDeviceAuth_ReturnsLastActivityDate_ForNewDeviceAsync was flaking on SqlServer: Dapper binds DateTime params as legacy `datetime` (~3.33ms granularity), so the entity initializer's UtcNow can be rounded a few ms earlier than the in-memory `beforeCreation` capture, making a strict >= comparison occasionally false. Truncate both sides to the second to absorb that drift while still rejecting stale or defaulted values. * PM-37166 - Rename Device.ClientVersion EF migration Renames migration class/files from AddDeviceClientVersionRefactorDeviceDataBump to AddDeviceClientVersion to drop stale "Bump" terminology and the misleading "RefactorDeviceData" prefix. The EF migration only adds the ClientVersion column; the BumpData -> UpdateLastActivity SP refactor lives in MSSQL .sql files and has no EF representation. * PM-37166 - Document null-is-no-op semantics for ClientVersion on IUpdateDeviceLastActivityCommand Tighten the interface-level summary and add a <param> note clarifying that a null clientVersion is treated as "no opinion" and will not clear an existing stored value. * PM-37166 - Regenerate Device.ClientVersion EF migration on post-#7634 baseline PR #7634 merged AddLastApiKeyRotationDateToUserTable into main while this branch was open. The prior AddDeviceClientVersion migration's frozen model snapshot (its .Designer.cs) was generated before that PR landed, so it did not include User.LastApiKeyRotationDate. Applying migrations incrementally against that stale snapshot would produce an inconsistent model graph. Regenerated AddDeviceClientVersion on top of the merged-from-main baseline so the new .Designer.cs files include both columns. The migration body itself still only adds Device.ClientVersion; the top-level DatabaseContextModelSnapshot.cs files were already correct from git's three-way merge. New timestamps (20260514192xxx) come after the User migration (20260514011xxx), preserving migration order. * PM-37166 - util/Migrator/DbScripts/2026-05-14_00_AddDeviceClientVersionAndUpdateLastActivitySp.sql - fix wrong comment * PM-37166 - Bump Device.ClientVersion column width from 20 to 43 43 is the upper bound of Version.ToString() for any input parseable by Version.TryParse — four Int32 components (Int32.MaxValue = 10 digits) joined by 3 dots. Sizing to the type's mathematical max prevents SQL Server error 8152 on malformed/hostile Bitwarden-Client-Version headers without paying the cost of normalization at the call sites. Real Bitwarden CalVer (YYYY.M.B) remains well within bounds at ~9 chars. - Device.cs [MaxLength] + entity doc comment - SSDT table + 4 stored procedures - Cloud migration ALTER TABLE + SP parameters - EF migrations regenerated for MySQL / Postgres / SQLite * PM-37166 - Defer dropping old single-column UpdateLastActivityDate SPs to follow-up Server and DB deploys are decoupled, so dropping the old SPs in the same migration that introduces the new combined ones would break server rollback. Per discussion on PR #7632: - Remove DROP PROCEDURE statements from the migration; replace with a note explaining the deferral. - Restore the old Device_UpdateLastActivityDate{ById,ByIdentifierUserId}.sql files in src/Sql/dbo so the SSDT source-of-truth stays aligned with deployed schema (EDD). A follow-up ticket will drop the old SPs and delete the .sql files together once we're confident no deployed server version still calls them. * PM-37166 - Pass @LastActivityDate into Device_UpdateLastActivity SPs Bitwarden convention is to compute timestamps in the application layer and pass them as DATETIME2(7) params, not call GETUTCDATE() inside SPs. Dapper repo now computes DateTime.UtcNow locally (matching the EF repo and UserRepository.cs precedent) and passes LastActivityDate through.	2026-05-14 20:22:13 -04:00