mirror of
https://github.com/RedWizardsLab/EchoHub.git
synced 2026-09-07 15:46:02 +02:00
deploy: 0105f798e0
This commit is contained in:
@@ -26,20 +26,14 @@ public record DeleteAccountRequest(string Password)
|
||||
| `Password` | `string` | — |
|
||||
|
||||
|
||||
This record models the password-confirmation payload required when a user initiates destructive self-service account actions (such as deleting their account). It captures the password as a single field to prove the user’s intent before the action is executed.
|
||||
Represents a request payload that carries the user's `Password` to re-confirm destructive self-service actions on the account. This separate `DeleteAccountRequest` DTO isolates credential input from other account data and is intended for use in flows that require explicit user re-authentication before irreversible operations (e.g., account deletion).
|
||||
|
||||
## Remarks
|
||||
DeleteAccountRequest encapsulates a sensitive credential within a lightweight boundary object to keep password handling explicit in the delete workflow. By isolating the password in a dedicated payload, the system can perform authentication checks, auditing, and policy enforcement at the appropriate boundary. The record is immutable and minimal (a single Password property), which simplifies model binding and reduces the surface area for accidental data exposure.
|
||||
|
||||
## Example
|
||||
```csharp
|
||||
// When initiating a delete flow, supply the password for re-confirmation.
|
||||
var request = new DeleteAccountRequest("P@ssw0rd!");
|
||||
```
|
||||
Isolates sensitive credential input into a minimal, purpose-built payload, enabling focused validation and auditing of destructive actions. It complements authentication state by forcing an explicit password re-entry rather than relying on session state alone, which helps mitigate accidental or unauthorized deletions. This pattern supports clearer separation of concerns between domain models and security-critical request data.
|
||||
|
||||
## Notes
|
||||
- Treat the Password as sensitive; avoid logging or exposing it in responses.
|
||||
- Use this payload only in the delete flow; ensure that the password validation is performed server-side before performing the destructive action.
|
||||
- Do not log or persist the `Password` value in plaintext; keep it transient and ensure redaction in any logs.
|
||||
- Ensure transport security (`TLS`) when transmitting this payload; avoid storing passwords in memory longer than needed; clear the value after usage if possible.
|
||||
|
||||
---
|
||||
|
||||
@@ -69,28 +63,16 @@ public record ExportedAttachmentDto(
|
||||
| `SentAt` | `DateTimeOffset` | — |
|
||||
|
||||
|
||||
Represents the metadata of an attachment that has been exported from a channel. It groups the file name, a URL to access the file, the file size in bytes, a textual kind descriptor, the originating channel name, and the timestamp when it was sent. Use this DTO when returning or transmitting export results to clients or cross-system boundaries to ensure a stable, serializable shape that is decoupled from internal domain models.
|
||||
Represents the metadata of an attachment that has been exported, carrying the essential details needed to access and display it—`FileName`, `Url`, `FileSize`, `Kind`, `ChannelName`, and `SentAt`. It serves as a transport contract between the export logic and clients or downstream services rather than exposing internal domain entities.
|
||||
|
||||
## Remarks
|
||||
- Being a record, instances are immutable and equality is value-based, making it ideal for transport across layers or for caching export results. It serves as a clean contract between the export process and API or consumer layers.
|
||||
- It acts as a boundary object, decoupling presentation/API concerns from domain entities while preserving the essential attachment metadata needed by clients (name, access URL, size, kind, origin channel, and timestamp).
|
||||
|
||||
## Example
|
||||
```csharp
|
||||
var attachment = new ExportedAttachmentDto(
|
||||
FileName: "invoice.pdf",
|
||||
Url: "https://cdn.example.com/exports/invoice.pdf",
|
||||
FileSize: 254000,
|
||||
Kind: "document",
|
||||
ChannelName: "billing",
|
||||
SentAt: DateTimeOffset.UtcNow
|
||||
);
|
||||
```
|
||||
`ExportedAttachmentDto` acts as a boundary-crossing contract: it decouples the external payload from the internal attachment representation and exposes only the data consumers require. The inclusion of a `Url` implies a downloadable resource that may be protected or time-limited, so callers should treat access as potentially ephemeral and handle expiration appropriately. Because this is a `record`, instances are immutable by default, which helps preserve the integrity of the export snapshot across layers.
|
||||
|
||||
## Notes
|
||||
- The Kind property is a free-form string; if there is a known finite set of kinds, consider introducing a dedicated enum later to avoid inconsistent values.
|
||||
- FileSize is a long and should be non-negative; implement validation at boundaries if negative values could be produced by upstream systems.
|
||||
- Ensure the Url is appropriate for client access (consider expiration, authentication, and CORS as needed) since this DTO surfaces a direct link to the exported attachment.
|
||||
|
||||
- The `Url` is often a signed or temporary link; do not assume long-lived access and design clients to handle expiration (e.g., 404 or 403 responses).
|
||||
- This DTO is strictly a data carrier; avoid embedding business logic in the payload and prefer mapping from domain models to this shape when exporting data.
|
||||
|
||||
---
|
||||
|
||||
@@ -118,26 +100,10 @@ public record ExportedMessageDto(
|
||||
| `ReplyToMessageId` | `Guid?` | — |
|
||||
|
||||
|
||||
ExportedMessageDto is an immutable data transfer object that captures the essential details of a message exported from a channel: its identity (Id), the channel it came from (ChannelName), when it was sent (SentAt), the message content (Content), and an optional reference to the message it replies to (ReplyToMessageId). It serves as a serialization-friendly payload used by export or archival pipelines, decoupled from the in-memory domain model.
|
||||
ExportedMessageDto is an immutable data transfer object (record) that captures the essential data of a single exported message: the message `Id`, the `ChannelName` it was sent in, the `SentAt` timestamp, the `Content`, and an optional `ReplyToMessageId` if the message is a reply. It provides a stable, serializable contract for exporting messages to external systems or archives, decoupled from domain behavior so consumers can rely on a consistent shape without depending on domain entities.
|
||||
|
||||
## Remarks
|
||||
ExportedMessageDto provides a stable contract for export pipelines by decoupling serialized data from the internal domain entities. Being a record, it benefits from value-based equality and immutability, which simplifies de-duplication and testing of exported payloads. The nullable ReplyToMessageId models the optional threading relationship: null means the message has no parent. Use ChannelName and SentAt as lightweight contextual metadata when reconstructing conversations in external systems.
|
||||
|
||||
## Example
|
||||
```csharp
|
||||
var message = new ExportedMessageDto(
|
||||
Id: Guid.NewGuid(),
|
||||
ChannelName: "general",
|
||||
SentAt: DateTimeOffset.UtcNow,
|
||||
Content: "Hello world",
|
||||
ReplyToMessageId: null
|
||||
);
|
||||
```
|
||||
|
||||
## Notes
|
||||
- The ReplyToMessageId is nullable; null indicates no parent message.
|
||||
- As a record, equality is based on all properties; two messages with identical data compare as equal.
|
||||
- If you need to derive a modified copy without mutating the original, use the with-expression (e.g., var updated = message with { Content = "Updated" };).
|
||||
As a `record`, `ExportedMessageDto` provides value-like semantics and a predictable equality contract, which is helpful when comparing exported records or caching results during export pipelines. It also separates export concerns from the rest of the domain, making it easier to evolve the internal models without breaking external consumers.
|
||||
|
||||
---
|
||||
|
||||
@@ -165,14 +131,12 @@ public record UserDataExportDto(
|
||||
| `Attachments` | `List<ExportedAttachmentDto>` | — |
|
||||
|
||||
|
||||
Represents a persisted snapshot of a user's data as stored by the server, intended for data export or portability. It consolidates the export timestamp, the server identity, the user's profile, and the exported messages and attachments; in end-to-end encrypted rooms the message contents are ciphertext, since the server never has access to plaintext.
|
||||
`UserDataExportDto` is a `record` that represents a complete snapshot of the server's stored data for a given user, produced when exporting user data for portability or archival. It contains the export timestamp (`ExportedAt`), the originating server name ([`ServerName`](../../EchoHub.Server.Irc/IrcCommandHandler.cs.md)), the user's profile (`Profile`), and the exported content items: messages (`Messages`) and attachments (`Attachments`). In end-to-end encrypted rooms, the message payload is preserved as ciphertext, since the server cannot provide plaintext it never possessed.
|
||||
|
||||
## Remarks
|
||||
|
||||
UserDataExportDto is an immutable data transfer object that anchors the export pipeline to the server's stored representation. By pairing profile, messages, and attachments into a single artifact, it simplifies serialization, auditing, and versioning while guarding the boundaries between storage concerns and export logic.
|
||||
This DTO acts as the stable envelope for user data exports, keeping metadata, profile, and content items together for portability and archival use. It decouples export semantics from how data is stored, permitting changes to storage without breaking export contracts. Note that for end-to-end encrypted rooms, the `Messages` are ciphertext as stored; no plaintext is accessible to the server.
|
||||
|
||||
## Notes
|
||||
|
||||
- The Messages collection contains ciphertext for end-to-end encrypted rooms; do not decrypt on the server. Decryption and user presentation must happen client-side with proper keys.
|
||||
- Large exports can be memory-intensive; plan for streaming or chunked delivery in exporters.
|
||||
|
||||
---
|
||||
Reference in New Issue
Block a user