Struct ServerConfig 

#[non_exhaustive]
pub struct ServerConfig {

    pub app_id: String,
    pub master_key: String,
    pub master_key_ips: IpAllowlist,
    pub maintenance_key: Option<String>,
    pub maintenance_key_ips: IpAllowlist,
    pub javascript_key: Option<String>,
    pub rest_api_key: Option<String>,
    pub client_key: Option<String>,
    pub dot_net_key: Option<String>,
    pub mount_path: String,
    pub enable_sanitized_error_response: bool,
    pub has_push_support: bool,
    pub has_push_scheduled_support: bool,
    pub security_check_enabled: bool,
    pub features: FeatureSupport,
    pub session: SessionConfig,
    pub protected_fields: ProtectedFieldsConfig,
    pub protected_fields_owner_exempt: bool,
    pub protected_fields_save_response_exempt: bool,
    pub allow_custom_object_id: bool,
    pub allow_client_class_creation: bool,
    pub allow_origin: Vec<String>,
    pub allow_headers: Vec<String>,
    pub batch_request_limit: i64,
    pub create_index_role_name: bool,
}

The keys and identity a request is checked against.

#[non_exhaustive], decided at 0.2.1 rather than inherited. This release adds two public fields, which already breaks any ServerConfig { .. } literal outside this crate, and cargo resolves 0.2.1 as compatible with 0.2.0 and will upgrade into it unasked. Marking it here means the break happens once, in the release that was going to cause it anyway, instead of again every time an option is added. Construction is ServerConfig::new followed by field assignment, which is what every call site in this repository already does and what the attribute still permits.

Fields (Non-exhaustive)

Non-exhaustive structs could have additional fields added in future. Therefore, non-exhaustive structs cannot be constructed in external crates using the traditional Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.

app_id: String

master_key: String

master_key_ips: IpAllowlist

masterKeyIps, default ['127.0.0.1', '::1'] (Options/Definitions.js:396-399), enforced at middlewares.js:452.

The default is a control and 0.2.0 shipped without it, so the master key was honoured from any source address on a server nobody had configured. A master key presented from an address outside this list is refused outright rather than downgraded to a client request: upstream throws a bare 403 (middlewares.js:453-462) instead of falling through.

maintenance_key: Option<String>

maintenanceKey. Grants the same ACL treatment as the master key and is not the same authority: validateClientClassCreation exempts both on a write and master alone on a read (RestWrite.js:200-202, RestQuery.js:486-489).

Reachable only from Rust, deliberately. The binary exposes no variable for it, and the reason changed in 0.2.1: it used to be that parse-rust had no IP filter, and now it has one. What remains is that master and maintenance are one AclScope internally, so every decision other than the one corrected above treats them alike. Shipping the key through the CLI would advertise an authority this server only partly distinguishes.

Not to be confused with the read-only master key, which is a third credential, sets isMaster upstream (Auth.js:63), and is not modeled at all.

maintenance_key_ips: IpAllowlist

maintenanceKeyIps, same default and same enforcement (Options/Definitions.js:385-388, middlewares.js:438).

Carried alongside master_key_ips rather than deferred. The two options are one mechanism with two call sites, and filtering one key while leaving the other unfiltered would close a hole and leave its twin open one header away. The exposure is narrower, because a maintenance key has no default value and only exists once an operator sets one.

javascript_key: Option<String>

rest_api_key: Option<String>

client_key: Option<String>

dot_net_key: Option<String>

mount_path: String

Where the API is mounted, e.g. /parse. A builder input, never inferred from the request path: axum’s nest and Express’s app.use differ here, and every generated file URL is built from this value.

enable_sanitized_error_response: bool

enableSanitizedErrorResponse, default true (Options/Definitions.js:253-258).

When true, every denial upstream routes through createSanitizedError or createSanitizedHttpError (Error.js:13-43) says Permission denied instead of naming the rule that refused. That is the configuration an unmodified deployment runs, so it is what every SDK sees by default. Read it as ServerConfig::error_detail rather than as a bare bool at a call site.

has_push_support: bool

has_push_scheduled_support: bool

security_check_enabled: bool

features: FeatureSupport

What /serverInfo advertises. Defaults to the truth: nothing unimplemented.

session: SessionConfig

