Class QuartzDashboardOptions

Namespace

Quartz

Assembly

Quartz.Dashboard.dll

How the dashboard is served and what it is allowed to do.

public sealed class QuartzDashboardOptions

Inheritance

object

QuartzDashboardOptions

Inherited Members

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.ReferenceEquals(object, object)

object.ToString()

Remarks

There is nothing here that points the dashboard at a scheduler: it renders the schedulers in its own process, through the IQuartzApiClient registered in the container.

Properties

AuthorizationPolicy

The authorization policy the dashboard's pages, hub, circuit and assets are held to. Null — the default — applies none of its own, so what guards the dashboard is whatever the application's pipeline already does.

public string? AuthorizationPolicy { get; set; }

Property Value

string

DashboardPath

The base path the dashboard UI is served from. Defaults to "/quartz". A custom value is honored when the dashboard hosts its own Blazor root (the parameterless MapQuartzDashboard() overload). When integrating into an existing Blazor application the dashboard page routes are fixed at "/quartz".

public string DashboardPath { get; set; }

Property Value

string

Remarks

MapQuartzDashboard(pattern) says the same thing where the endpoints are mapped, which is where the rest of an application's routes are written, and a pattern given there wins over this.

HistoryMaxEntriesPerScheduler

How many executions and how many misfires the dashboard's own history store keeps per scheduler, oldest dropped first. Defaults to 2000 of each.

public int HistoryMaxEntriesPerScheduler { get; set; }

Property Value

int

HistoryRetention

How far back the dashboard's own history store keeps executions and misfires. Defaults to 24 hours.

public TimeSpan HistoryRetention { get; set; }

Property Value

TimeSpan

Remarks

The count bound below cannot answer for a scheduler that has gone quiet: it keeps whatever it last recorded, so a page shows executions from an arbitrary distance in the past with nothing to say how old they are. Both bounds apply, and whichever bites first wins.

IsJobTypeAllowed

Which job types a call through the dashboard's IQuartzApiClient may name. Null — the default — allows every one, which is what every earlier release did.

public Func<string, bool>? IsJobTypeAllowed { get; set; }

Property Value

Func<string, bool>

Remarks

This is the narrowing for the thing SECURITY.md says is not a vulnerability: a visitor who passes authorization can add or schedule a job of any type that implements IJob, and Quartz.Jobs' NativeJob implements it and starts the executable its job data names. Where ReadOnly refuses every mutation, this refuses one kind of them.

The predicate is given the job type name, as it was written, and nothing resolves it first — the dashboard stores a job type name unresolved for the same reason the HTTP API does, so that a name arriving from outside never makes this process probe its assemblies. Match on the string, and remember that one type has more than one spelling: Acme.Jobs.Nightly, Acme.Jobs and the same name carrying Version, Culture and PublicKeyToken are both it.

A refused name raises UnauthorizedAccessException, the way a scheduler the visitor fails SchedulerAuthorizationPolicy for does. Enforced by the client rather than by the pages, so it holds wherever the call is made from. It says nothing about the HTTP API, which is mapped and configured separately: QuartzHttpApiOptions.IsJobTypeAllowed is the same setting for that surface.

ReadOnly

Hides every mutating action — pause, resume, trigger now, reschedule, unschedule, delete — so the dashboard is a view of the schedulers rather than a way to drive them.

public bool ReadOnly { get; set; }

Property Value

bool

Remarks

Enforced by the client rather than by the pages alone: a mutation refused here is refused wherever it is called from, so hiding a button is not what makes it safe.

SchedulerAuthorizationPolicy

The authorization policy each scheduler is held to, evaluated against a SchedulerResource carrying that scheduler's name. Null — the default — leaves the dashboard as it was: whoever passes AuthorizationPolicy sees every scheduler in the process.

public string? SchedulerAuthorizationPolicy { get; set; }

Property Value

string

Remarks

Set it and the scheduler picker offers only the schedulers the visitor passes for, a page opened on one they do not says so without reading anything, and the live-events hub refuses to subscribe them to it. The two policies compose: AuthorizationPolicy decides who reaches the dashboard at all, this one decides which schedulers they see once they are in, and ReadOnly still decides what anyone may change.

It is the same policy and the same resource the HTTP API's QuartzHttpApiOptions.SchedulerAuthorizationPolicy evaluates, so one AuthorizationHandler<TRequirement, SchedulerResource> answers for both surfaces.