Search Results for

Show / Hide Table of Contents

# Namespace CoreUpload.Security

### Classes

#### UploadSecurityContext

#### UploadSecurityData

### Interfaces

#### IUploadAuthorizationHandler

Optional per-file authorization for the built-in endpoints.

Default behavior (no implementation registered): the endpoints are capability-based — anyone holding a file's GUID can read or delete it. The GUIDs are NewGuid() (v4, not enumerable), so this is the same security model as an unguessable share link. That is a deliberate default so the component works with zero configuration, but it means a GUID leaked through a referrer header, a log, or a screenshot grants access.

To scope files to a user/tenant, register an implementation:

    builder.Services.AddSingleton<IUploadAuthorizationHandler, MyUploadAuthorization>();
    public sealed class MyUploadAuthorization : IUploadAuthorizationHandler
    {
    public ValueTask<bool> AuthorizeAsync(HttpContext http, Guid fileGuid, UploadFileAction action, CancellationToken ct)
    {
    var owner = MyDb.GetOwnerOf(fileGuid);
    return ValueTask.FromResult(owner == http.User.Identity?.Name);
    }
    }

Returning false makes the endpoint answer 404 (not 403) so a caller cannot probe which GUIDs exist.

Note that `DELETE` also honors `CoreUploadOptions.EnableAntiforgery`, which is off by default; turn it on (or authorize here) if a leaked GUID must not be deletable cross-site.

### Enums

#### UploadFileAction

Actions the built-in endpoints perform on an already-stored file.