sessionLength and expireInactiveSessions, which together decide _Session.expiresAt. Defaults are upstream’s (Options/Definitions.js:629-634, :269-274).

protected_fields: ProtectedFieldsConfig

protectedFields. See default_protected_fields for the merge rule.

protected_fields_owner_exempt: bool

protectedFieldsOwnerExempt, default true (Options/Definitions.js:501-506). When true a user reading their own _User row sees every field regardless of protectedFields.

protected_fields_save_response_exempt: bool

protectedFieldsSaveResponseExempt, default true (Options/Definitions.js:507-512).

When true, a create or update response carries protected fields the write touched. When false they are stripped from the response as they are from a query result. parse-rust only ever echoes back the keys whose request value was an operation, so this narrows that echo rather than a whole object.

allow_custom_object_id: bool

allowCustomObjectId, default false (Options/Definitions.js:73-78).

Two effects, and the second is easy to forget because it is in a different file. It gates whether a create may carry its own objectId (RestWrite.js:50-65, enforced by enforce_object_id_policy), and it widens the objectId grammar a CLP entity key is matched against, from ^[a-zA-Z0-9]{1,}$ to ^.{1,}$ (SchemaController.js:726-731).

The two are one option because a CLP naming a user by id has to be able to name a user whose id the client chose.

allow_client_class_creation: bool

allowClientClassCreation, default false (Options/Definitions.js:67-72).

Gates whether a write may bring a class into existence. Enforced by validateClientClassCreation in the write pipeline, which exempts master, maintenance and the classes Parse defines itself.

The default matters more than the option. Left unimplemented, a server behaves as though this were true, which lets a caller holding only the app id and client key create classes without limit on a database parse-server nodes also read, each with a default-open CLP.

allow_origin: Vec<String>

allowOrigin, default ["*"] (middlewares.js:407-408).

A list rather than one value, because upstream accepts either and echoes back whichever entry matches the request’s Origin. An unmatched origin gets the first entry, so a single-element list is an allowlist of one rather than a wildcard.

allow_headers: Vec<String>

allowHeaders. Appended to DEFAULT_ALLOWED_HEADERS rather than replacing it (middlewares.js:402-405), so a deployment adding one custom header does not have to restate the twelve a Parse SDK needs.

batch_request_limit: i64

requestComplexity.batchRequestLimit, default -1, which disables it (Options/Definitions.js:733-738). Master and maintenance bypass it (batch.js:73).

create_index_role_name: bool

databaseOptions.createIndexRoleName, default true (Options/Definitions.js:1318-1323), created at DatabaseController.js:2033-2038.

Not cosmetic. Without the index two _Role rows can carry the same name, and an ACL entry of role:X then grants every member of both, which is a privilege-escalation path rather than a duplicate-data annoyance. Upstream tests !== false, so anything other than an explicit false creates it.

Implementations

impl ServerConfig

pub fn new(app_id: impl Into<String>, master_key: impl Into<String>) -> Self

pub fn error_detail(&self) -> ErrorDetail

Whether a denial tells the client why.

The one place enable_sanitized_error_response becomes an ErrorDetail, so no call site has to remember which way round the bool runs.

pub fn object_id_form(&self) -> ObjectIdForm

How a CLP entity key that looks like an objectId is matched.

pub fn clp_validation(&self) -> ClpValidation

What CLP validation accepts.

Unenforceable::Accept, because the read and write pipelines enforce all three of the features the toggle guards: per-operation pointerFields, the class-wide readUserFields and writeUserFields arrays (ClassLevelPermissions::applicable_pointer_fields), and userField: protected-field entries (ProtectedFieldPlan::user_field_rules). Refusing them would reject a CLP this server honors.

pub fn permission_options(&self) -> PermissionOptions

The permission options the read and write pipelines take.

pub fn javascript_key(self, k: impl Into<String>) -> Self

pub fn rest_api_key(self, k: impl Into<String>) -> Self

pub fn mount_path(self, p: impl Into<String>) -> Self

pub fn requires_client_key(&self) -> bool

True when any client key is configured. Upstream’s rule is all-or-nothing: if any of these is set, a non-master request must present one that matches (middlewares.js:255-265). If none is configured, none is required.

Trait Implementations

impl Clone for ServerConfig

fn clone(&self) -> ServerConfig

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for ServerConfig

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.