* refactor(server)!: sanitize error messages to avoid leaking resource and permission details
* fix e2e tests
* fix(server): prevent login timing oracle by always running bcrypt
Always call compareBcrypt in the login path regardless of whether the
email is registered. When no user is found, a dummy hash is used so the
bcrypt KDF still runs and response latency is constant, making it
impossible to enumerate valid email addresses by measuring response time.
* fix(server): collapse OAuth callback messages to prevent email-existence oracle
Two distinct error messages in the OAuth callback endpoint revealed
whether an email address was already registered in the database.
An attacker controlling the OAuth provider's email claim could probe
the user table without authentication. Both cases now return the same
generic message.
* fix(server): replace email-in-use messages to prevent user-existence oracle
Error messages on registration and profile-update that named whether an
email address was already taken allowed callers to enumerate registered
accounts. All three sites now return the same generic message regardless
of whether the address is in use.
* fix(server): hide slug uniqueness constraint to prevent shared-link probe
Surfacing the Postgres unique-constraint name in the error response let
any authenticated user brute-force whether a custom slug was already in
use by another user's shared link, leaking the existence of other links.
* fix(server): unify profile image errors to prevent user-existence oracle via status code
GET /users/:id/profile-image returned HTTP 400 for an unknown user ID
but HTTP 404 when the user existed without a photo, letting callers
distinguish the two cases. Both now return 404 so the response is
identical regardless of whether the UUID maps to an account.
* fix(server): replace album user-not-found message to prevent UUID-existence oracle
Album owners could probe arbitrary UUIDs via the add-user endpoint and
determine whether they belonged to registered accounts by receiving
'User not found'. The message is now ambiguous about whether the ID was
unrecognised or the user is inactive.
* Revert "fix e2e tests"
This reverts commit c1bd7a116b3f0fccf3d2530c8e34b13c1d862989.
* Revert "refactor(server)!: sanitize error messages to avoid leaking resource and permission details"
This reverts commit b96421a08387340fbb77913ca89b0717bcd9945d.
* fix(server): use 403 instead of 400 for access-denied errors
requireAccess threw BadRequestException which is incorrect HTTP semantics.
Access denial is a client authorization problem (403 Forbidden), not a
malformed request (400 Bad Request). Keep the descriptive permission name
in the message since the full permission set is public API surface.
* Revert "fix(server): use 403 instead of 400 for access-denied errors"
This reverts commit bb069909571f4e514e7d050ddf588c017ee5a029.
* shorten comment
* add log messages
* format
* one more
* fix(server): prevent album shared link from breaking after uploads
* update test
* add withSharedAssets helper
* remove options
* add more helpers
* update selects
The searchAssetBuilder was incorrectly adding withFacesAndPeople
select when personIds was provided. This caused a SQL error because
the subquery referenced asset.id which wasn't selected in statistics
queries (only count(*) was selected).
The fix removes personIds from the condition that triggers adding
faces data to the select. The hasPeople filter (for personIds) is
still applied correctly for filtering.
Fixes#25003
Signed-off-by: majiayu000 <1835304752@qq.com>
* feat: workflow ui
* wip
* wip
* wip
* pr feedback
* refactor: picker field
* use showDialog directly
* better test
* refactor step selection modal
* move enable button to info form
* use for Props
* pr feedback
* refactor ActionItem
* refactor ActionItem
* more refactor
* fix: new schemaformfield has value of the same type
* chore: clean up
* Test memory creation in advance
Use year 2035 to make sure it's in the future of current time of a test run
* Use target year instead of current year when fetching assets during memory creation
This fixes an edge case of creating memories in advance when target year is
different from current year.
Example: job runs on 2025-12-31 (current year is 2025) and creates memories
to be shown on 2026-01-01 (target year is 2026). If using _current_ year in
calculation then range of years is capped at (2025 - 1 = 2024) thus excluding
2025-01-01 from created memories. With _target_ year it is (2026 - 1 = 2025),
so 2025-01-01 will be included in memories.
* Update sql queries
