# Hapi > 21.4.321.3.020.3.019.2.118.4.217.9.416.8.4 --- # hapi Documentation # Source: https://hapi.dev/api/ API 21.4.321.3.020.3.019.2.118.4.217.9.416.8.4 Showing result 1 of 0 Previous Next No results found * [Server](#server) * [`server()`](#-serveroptions) * [Server options](#-server-options) * [`server.options.address`](#-serveroptionsaddress) * [`server.options.app`](#-serveroptionsapp) * [`server.options.autoListen`](#-serveroptionsautolisten) * [`server.options.cache`](#-serveroptionscache) * [`server.options.compression`](#-serveroptionscompression) * [`server.options.compression.minBytes`](#-serveroptionscompressionminbytes) * [`server.options.debug`](#-serveroptionsdebug) * [`server.options.host`](#-serveroptionshost) * [`server.options.info.remote`](#-serveroptionsinforemote) * [`server.options.listener`](#-serveroptionslistener) * [`server.options.load`](#-serveroptionsload) * [`server.options.mime`](#-serveroptionsmime) * [`server.options.operations`](#-serveroptionsoperations) * [`server.options.plugins`](#-serveroptionsplugins) * [`server.options.port`](#-serveroptionsport) * [`server.options.query`](#-serveroptionsquery) * [`server.options.query.parser`](#-serveroptionsqueryparser) * [`server.options.router`](#-serveroptionsrouter) * [`server.options.routes`](#-serveroptionsroutes) * [`server.options.state`](#-serveroptionsstate) * [`server.options.tls`](#-serveroptionstls) * [`server.options.uri`](#-serveroptionsuri) * [Server properties](#server-properties) * [`server.app`](#-serverapp) * [`server.auth.api`](#-serverauthapi) * [`server.auth.settings.default`](#-serverauthsettingsdefault) * [`server.decorations`](#-serverdecorations) * [`server.events`](#-serverevents) * [`'log'` Event](#-log-event) * [`'cachePolicy'` Event](#-cachepolicy-event) * [`'request'` Event](#-request-event) * [`'response'` Event](#-response-event) * [`'route'` Event](#-route-event) * [`'start'` Event](#-start-event) * [`'closing'` Event](#-closing-event) * [`'stop'` Event](#-stop-event) * [`server.info`](#-serverinfo) * [`server.listener`](#-serverlistener) * [`server.load`](#-serverload) * [`server.methods`](#-servermethods) * [`server.mime`](#-servermime) * [`server.plugins`](#-serverplugins) * [`server.realm`](#-serverrealm) * [`server.registrations`](#-serverregistrations) * [`server.settings`](#-serversettings) * [`server.states`](#-serverstates) * [`server.states.settings`](#-serverstatessettings) * [`server.states.cookies`](#-serverstatescookies) * [`server.states.names`](#-serverstatesnames) * [`server.type`](#-servertype) * [`server.version`](#-serverversion) * [`server.auth.default()`](#-serverauthdefaultoptions) * [`server.auth.scheme()`](#-serverauthschemename-scheme) * [Authentication scheme](#authentication-scheme) * [`server.auth.strategy()`](#-serverauthstrategyname-scheme-options) * [`await server.auth.test()`](#-await-serverauthteststrategy-request) * [`await server.auth.verify()`](#-await-serverauthverifyrequest) * [`server.bind()`](#-serverbindcontext) * [`server.cache()`](#-servercacheoptions) * [`await server.cache.provision()`](#-await-servercacheprovisionoptions) * [`server.control()`](#-servercontrolserver) * [`server.decoder()`](#-serverdecoderencoding-decoder) * [`server.decorate()`](#-serverdecoratetype-property-method-options) * [`server.dependency()`](#-serverdependencydependencies-after) * [`server.encoder()`](#-serverencoderencoding-encoder) * [`server.event()`](#-servereventevents) * [`server.events.emit()`](#-servereventsemitcriteria-data) * [`server.events.on()`](#-servereventsoncriteria-listener-context) * [`server.events.once()`](#-servereventsoncecriteria-listener-context) * [`await server.events.once()`](#-await-servereventsoncecriteria) * [`await server.events.gauge()`](#-await-servereventsgaugecriteria-data) * [`server.expose()`](#-serverexposekey-value-options) * [`server.expose()`](#-serverexposeobj) * [`server.ext()`](#-serverextevents) * [`server.ext()`](#-serverextevent-method-options) * [`await server.initialize()`](#-await-serverinitialize) * [`await server.inject()`](#-await-serverinjectoptions) * [`server.log()`](#-serverlogtags-data-timestamp) * [`server.lookup()`](#-serverlookupid) * [`server.match()`](#-servermatchmethod-path-host) * [`server.method()`](#-servermethodname-method-options) * [`server.method()`](#-servermethodmethods) * [`server.path()`](#-serverpathrelativeto) * [`await server.register()`](#-await-serverregisterplugins-options) * [`server.route()`](#-serverrouteroute) * [Path parameters](#path-parameters) * [Path matching order](#path-matching-order) * [Catch all route](#catch-all-route) * [`server.rules()`](#-serverrulesprocessor-options) * [`await server.start()`](#-await-serverstart) * [`server.state()`](#-serverstatename-options) * [`server.states.add()`](#-serverstatesaddname-options) * [`await server.states.format()`](#-await-serverstatesformatcookies) * [`await server.states.parse()`](#-await-serverstatesparseheader) * [`await server.stop()`](#-await-serverstopoptions) * [`server.table()`](#-servertablehost) * [`server.validator()`](#-servervalidatorvalidator) * [Route options](#route-options) * [`route.options.app`](#-routeoptionsapp) * [`route.options.auth`](#-routeoptionsauth) * [`route.options.auth.access`](#-routeoptionsauthaccess) * [`route.options.auth.access.scope`](#-routeoptionsauthaccessscope) * [`route.options.auth.access.entity`](#-routeoptionsauthaccessentity) * [`route.options.auth.mode`](#-routeoptionsauthmode) * [`route.options.auth.payload`](#-routeoptionsauthpayload) * [`route.options.auth.strategies`](#-routeoptionsauthstrategies) * [`route.options.auth.strategy`](#-routeoptionsauthstrategy) * [`route.options.bind`](#-routeoptionsbind) * [`route.options.cache`](#-routeoptionscache) * [`route.options.compression`](#-routeoptionscompression) * [`route.options.cors`](#-routeoptionscors) * [`route.options.description`](#-routeoptionsdescription) * [`route.options.ext`](#-routeoptionsext) * [`route.options.files`](#-routeoptionsfiles) * [`route.options.handler`](#-routeoptionshandler) * [`route.options.id`](#-routeoptionsid) * [`route.options.isInternal`](#-routeoptionsisinternal) * [`route.options.json`](#-routeoptionsjson) * [`route.options.log`](#-routeoptionslog) * [`route.options.notes`](#-routeoptionsnotes) * [`route.options.payload`](#-routeoptionspayload) * [`route.options.payload.allow`](#-routeoptionspayloadallow) * [`route.options.payload.compression`](#-routeoptionspayloadcompression) * [`route.options.payload.defaultContentType`](#-routeoptionspayloaddefaultcontenttype) * [`route.options.payload.failAction`](#-routeoptionspayloadfailaction) * [`route.options.payload.maxBytes`](#-routeoptionspayloadmaxbytes) * [`route.options.payload.maxParts`](#-routeoptionspayloadmaxparts) * [`route.options.payload.multipart`](#-routeoptionspayloadmultipart) * [`route.options.payload.output`](#-routeoptionspayloadoutput) * [`route.options.payload.override`](#-routeoptionspayloadoverride) * [`route.options.payload.parse`](#-routeoptionspayloadparse) * [`route.options.payload.protoAction`](#-routeoptionspayloadprotoaction) * [`route.options.payload.timeout`](#-routeoptionspayloadtimeout) * [`route.options.payload.uploads`](#-routeoptionspayloaduploads) * [`route.options.plugins`](#-routeoptionsplugins) * [`route.options.pre`](#-routeoptionspre) * [`route.options.response`](#-routeoptionsresponse) * [`route.options.response.disconnectStatusCode`](#-routeoptionsresponsedisconnectstatuscode) * [`route.options.response.emptyStatusCode`](#-routeoptionsresponseemptystatuscode) * [`route.options.response.failAction`](#-routeoptionsresponsefailaction) * [`route.options.response.modify`](#-routeoptionsresponsemodify) * [`route.options.response.options`](#-routeoptionsresponseoptions) * [`route.options.response.ranges`](#-routeoptionsresponseranges) * [`route.options.response.sample`](#-routeoptionsresponsesample) * [`route.options.response.schema`](#-routeoptionsresponseschema) * [`route.options.response.status`](#-routeoptionsresponsestatus) * [`route.options.rules`](#-routeoptionsrules) * [`route.options.security`](#-routeoptionssecurity) * [`route.options.state`](#-routeoptionsstate) * [`route.options.tags`](#-routeoptionstags) * [`route.options.timeout`](#-routeoptionstimeout) * [`route.options.timeout.server`](#-routeoptionstimeoutserver) * [`route.options.timeout.socket`](#-routeoptionstimeoutsocket) * [`route.options.validate`](#-routeoptionsvalidate) * [`route.options.validate.errorFields`](#-routeoptionsvalidateerrorfields) * [`route.options.validate.failAction`](#-routeoptionsvalidatefailaction) * [`route.options.validate.headers`](#-routeoptionsvalidateheaders) * [`route.options.validate.options`](#-routeoptionsvalidateoptions) * [`route.options.validate.params`](#-routeoptionsvalidateparams) * [`route.options.validate.payload`](#-routeoptionsvalidatepayload) * [`route.options.validate.query`](#-routeoptionsvalidatequery) * [`route.options.validate.state`](#-routeoptionsvalidatestate) * [`route.options.validate.validator`](#-routeoptionsvalidatevalidator) * [Request lifecycle](#request-lifecycle) * [Lifecycle methods](#lifecycle-methods) * [Lifecycle workflow](#lifecycle-workflow) * [Takeover response](#takeover-response) * [`failAction` configuration](#-failaction-configuration) * [Errors](#errors) * [Error transformation](#error-transformation) * [Response Toolkit](#response-toolkit) * [Toolkit properties](#toolkit-properties) * [`h.abandon`](#-habandon) * [`h.close`](#-hclose) * [`h.context`](#-hcontext) * [`h.continue`](#-hcontinue) * [`h.realm`](#-hrealm) * [`h.request`](#-hrequest) * [`h.authenticated()`](#-hauthenticateddata) * [`h.entity()`](#-hentityoptions) * [`h.redirect()`](#-hredirecturi) * [`h.response()`](#-hresponsevalue) * [`h.state()`](#-hstatename-value-options) * [`h.unauthenticated()`](#-hunauthenticatederror-data) * [`h.unstate()`](#-hunstatename-options) * [Response object](#response-object) * [Response properties](#response-properties) * [`response.app`](#-responseapp) * [`response.contentType`](#-responsecontenttype) * [`response.events`](#-responseevents) * [`response.headers`](#-responseheaders) * [`response.plugins`](#-responseplugins) * [`response.settings`](#-responsesettings) * [`response.settings.passThrough`](#-responsesettingspassthrough) * [`response.settings.stringify`](#-responsesettingsstringify) * [`response.settings.ttl`](#-responsesettingsttl) * [`response.settings.varyEtag`](#-responsesettingsvaryetag) * [`response.source`](#-responsesource) * [`response.statusCode`](#-responsestatuscode) * [`response.variety`](#-responsevariety) * [`response.bytes()`](#-responsebyteslength) * [`response.charset()`](#-responsecharsetcharset) * [`response.code()`](#-responsecodestatuscode) * [`response.message()`](#-responsemessagehttpmessage) * [`response.compressed()`](#-responsecompressedencoding) * [`response.created()`](#-responsecreateduri) * [`response.encoding()`](#-responseencodingencoding) * [`response.etag()`](#-responseetagtag-options) * [`response.header()`](#-responseheadername-value-options) * [`response.location()`](#-responselocationuri) * [`response.redirect()`](#-responseredirecturi) * [`response.replacer()`](#-responsereplacermethod) * [`response.spaces()`](#-responsespacescount) * [`response.state()`](#-responsestatename-value-options) * [`response.suffix()`](#-responsesuffixsuffix) * [`response.ttl()`](#-responsettlmsec) * [`response.type()`](#-responsetypemimetype) * [`response.unstate()`](#-responseunstatename-options) * [`response.vary()`](#-responsevaryheader) * [`response.takeover()`](#-responsetakeover) * [`response.temporary()`](#-responsetemporaryistemporary) * [`response.permanent()`](#-responsepermanentispermanent) * [`response.rewritable()`](#-responserewritableisrewritable) * [Request](#request) * [Request properties](#request-properties) * [`request.app`](#-requestapp) * [`request.auth`](#-requestauth) * [`request.events`](#-requestevents) * [`request.headers`](#-requestheaders) * [`request.info`](#-requestinfo) * [`request.isInjected`](#-requestisinjected) * [`request.logs`](#-requestlogs) * [`request.method`](#-requestmethod) * [`request.mime`](#-requestmime) * [`request.orig`](#-requestorig) * [`request.params`](#-requestparams) * [`request.paramsArray`](#-requestparamsarray) * [`request.path`](#-requestpath) * [`request.payload`](#-requestpayload) * [`request.plugins`](#-requestplugins) * [`request.pre`](#-requestpre) * [`request.response`](#-requestresponse) * [`request.preResponses`](#-requestpreresponses) * [`request.query`](#-requestquery) * [`request.raw`](#-requestraw) * [`request.route`](#-requestroute) * [`request.server`](#-requestserver) * [`request.state`](#-requeststate) * [`request.url`](#-requesturl) * [`request.generateResponse()`](#-requestgenerateresponsesource-options) * [`request.active()`](#-requestactive) * [`request.log()`](#-requestlogtags-data) * [`request.route.auth.access()`](#-requestrouteauthaccessrequest) * [`request.setMethod()`](#-requestsetmethodmethod) * [`request.setUrl(url, [stripTrailingSlash]`](#-requestseturlurl-striptrailingslash) * [Plugins](#plugins) ## Server [](#server) The server object is the main application container. The server manages all incoming requests along with all the facilities provided by the framework. Each server supports a single connection (e.g. listen to port `80`). ### `server([options])` [](#-serveroptions) Creates a new server object where: * `options` \- (optional) a [server configuration object](#server.options). const Hapi = require('@hapi/hapi'); const server = Hapi.server({ load: { sampleInterval: 1000 } }); ### Server options [](#-server-options) The server options control the behavior of the server object. Note that the options object is deeply cloned (with the exception of [`listener`](#server.options.listener) which is shallowly copied) and should not contain any values that are unsafe to perform deep copy on. All options are optionals. #### `server.options.address` [](#-serveroptionsaddress) Default value: `'::'` if IPv6 is available, otherwise `'0.0.0.0'` (i.e. all available network interfaces). Sets the hostname or IP address the server will listen on. If not configured, defaults to [`host`](#server.options.host) if present, otherwise to all available network interfaces. Set to `'127.0.0.1'`, `'::1'`, or `'localhost'` to restrict the server to only those coming from the same host. #### `server.options.app` [](#-serveroptionsapp) Default value: `{}`. Provides application-specific configuration which can later be accessed via [`server.settings.app`](#server.settings). The framework does not interact with this object. It is simply a reference made available anywhere a `server` reference is provided. Note the difference between `server.settings.app` which is used to store static configuration values and [`server.app`](#server.app) which is meant for storing run-time state. #### `server.options.autoListen` [](#-serveroptionsautolisten) Default value: `true`. Used to disable the automatic initialization of the [`listener`](#server.options.listener). When `false`, indicates that the [`listener`](#server.options.listener) will be started manually outside the framework. Cannot be set to `false` along with a [`port`](#server.options.port) value. #### `server.options.cache` [](#-serveroptionscache) Default value: `{ provider: { constructor: require('@hapi/catbox-memory'), options: { partition: 'hapi-cache' } } }`. Sets up server-side caching providers. Every server includes a default cache for storing application state. By default, a simple memory-based cache is created which has limited capacity and capabilities. **hapi** uses [**catbox**](https://hapi.dev/family/catbox/api) for its cache implementation which includes support for common storage solutions (e.g. Redis, MongoDB, Memcached, Riak, among others). Caching is only utilized if [methods](#server.methods) and [plugins](#plugins) explicitly store their state in the cache. The server cache configuration only defines the storage container itself. The configuration can be assigned one or more (array): * a class or prototype function (usually obtained by calling `require()` on a **catbox** strategy such as `require('@hapi/catbox-redis')`). A new **catbox** [client](https://hapi.dev/family/catbox/api#client) will be created internally using this constructor. * a configuration object with the following: * `engine` \- a **catbox** engine object instance. * `name` \- an identifier used later when provisioning or configuring caching for [server methods](#server.methods) or [plugins](#plugins). Each cache name must be unique. A single item may omit the `name` option which defines the default cache. If every cache includes a `name`, a default memory cache is provisioned as well. * `provider` \- a class, a constructor function, or an object with the following: * `constructor` \- a class or a prototype function. * `options` \- (optional) a settings object passed as-is to the `constructor` with the following: * `partition` \- (optional) string used to isolate cached data. Defaults to `'hapi-cache'`. * other constructor-specific options passed to the `constructor` on instantiation. * `shared` \- if `true`, allows multiple cache users to share the same segment (e.g. multiple methods using the same cache storage container). Default to `false`. * One (and only one) of `engine` or `provider` is required per configuration object. #### `server.options.compression` [](#-serveroptionscompression) Default value: `{ minBytes: 1024 }`. Defines server handling of content encoding requests. If `false`, response content encoding is disabled and no compression is performed by the server. ##### `server.options.compression.minBytes` [](#-serveroptionscompressionminbytes) Default value: '1024'. Sets the minimum response payload size in bytes that is required for content encoding compression. If the payload size is under the limit, no compression is performed. #### `server.options.debug` [](#-serveroptionsdebug) Default value: `{ request: ['implementation'] }`. Determines which logged events are sent to the console. This should only be used for development and does not affect which events are actually logged internally and recorded. Set to `false` to disable all console logging, or to an object with: * `log` \- a string array of server log tags to be displayed via `console.error()` when the events are logged via [`server.log()`](#server.log\(\)) as well as internally generated [server logs](#server-logs). Defaults to no output. * `request` \- a string array of request log tags to be displayed via `console.error()` when the events are logged via [`request.log()`](#request.log\(\)) as well as internally generated [request logs](#request-logs). For example, to display all errors, set the option to `['error']`. To turn off all console debug messages set it to `false`. To display all request logs, set it to `'*'`. Defaults to uncaught errors thrown in external code (these errors are handled automatically and result in an Internal Server Error response) or runtime errors due to developer error. For example, to display all errors, set the `log` or `request` to `['error']`. To turn off all output set the `log` or `request` to `false`. To display all server logs, set the `log` or `request` to `'*'`. To disable all debug information, set `debug` to `false`. #### `server.options.host` [](#-serveroptionshost) Default value: the operating system hostname and if not available, to `'localhost'`. The public hostname or IP address. Used to set [`server.info.host`](#server.info) and [`server.info.uri`](#server.info) and as [`address`](#server.options.address) if none is provided. #### `server.options.info.remote` [](#-serveroptionsinforemote) Default value: `false`. If `true`, the `request.info.remoteAddress` and `request.info.remotePort` are populated when the request is received which can consume more resource (but is ok if the information is needed, especially for aborted requests). When `false`, the fields are only populated upon demand (but will be `undefined` if accessed after the request is aborted). #### `server.options.listener` [](#-serveroptionslistener) Default value: none. An optional node HTTP (or HTTPS) [`http.Server`](https://nodejs.org/api/http.html#http_class_http_server) object (or an object with a compatible interface). If the `listener` needs to be manually started, set [`autoListen`](#server.options.autolisten) to `false`. If the `listener` uses TLS, set [`tls`](#server.options.tls) to `true`. #### `server.options.load` [](#-serveroptionsload) Default value: `{ sampleInterval: 0, maxHeapUsedBytes: 0, maxRssBytes: 0, maxEventLoopDelay: 0, maxEventLoopUtilization: 0 }`. Server excessive load handling limits where: * `sampleInterval` \- the frequency of sampling in milliseconds. When set to `0`, the other load options are ignored. Defaults to `0` (no sampling). * `maxHeapUsedBytes` \- maximum V8 heap size over which incoming requests are rejected with an HTTP Server Timeout (503) response. Defaults to `0` (no limit). * `maxRssBytes` \- maximum process RSS size over which incoming requests are rejected with an HTTP Server Timeout (503) response. Defaults to `0` (no limit). * `maxEventLoopDelay` \- maximum event loop delay duration in milliseconds over which incoming requests are rejected with an HTTP Server Timeout (503) response. Defaults to `0` (no limit). * `maxEventLoopUtilization` \- maximum event loop utilization value over which incoming requests are rejected with an HTTP Server Timeout (503) response. Defaults to `0` (no limit). #### `server.options.mime` [](#-serveroptionsmime) Default value: none. Options passed to the [**mimos**](https://hapi.dev/family/mimos/api) module when generating the mime database used by the server (and accessed via [`server.mime`](#server.mime)): * `override` \- an object hash that is merged into the built in mime information specified [here](https://github.com/jshttp/mime-db). Each key value pair represents a single mime object. Each override value must contain: * `key` \- the lower-cased mime-type string (e.g. `'application/javascript'`). * `value` \- an object following the specifications outlined [here](https://github.com/jshttp/mime-db#data-structure). Additional values include: * `type` \- specify the `type` value of result objects, defaults to `key`. * `predicate` \- method with signature `function(mime)` when this mime type is found in the database, this function will execute to allows customizations. const options = { mime: { override: { 'node/module': { source: 'iana', compressible: true, extensions: ['node', 'module', 'npm'], type: 'node/module' }, 'application/javascript': { source: 'iana', charset: 'UTF-8', compressible: true, extensions: ['js', 'javascript'], type: 'text/javascript' }, 'text/html': { predicate: function(mime) { if (someCondition) { mime.foo = 'test'; } else { mime.foo = 'bar'; } return mime; } } } } }; #### `server.options.operations` [](#-serveroptionsoperations) Default value: `{ cleanStop: true }`. Defines server handling of server operations: * `cleanStop` \- if `true`, the server keeps track of open connections and properly closes them when the server is stopped. Under normal load, this should not interfere with server performance. However, under severe load connection monitoring can consume additional resources and aggravate the situation. If the server is never stopped, or if it is forced to stop without waiting for open connection to close, setting this to `false` can save resources that are not being utilized anyway. Defaults to `true`. #### `server.options.plugins` [](#-serveroptionsplugins) Default value: `{}`. Plugin-specific configuration which can later be accessed via [`server.settings.plugins`](#server.settings). `plugins` is an object where each key is a plugin name and the value is the configuration. Note the difference between [`server.settings.plugins`](#server.settings) which is used to store static configuration values and [`server.plugins`](#server.plugins) which is meant for storing run-time state. #### `server.options.port` [](#-serveroptionsport) Default value: `0` (an ephemeral port). The TCP port the server will listen to. Defaults the next available port when the server is started (and assigned to [`server.info.port`](#server.info)). If `port` is a string containing a '/' character, it is used as a UNIX domain socket path. If it starts with '\\.\pipe', it is used as a Windows named pipe. #### `server.options.query` [](#-serveroptionsquery) Default value: `{}`. Defines server handling of the request path query component. ##### `server.options.query.parser` [](#-serveroptionsqueryparser) Default value: none. Sets a query parameters parser method using the signature `function(query)` where: * `query` \- an object containing the incoming [`request.query`](#request.query) parameters. * the method must return an object where each key is a parameter and matching value is the parameter value. If the method throws, the error is used as the response or returned when [`request.setUrl()`](#request.setUrl\(\)) is called. const Qs = require('qs'); const options = { query: { parser: (query) => Qs.parse(query) } }; #### `server.options.router` [](#-serveroptionsrouter) Default value: `{ isCaseSensitive: true, stripTrailingSlash: false }`. Controls how incoming request URIs are matched against the routing table: * `isCaseSensitive` \- determines whether the paths '/example' and '/EXAMPLE' are considered different resources. Defaults to `true`. * `stripTrailingSlash` \- removes trailing slashes on incoming paths. Defaults to `false`. #### `server.options.routes` [](#-serveroptionsroutes) Default value: none. A [route options](#route-options) object used as the default configuration for every route. #### `server.options.state` [](#-serveroptionsstate) Default value: { strictHeader: true, ignoreErrors: false, isSecure: true, isHttpOnly: true, isSameSite: 'Strict', isPartitioned: false, encoding: 'none' } Sets the default configuration for every state (cookie) set explicitly via [`server.state()`](#server.state\(\)) or implicitly (without definition) using the [state configuration](#server.state\(\)) object. #### `server.options.tls` [](#-serveroptionstls) Default value: none. Used to create an HTTPS connection. The `tls` object is passed unchanged to the node HTTPS server as described in the [node HTTPS documentation](https://nodejs.org/api/https.html#https_https_createserver_options_requestlistener). Set to `true` when passing a [`listener`](#server.options.listener) object that has been configured to use TLS directly. #### `server.options.uri` [](#-serveroptionsuri) Default value: constructed from runtime server information. The full public URI without the path (e.g. ''). If present, used as the server [`server.info.uri`](#server.info), otherwise constructed from the server settings. ### Server properties [](#server-properties) #### `server.app` [](#-serverapp) Access: read / write. Provides a safe place to store server-specific run-time application data without potential conflicts with the framework internals. The data can be accessed whenever the server is accessible. Initialized with an empty object. const server = Hapi.server(); server.app.key = 'value'; const handler = function (request, h) { return request.server.app.key; // 'value' }; #### `server.auth.api` [](#-serverauthapi) Access: authentication strategy specific. An object where each key is an authentication strategy name and the value is the exposed strategy API. Available only when the authentication scheme exposes an API by returning an `api` key in the object returned from its implementation function. const server = Hapi.server({ port: 80 }); const scheme = function (server, options) { return { api: { settings: { x: 5 } }, authenticate: function (request, h) { const authorization = request.headers.authorization; if (!authorization) { throw Boom.unauthorized(null, 'Custom'); } return h.authenticated({ credentials: { user: 'john' } }); } }; }; server.auth.scheme('custom', scheme); server.auth.strategy('default', 'custom'); console.log(server.auth.api.default.settings.x); // 5 #### `server.auth.settings.default` [](#-serverauthsettingsdefault) Access: read only. Contains the default authentication configuration if a default strategy was set via [`server.auth.default()`](#server.auth.default\(\)). #### `server.decorations` [](#-serverdecorations) Access: read only. Provides access to the decorations already applied to various framework interfaces. The object must not be modified directly, but only through [`server.decorate`](#server.decorate\(\)). Contains: * `request` \- decorations on the [request object](#request). * `response` \- decorations on the [response object](#response-object). * `toolkit` \- decorations on the [response toolkit](#response-toolkit). * `server` \- decorations on the [server](#server) object. const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); const success = function () { return this.response({ status: 'ok' }); }; server.decorate('toolkit', 'success', success); console.log(server.decorations.toolkit); // ['success'] #### `server.events` [](#-serverevents) Access: **podium** public interface. The server events emitter. Utilizes the [**podium**](https://hapi.dev/family/podium/api) with support for event criteria validation, channels, and filters. Use the following methods to interact with `server.events`: * [`server.event(events)`](#server.event\(\)) \- register application events. * [`server.events.emit(criteria, data)`](#server.events.emit\(\)) \- emit server events. * [`server.events.on(criteria, listener, context)`](#server.events.on\(\)) \- subscribe to all events. * [`server.events.once(criteria, listener, context)`](#server.events.once\(\)) \- subscribe to a single event. Other methods include: `server.events.removeListener(name, listener)`, `server.events.removeAllListeners(name)`, and `server.events.hasListeners(name)`. ##### `'log'` Event [](#-log-event) The `'log'` event type emits internal server events generated by the framework as well as application events logged with [`server.log()`](#server.log\(\)). The `'log'` event handler uses the function signature `function(event, tags)` where: * `event` \- an object with the following properties: * `timestamp` \- the event timestamp. * `tags` \- an array of tags identifying the event (e.g. `['error', 'http']`). * `channel` \- set to `'internal'` for internally generated events, otherwise `'app'` for events generated by [`server.log()`](#server.log\(\)). * `data` \- event-specific information. Available when event data was provided and is not an error. Errors are passed via `error`. * `error` \- the error object related to the event if applicable. Cannot appear together with `data`. * `tags` \- an object where each `event.tag` is a key and the value is `true`. Useful for quick identification of events. server.events.on('log', (event, tags) => { if (tags.error) { console.log(`Server error: ${event.error ? event.error.message : 'unknown'}`); } }); The internally generated events are (identified by their `tags`): * `load` \- logs the current server load measurements when the server rejects a request due to [high load](#server.options.load). The event data contains the process load metrics. * `connection` `client` `error` \- a `clientError` event was received from the HTTP or HTTPS listener. The event data is the error object received. ##### `'cachePolicy'` Event [](#-cachepolicy-event) The `'cachePolicy'` event type is emitted when a server [cache policy](https://hapi.dev/module/catbox/api#policy) is created via [`server.cache()`](#server.cache\(\)) or a [`server.method()`](#server.method\(\)) with caching enabled is registered. The `'cachePolicy'` event handler uses the function signature `function(cachePolicy, cache, segment)` where: * `cachePolicy` \- the catbox [cache policy](https://hapi.dev/module/catbox/api#policy). * `cache` \- the [cache provision](#server.options.cache) name used when the policy was created or `undefined` if the default cache was used. * `segment` \- the segment name used when the policy was created. server.events.on('cachePolicy', (cachePolicy, cache, segment) => { console.log(`New cache policy created using cache: ${cache === undefined ? 'default' : cache} and segment: ${segment}`); }); ##### `'request'` Event [](#-request-event) The `'request'` event type emits internal request events generated by the framework as well as application events logged with [`request.log()`](#request.log\(\)). The `'request'` event handler uses the function signature `function(request, event, tags)` where: * `request` \- the [request object](#request). * `event` \- an object with the following properties: * `timestamp` \- the event timestamp. * `tags` \- an array of tags identifying the event (e.g. `['error', 'http']`). * `channel` \- one of * `'app'` \- events generated by [`request.log()`](#request.log\(\)). * `'error'` \- emitted once per request if the response had a `500` status code. * `'internal'` \- internally generated events. * `request` \- the request [identifier](#request.info.id). * `data` \- event-specific information. Available when event data was provided and is not an error. Errors are passed via `error`. * `error` \- the error object related to the event if applicable. Cannot appear together with `data`. * `tags` \- an object where each `event.tag` is a key and the value is `true`. Useful for quick identification of events. server.events.on('request', (request, event, tags) => { if (tags.error) { console.log(`Request ${event.request} error: ${event.error ? event.error.message : 'unknown'}`); } }); To listen to only one of the channels, use the event criteria object: server.events.on({ name: 'request', channels: 'error' }, (request, event, tags) => { console.log(`Request ${event.request} failed`); }); The internally generated events are (identified by their `tags`): * `accept-encoding` `error` \- a request received contains an invalid Accept-Encoding header. * `auth` `unauthenticated` \- no authentication scheme included with the request. * `auth` `unauthenticated` `response` `{strategy}` \- the authentication strategy listed returned a non-error response (e.g. a redirect to a login page). * `auth` `unauthenticated` `error` `{strategy}` \- the request failed to pass the listed authentication strategy (invalid credentials). * `auth` `unauthenticated` `missing` `{strategy}` \- the request failed to pass the listed authentication strategy (no credentials found). * `auth` `unauthenticated` `try` `{strategy}` \- the request failed to pass the listed authentication strategy in `'try'` mode and will continue. * `auth` `scope` `error` \- the request authenticated but failed to meet the scope requirements. * `auth` `entity` `user` `error` \- the request authenticated but included an application entity when a user entity was required. * `auth` `entity` `app` `error` \- the request authenticated but included a user entity when an application entity was required. * `ext` `error` \- an `onPostResponse` extension handler errored. * `handler` `error` \- the route handler returned an error. Includes the execution duration and the error message. * `pre` `error` \- a pre method was executed and returned an error. Includes the execution duration, assignment key, and error. * `internal` `error` \- an HTTP 500 error response was assigned to the request. * `internal` `implementation` `error` \- an incorrectly implemented [lifecycle method](#lifecycle-methods). * `request` `error` `abort` \- the request aborted. * `request` `error` `close` \- the request closed prematurely. * `request` `error` \- the request stream emitted an error. Includes the error. * `request` `server` `timeout` `error` \- the request took too long to process by the server. Includes the timeout configuration value and the duration. * `state` `error` \- the request included an invalid cookie or cookies. Includes the cookies and error details. * `state` `response` `error` \- the response included an invalid cookie which prevented generating a valid header. Includes the error. * `payload` `error` \- failed processing the request payload. Includes the error. * `response` `error` \- failed writing the response to the client. Includes the error. * `response` `error` `close` \- failed writing the response to the client due to prematurely closed connection. * `response` `error` `aborted` \- failed writing the response to the client due to prematurely aborted connection. * `response` `error` `cleanup` \- failed freeing response resources. * `validation` `error` `{input}` \- input (i.e. payload, query, params, headers) validation failed. Includes the error. Only emitted when `failAction` is set to `'log'`. * `validation` `response` `error` \- response validation failed. Includes the error message. Only emitted when `failAction` is set to `'log'`. ##### `'response'` Event [](#-response-event) The `'response'` event type is emitted after the response is sent back to the client (or when the client connection closed and no response sent, in which case [`request.response`](#request.response) is `null`). A single event is emitted per request. The `'response'` event handler uses the function signature `function(request)` where: * `request` \- the [request object](#request). server.events.on('response', (request) => { console.log(`Response sent for request: ${request.info.id}`); }); ##### `'route'` Event [](#-route-event) The `'route'` event type is emitted when a route is added via [`server.route()`](#server.route\(\)). The `'route'` event handler uses the function signature `function(route)` where: * `route` \- the [route information](#request.route). The `route` object must not be modified. server.events.on('route', (route) => { console.log(`New route added: ${route.path}`); }); ##### `'start'` Event [](#-start-event) The `'start'` event type is emitted when the server is started using [`server.start()`](#server.start\(\)). The `'start'` event handler uses the function signature `function()`. server.events.on('start', () => { console.log('Server started'); }); ##### `'closing'` Event [](#-closing-event) The `'closing'` event type is emitted when the server is stopped using [`server.stop()`](#server.stop\(\)). It is triggered when incoming requests are no longer accepted but before all underlying active connections have been closed, and thus before the [`'stop'`](#server.events.stop) event is triggered. The `'closing'` event handler uses the function signature `function()`. server.events.on('closing', () => { console.log('Server is closing'); }); ##### `'stop'` Event [](#-stop-event) The `'stop'` event type is emitted when the server is stopped using [`server.stop()`](#server.stop\(\)). The `'stop'` event handler uses the function signature `function()`. server.events.on('stop', () => { console.log('Server stopped'); }); #### `server.info` [](#-serverinfo) Access: read only. An object containing information about the server where: * `id` \- a unique server identifier (using the format '{hostname}:{pid}:{now base36}'). * `created` \- server creation timestamp. * `started` \- server start timestamp (`0` when stopped). * `port` \- the connection port based on the following rules: * before the server has been started: the configured [`port`](#server.options.port) value. * after the server has been started: the actual port assigned when no port is configured or was set to `0`. * `host` \- The [`host`](#server.options.host) configuration value. * `address` \- the active IP address the connection was bound to after starting. Set to `undefined` until the server has been started or when using a non TCP port (e.g. UNIX domain socket). * `protocol` \- the protocol used: * `'http'` \- HTTP. * `'https'` \- HTTPS. * `'socket'` \- UNIX domain socket or Windows named pipe. * `uri` \- a string representing the connection (e.g. '' or 'socket:/unix/domain/socket/path'). Contains the [`uri`](#server.options.uri) value if set, otherwise constructed from the available settings. If no [`port`](#server.options.port) is configured or is set to `0`, the `uri` will not include a port component until the server is started. const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); console.log(server.info.port); // 80 #### `server.listener` [](#-serverlistener) Access: read only and listener public interface. The node HTTP server object. const Hapi = require('@hapi/hapi'); const SocketIO = require('socket.io'); const server = Hapi.server({ port: 80 }); const io = SocketIO.listen(server.listener); io.sockets.on('connection', (socket) => { socket.emit({ msg: 'welcome' }); }); #### `server.load` [](#-serverload) Access: read only. An object containing the process load metrics (when [`load.sampleInterval`](#server.options.load) is enabled): * `eventLoopDelay` \- event loop delay milliseconds. * `eventLoopUtilization` \- current event loop utilization value. * `heapUsed` \- V8 heap usage. * `rss` \- RSS memory usage. const Hapi = require('@hapi/hapi'); const server = Hapi.server({ load: { sampleInterval: 1000 } }); console.log(server.load.rss); #### `server.methods` [](#-servermethods) Access: read only. Server methods are functions registered with the server and used throughout the application as a common utility. Their advantage is in the ability to configure them to use the built-in cache and share across multiple request handlers without having to create a common module. `sever.methods` is an object which provides access to the methods registered via [server.method()](#server.method\(\)) where each server method name is an object property. const Hapi = require('@hapi/hapi'); const server = Hapi.server(); server.method('add', (a, b) => (a + b)); const result = server.methods.add(1, 2); // 3 #### `server.mime` [](#-servermime) Access: read only and **mimos** public interface. Provides access to the server MIME database used for setting content-type information. The object must not be modified directly but only through the [`mime`](#server.options.mime) server setting. const Hapi = require('@hapi/hapi'); const options = { mime: { override: { 'node/module': { source: 'steve', compressible: false, extensions: ['node', 'module', 'npm'], type: 'node/module' } } } }; const server = Hapi.server(options); console.log(server.mime.path('code.js').type) // 'application/javascript' console.log(server.mime.path('file.npm').type) // 'node/module' #### `server.plugins` [](#-serverplugins) Access: read / write. An object containing the values exposed by each registered plugin where each key is a plugin name and the values are the exposed properties by each plugin using [`server.expose()`](#server.expose\(\)). Plugins may set the value of the `server.plugins[name]` object directly or via the `server.expose()` method. exports.plugin = { name: 'example', register: function (server, options) { server.expose('key', 'value'); server.plugins.example.other = 'other'; console.log(server.plugins.example.key); // 'value' console.log(server.plugins.example.other); // 'other' } }; #### `server.realm` [](#-serverrealm) Access: read only. The realm object contains sandboxed server settings specific to each plugin or authentication strategy. When registering a plugin or an authentication scheme, a `server` object reference is provided with a new `server.realm` container specific to that registration. It allows each plugin to maintain its own settings without leaking and affecting other plugins. For example, a plugin can set a default file path for local resources without breaking other plugins' configured paths. When calling [`server.bind()`](#server.bind\(\)), the active realm's `settings.bind` property is set which is then used by routes and extensions added at the same level (server root or plugin). The `server.realm` object contains: * `modifiers` \- when the server object is provided as an argument to the plugin `register()` method, `modifiers` provides the registration preferences passed the [`server.register()`](#server.register\(\)) method and includes: * `route` \- routes preferences: * `prefix` \- the route path prefix used by any calls to [`server.route()`](#server.route\(\)) from the server. Note that if a prefix is used and the route path is set to `'/'`, the resulting path will not include the trailing slash. * `vhost` \- the route virtual host settings used by any calls to [`server.route()`](#server.route\(\)) from the server. * `parent` \- the realm of the parent server object, or `null` for the root server. * `plugin` \- the active plugin name (empty string if at the server root). * `pluginOptions` \- the plugin options passed at registration. * `plugins` \- plugin-specific state to be shared only among activities sharing the same active state. `plugins` is an object where each key is a plugin name and the value is the plugin state. * `settings` \- settings overrides: * `files.relativeTo` * `bind` The `server.realm` object should be considered read-only and must not be changed directly except for the `plugins` property which can be directly manipulated by each plugin, setting its properties inside `plugins[name]`. exports.register = function (server, options) { console.log(server.realm.modifiers.route.prefix); }; #### `server.registrations` [](#-serverregistrations) Access: read only. An object of the currently registered plugins where each key is a registered plugin name and the value is an object containing: * `version` \- the plugin version. * `name` \- the plugin name. * `options` \- (optional) options passed to the plugin during registration. #### `server.settings` [](#-serversettings) Access: read only. The server configuration object after defaults applied. const Hapi = require('@hapi/hapi'); const server = Hapi.server({ app: { key: 'value' } }); console.log(server.settings.app); // { key: 'value' } #### `server.states` [](#-serverstates) Access: read only and **statehood** public interface. The server cookies manager. #### `server.states.settings` [](#-serverstatessettings) Access: read only. The server cookies manager settings. The settings are based on the values configured in [`server.options.state`](#server.options.state). #### `server.states.cookies` [](#-serverstatescookies) Access: read only. An object containing the configuration of each cookie added via [`server.state()`](#server.state\(\)) where each key is the cookie name and value is the configuration object. #### `server.states.names` [](#-serverstatesnames) Access: read only. An array containing the names of all configured cookies. #### `server.type` [](#-servertype) Access: read only. A string indicating the listener type where: * `'socket'` \- UNIX domain socket or Windows named pipe. * `'tcp'` \- an HTTP listener. #### `server.version` [](#-serverversion) Access: read only. The **hapi** module version number. const Hapi = require('@hapi/hapi'); const server = Hapi.server(); console.log(server.version); // '17.0.0' ### `server.auth.default(options)` [](#-serverauthdefaultoptions) Sets a default strategy which is applied to every route where: * `options` \- one of: * a string with the default strategy name * an authentication configuration object using the same format as the [route `auth` handler options](#route.options.auth). Return value: none. The default does not apply when a route config specifies `auth` as `false`, or has an authentication strategy configured (contains the [`strategy`](#route.options.auth.strategy) or [`strategies`](#route.options.auth.strategies) authentication settings). Otherwise, the route authentication config is applied to the defaults. Note that if the route has authentication configured, the default only applies at the time of adding the route, not at runtime. This means that calling `server.auth.default()` after adding a route with some authentication config will have no impact on the routes added prior. However, the default will apply to routes added before `server.auth.default()` is called if those routes lack any authentication config. The default auth strategy configuration can be accessed via [`server.auth.settings.default`](#server.auth.settings.default). To obtain the active authentication configuration of a route, use `server.auth.lookup(request.route)`. const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); server.auth.scheme('custom', scheme); server.auth.strategy('default', 'custom'); server.auth.default('default'); server.route({ method: 'GET', path: '/', handler: function (request, h) { return request.auth.credentials.user; } }); ### `server.auth.scheme(name, scheme)` [](#-serverauthschemename-scheme) Registers an authentication scheme where: * `name` \- the scheme name. * `scheme` \- the method implementing the scheme with signature `function(server, options)` where: * `server` \- a reference to the server object the scheme is added to. Each auth strategy is given its own [`server.realm`](#server.realm) whose parent is the realm of the `server` in the call to [`server.auth.strategy()`](#server.auth.strategy\(\)). * `options` \- (optional) the scheme `options` argument passed to [`server.auth.strategy()`](#server.auth.strategy\(\)) when instantiation a strategy. Return value: none. The `scheme` function must return an [authentication scheme object](#authentication-scheme) when invoked. #### Authentication scheme [](#authentication-scheme) An authentication scheme is an object with the following properties: * `api` \- (optional) object which is exposed via the [`server.auth.api`](#server.auth.api) object. * `async authenticate(request, h)` \- (required) a [lifecycle method](#lifecycle-methods) function called for each incoming request configured with the authentication scheme. The method is provided with two special toolkit methods for returning an authenticated or an unauthenticate result: * [`h.authenticated()`](#h.authenticated\(\)) \- indicate request authenticated successfully. * [`h.unauthenticated()`](#h.unauthenticated\(\)) \- indicate request failed to authenticate. * `async payload(request, h)` \- (optional) a [lifecycle method](#lifecycle-methods) to authenticate the request payload. * `async response(request, h)` \- (optional) a [lifecycle method](#lifecycle-methods) to decorate the response with authentication headers before the response headers or payload is written. * `async verify(auth)` \- (optional) a method used to verify the authentication credentials provided are still valid (e.g. not expired or revoked after the initial authentication) where: * `auth` \- the [`request.auth`](#request.auth) object containing the `credentials` and `artifacts` objects returned by the scheme's `authenticate()` method. * the method throws an `Error` when the credentials passed are no longer valid (e.g. expired or revoked). Note that the method does not have access to the original request, only to the credentials and artifacts produced by the `authenticate()` method. * `options` \- (optional) an object with the following keys: * `payload` \- if `true`, requires payload validation as part of the scheme and forbids routes from disabling payload auth validation. Defaults to `false`. When the scheme `authenticate()` method implementation throws an error or calls [`h.unauthenticated()`](#h.unauthenticated\(\)), the specifics of the error affect whether additional authentication strategies will be attempted (if configured for the route). If the error includes a message, no additional strategies will be attempted. If the `err` does not include a message but does include the scheme name (e.g. `Boom.unauthorized(null, 'Custom')`), additional strategies will be attempted in the order of preference (defined in the route configuration). If authentication fails, the scheme names will be present in the 'WWW-Authenticate' header. When the scheme `payload()` method throws an error with a message, it means payload validation failed due to bad payload. If the error has no message but includes a scheme name (e.g. `Boom.unauthorized(null, 'Custom')`), authentication may still be successful if the route [`auth.payload`](#route.options.auth.payload) configuration is set to `'optional'`. const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); const scheme = function (server, options) { return { authenticate: function (request, h) { const req = request.raw.req; const authorization = req.headers.authorization; if (!authorization) { throw Boom.unauthorized(null, 'Custom'); } return h.authenticated({ credentials: { user: 'john' } }); } }; }; server.auth.scheme('custom', scheme); ### `server.auth.strategy(name, scheme, [options])` [](#-serverauthstrategyname-scheme-options) Registers an authentication strategy where: * `name` \- the strategy name. * `scheme` \- the scheme name (must be previously registered using [`server.auth.scheme()`](#server.auth.scheme\(\))). * `options` \- scheme options based on the scheme requirements. Return value: none. const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); server.auth.scheme('custom', scheme); server.auth.strategy('default', 'custom'); server.route({ method: 'GET', path: '/', options: { auth: 'default', handler: function (request, h) { return request.auth.credentials.user; } } }); ### `await server.auth.test(strategy, request)` [](#-await-serverauthteststrategy-request) Tests a request against an authentication strategy where: * `strategy` \- the strategy name registered with [`server.auth.strategy()`](#server.auth.strategy\(\)). * `request` \- the [request object](#request). Return value: an object containing the authentication `credentials` and `artifacts` if authentication was successful, otherwise throws an error. Note that the `test()` method does not take into account the route authentication configuration. It also does not perform payload authentication. It is limited to the basic strategy authentication execution. It does not include verifying scope, entity, or other route properties. const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); server.auth.scheme('custom', scheme); server.auth.strategy('default', 'custom'); server.route({ method: 'GET', path: '/', handler: async function (request, h) { try { const { credentials, artifacts } = await request.server.auth.test('default', request); return { status: true, user: credentials.name }; } catch (err) { return { status: false }; } } }); ### `await server.auth.verify(request)` [](#-await-serverauthverifyrequest) Verify a request's authentication credentials against an authentication strategy where: * `request` \- the [request object](#request). Return value: nothing if verification was successful, otherwise throws an error. Note that the `verify()` method does not take into account the route authentication configuration or any other information from the request other than the `request.auth` object. It also does not perform payload authentication. It is limited to verifying that the previously valid credentials are still valid (e.g. have not been revoked or expired). It does not include verifying scope, entity, or other route properties. const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); server.auth.scheme('custom', scheme); server.auth.strategy('default', 'custom'); server.route({ method: 'GET', path: '/', handler: async function (request, h) { try { const credentials = await request.server.auth.verify(request); return { status: true, user: credentials.name }; } catch (err) { return { status: false }; } } }); ### `server.bind(context)` [](#-serverbindcontext) Sets a global context used as the default bind object when adding a route or an extension where: * `context` \- the object used to bind `this` in [lifecycle methods](#lifecycle-methods) such as the [route handler](#route.options.handler) and [extension methods](#server.ext\(\)). The context is also made available as [`h.context`](#h.context). Return value: none. When setting a context inside a plugin, the context is applied only to methods set up by the plugin. Note that the context applies only to routes and extensions added after it has been set. Ignored if the method being bound is an arrow function. const handler = function (request, h) { return this.message; // Or h.context.message }; exports.plugin = { name: 'example', register: function (server, options) { const bind = { message: 'hello' }; server.bind(bind); server.route({ method: 'GET', path: '/', handler }); } }; ### `server.cache(options)` [](#-servercacheoptions) Provisions a cache segment within the server cache facility where: * `options` \- [**catbox** policy](https://hapi.dev/family/catbox/api#policy) configuration where: * `expiresIn` \- relative expiration expressed in the number of milliseconds since the item was saved in the cache. Cannot be used together with `expiresAt`. * `expiresAt` \- time of day expressed in 24h notation using the 'HH:MM' format, at which point all cache records expire. Uses local time. Cannot be used together with `expiresIn`. * `generateFunc` \- a function used to generate a new cache item if one is not found in the cache when calling `get()`. The method's signature is `async function(id, flags)` where: - `id` - the `id` string or object provided to the `get()` method. - `flags` - an object used to pass back additional flags to the cache where: - `ttl` - the cache ttl value in milliseconds. Set to `0` to skip storing in the cache. Defaults to the cache global policy. * `staleIn` \- number of milliseconds to mark an item stored in cache as stale and attempt to regenerate it when `generateFunc` is provided. Must be less than `expiresIn`. * `staleTimeout` \- number of milliseconds to wait before checking if an item is stale. * `generateTimeout` \- number of milliseconds to wait before returning a timeout error when the `generateFunc` function takes too long to return a value. When the value is eventually returned, it is stored in the cache for future requests. Required if `generateFunc` is present. Set to `false` to disable timeouts which may cause all `get()` requests to get stuck forever. * `generateOnReadError` \- if `false`, an upstream cache read error will stop the `cache.get()` method from calling the generate function and will instead pass back the cache error. Defaults to `true`. * `generateIgnoreWriteError` \- if `false`, an upstream cache write error when calling `cache.get()` will be passed back with the generated value when calling. Defaults to `true`. * `dropOnError` \- if `true`, an error or timeout in the `generateFunc` causes the stale value to be evicted from the cache. Defaults to `true`. * `pendingGenerateTimeout` \- number of milliseconds while `generateFunc` call is in progress for a given id, before a subsequent `generateFunc` call is allowed. Defaults to `0` (no blocking of concurrent `generateFunc` calls beyond `staleTimeout`). * `cache` \- the cache name configured in [`server.cache`](#server.options.cache). Defaults to the default cache. * `segment` \- string segment name, used to isolate cached items within the cache partition. When called within a plugin, defaults to '!name' where 'name' is the plugin name. When called within a server method, defaults to '#name' where 'name' is the server method name. Required when called outside of a plugin. * `shared` \- if `true`, allows multiple cache provisions to share the same segment. Default to `false`. Return value: a [**catbox** policy](https://hapi.dev/family/catbox/api#policy) object. const Hapi = require('@hapi/hapi'); async function example() { const server = Hapi.server({ port: 80 }); const cache = server.cache({ segment: 'countries', expiresIn: 60 * 60 * 1000 }); await cache.set('norway', { capital: 'oslo' }); const value = await cache.get('norway'); } ### `await server.cache.provision(options)` [](#-await-servercacheprovisionoptions) Provisions a server cache as described in [`server.cache`](#server.options.cache) where: * `options` \- same as the server [`cache`](#server.options.cache) configuration options. Return value: none. Note that if the server has been initialized or started, the cache will be automatically started to match the state of any other provisioned server cache. const Hapi = require('@hapi/hapi'); async function example() { const server = Hapi.server({ port: 80 }); await server.initialize(); await server.cache.provision({ provider: require('@hapi/catbox-memory'), name: 'countries' }); const cache = server.cache({ cache: 'countries', expiresIn: 60 * 60 * 1000 }); await cache.set('norway', { capital: 'oslo' }); const value = await cache.get('norway'); } ### `server.control(server)` [](#-servercontrolserver) Links another server to the initialize/start/stop state of the current server by calling the controlled server `initialize()`/`start()`/`stop()` methods whenever the current server methods are called, where: * `server` \- the **hapi** server object to be controlled. ### `server.decoder(encoding, decoder)` [](#-serverdecoderencoding-decoder) Registers a custom content decoding compressor to extend the built-in support for `'gzip'` and '`deflate`' where: * `encoding` \- the decoder name string. * `decoder` \- a function using the signature `function(options)` where `options` are the encoding specific options configured in the route [`payload.compression`](#route.options.payload.compression) configuration option, and the return value is an object compatible with the output of node's [`zlib.createGunzip()`](https://nodejs.org/api/zlib.html#zlib_zlib_creategunzip_options). Return value: none. const Zlib = require('zlib'); const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80, routes: { payload: { compression: { special: { chunkSize: 16 * 1024 } } } } }); server.decoder('special', (options) => Zlib.createGunzip(options)); ### `server.decorate(type, property, method, [options])` [](#-serverdecoratetype-property-method-options) Extends various framework interfaces with custom methods where: * `type` \- the interface being decorated. Supported types: * `'handler'` \- adds a new handler type to be used in [routes handlers](#route.options.handler). * `'request'` \- adds methods to the [Request object](#request). * `'response'` \- adds methods to the [Response object](#response-object). * `'server'` \- adds methods to the [Server](#server) object. * `'toolkit'` \- adds methods to the [response toolkit](#response-toolkit). * `property` \- the object decoration key name or symbol. * `method` \- the extension function or other value. * `options` \- (optional) supports the following optional settings: * `apply` \- when the `type` is `'request'`, if `true`, the `method` function is invoked using the signature `function(request)` where `request` is the current request object and the returned value is assigned as the decoration. * `extend` \- if `true`, overrides an existing decoration. The `method` must be a function with the signature `function(existing)` where: * `existing` \- is the previously set decoration method value. * must return the new decoration function or value. * cannot be used to extend handler decorations. Return value: none. const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); const success = function () { return this.response({ status: 'ok' }); }; server.decorate('toolkit', 'success', success); server.route({ method: 'GET', path: '/', handler: function (request, h) { return h.success(); } }); When registering a handler decoration, the `method` must be a function using the signature `function(route, options)` where: * `route` \- the [route information](#request.route). * `options` \- the configuration object provided in the handler config. const Hapi = require('@hapi/hapi'); async function example() { const server = Hapi.server({ host: 'localhost', port: 8000 }); // Defines new handler for routes on this server const handler = function (route, options) { return function (request, h) { return 'new handler: ' + options.msg; } }; server.decorate('handler', 'test', handler); server.route({ method: 'GET', path: '/', handler: { test: { msg: 'test' } } }); await server.start(); } The `method` function can have a `defaults` object or function property. If the property is set to an object, that object is used as the default route config for routes using this handler. If the property is set to a function, the function uses the signature `function(method)` and returns the route default configuration. const Hapi = require('@hapi/hapi'); const server = Hapi.server({ host: 'localhost', port: 8000 }); const handler = function (route, options) { return function (request, h) { return 'new handler: ' + options.msg; } }; // Change the default payload processing for this handler handler.defaults = { payload: { output: 'stream', parse: false } }; server.decorate('handler', 'test', handler); ### `server.dependency(dependencies, [after])` [](#-serverdependencydependencies-after) Used within a plugin to declare a required dependency on other [plugins](#plugins) required for the current plugin to operate (plugins listed must be registered before the server is initialized or started) where: * `dependencies` \- one of: * a single plugin name string. * an array of plugin name strings. * an object where each key is a plugin name and each matching value is a [version range string](https://www.npmjs.com/package/semver) which must match the registered plugin version. * `after` \- (optional) a function that is called after all the specified dependencies have been registered and before the server starts. The function is only called if the server is initialized or started. The function signature is `async function(server)` where: * `server` \- the server the `dependency()` method was called on. Return value: none. The `after` method is identical to setting a server extension point on `'onPreStart'`. If a circular dependency is detected, an exception is thrown (e.g. two plugins each has an `after` function to be called after the other). const after = function (server) { // Additional plugin registration logic }; exports.plugin = { name: 'example', register: function (server, options) { server.dependency('yar', after); } }; Dependencies can also be set via the plugin `dependencies` property (does not support setting `after`): exports.plugin = { name: 'test', version: '1.0.0', dependencies: { yar: '1.x.x' }, register: function (server, options) { } }; The `dependencies` configuration accepts one of: * a single plugin name string. * an array of plugin name strings. * an object where each key is a plugin name and each matching value is a [version range string](https://www.npmjs.com/package/semver) which must match the registered plugin version. ### `server.encoder(encoding, encoder)` [](#-serverencoderencoding-encoder) Registers a custom content encoding compressor to extend the built-in support for `'gzip'` and '`deflate`' where: * `encoding` \- the encoder name string. * `encoder` \- a function using the signature `function(options)` where `options` are the encoding specific options configured in the route [`compression`](#route.options.compression) option, and the return value is an object compatible with the output of node's [`zlib.createGzip()`](https://nodejs.org/api/zlib.html#zlib_zlib_creategzip_options). Return value: none. const Zlib = require('zlib'); const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80, routes: { compression: { special: { chunkSize: 16 * 1024 } } } }); server.encoder('special', (options) => Zlib.createGzip(options)); ### `server.event(events)` [](#-servereventevents) Register custom application events where: * `events` \- must be one of: * an event name string. * an event options object with the following optional keys (unless noted otherwise): * `name` \- the event name string (required). * `channels` \- a string or array of strings specifying the event channels available. Defaults to no channel restrictions (event updates can specify a channel or not). * `clone` \- if `true`, the `data` object passed to [`server.events.emit()`](#server.events.emit\(\)) is cloned before it is passed to the listeners (unless an override specified by each listener). Defaults to `false` (`data` is passed as-is). * `spread` \- if `true`, the `data` object passed to [`server.event.emit()`](#server.event.emit\(\)) must be an array and the `listener` method is called with each array element passed as a separate argument (unless an override specified by each listener). This should only be used when the emitted data structure is known and predictable. Defaults to `false` (`data` is emitted as a single argument regardless of its type). * `tags` \- if `true` and the `criteria` object passed to [`server.event.emit()`](#server.event.emit\(\)) includes `tags`, the tags are mapped to an object (where each tag string is the key and the value is `true`) which is appended to the arguments list at the end. A configuration override can be set by each listener. Defaults to `false`. * `shared` \- if `true`, the same event `name` can be registered multiple times where the second registration is ignored. Note that if the registration config is changed between registrations, only the first configuration is used. Defaults to `false` (a duplicate registration will throw an error). * an array containing any of the above. Return value: none. const Hapi = require('@hapi/hapi'); async function example() { const server = Hapi.server({ port: 80 }); server.event('test'); server.events.on('test', (update) => console.log(update)); await server.events.gauge('test', 'hello'); } ### `server.events.emit(criteria, data)` [](#-servereventsemitcriteria-data) Emits a custom application event to all the subscribed listeners where: * `criteria` \- the event update criteria which must be one of: * the event name string. * an object with the following optional keys (unless noted otherwise): * `name` \- the event name string (required). * `channel` \- the channel name string. * `tags` \- a tag string or array of tag strings. * `data` \- the value emitted to the subscribers. If `data` is a function, the function signature is `function()` and it called once to generate (return value) the actual data emitted to the listeners. If no listeners match the event, the `data` function is not invoked. Return value: none. Note that events must be registered before they can be emitted or subscribed to by calling [`server.event(events)`](#server.event\(\)). This is done to detect event name misspelling and invalid event activities. const Hapi = require('@hapi/hapi'); async function example() { const server = Hapi.server({ port: 80 }); server.event('test'); server.events.on('test', (update) => console.log(update)); server.events.emit('test', 'hello'); } ### `server.events.on(criteria, listener, context)` [](#-servereventsoncriteria-listener-context) Subscribe to an event where: * `criteria` \- the subscription criteria which must be one of: * event name string which can be any of the [built-in server events](#server.events) or a custom application event registered with [`server.event()`](#server.event\(\)). * a criteria object with the following optional keys (unless noted otherwise): * `name` \- (required) the event name string. * `channels` \- a string or array of strings specifying the event channels to subscribe to. If the event registration specified a list of allowed channels, the `channels` array must match the allowed channels. If `channels` are specified, event updates without any channel designation will not be included in the subscription. Defaults to no channels filter. * `clone` \- if `true`, the `data` object passed to [`server.event.emit()`](#server.event.emit\(\)) is cloned before it is passed to the `listener` method. Defaults to the event registration option (which defaults to `false`). * `count` \- a positive integer indicating the number of times the `listener` can be called after which the subscription is automatically removed. A count of `1` is the same as calling `server.events.once()`. Defaults to no limit. * `filter` \- the event tags (if present) to subscribe to which can be one of: * a tag string. * an array of tag strings. * an object with the following: * `tags` \- a tag string or array of tag strings. * `all` \- if `true`, all `tags` must be present for the event update to match the subscription. Defaults to `false` (at least one matching tag). * `spread` \- if `true`, and the `data` object passed to [`server.event.emit()`](#server.event.emit\(\)) is an array, the `listener` method is called with each array element passed as a separate argument. This should only be used when the emitted data structure is known and predictable. Defaults to the event registration option (which defaults to `false`). * `tags` \- if `true` and the `criteria` object passed to [`server.event.emit()`](#server.event.emit\(\)) includes `tags`, the tags are mapped to an object (where each tag string is the key and the value is `true`) which is appended to the arguments list at the end. Defaults to the event registration option (which defaults to `false`). * `listener` \- the handler method set to receive event updates. The function signature depends on the event argument, and the `spread` and `tags` options. * `context` \- an object that binds to the listener handler. Return value: none. const Hapi = require('@hapi/hapi'); async function example() { const server = Hapi.server({ port: 80 }); server.event('test'); server.events.on('test', (update) => console.log(update)); server.events.emit('test', 'hello'); } ### `server.events.once(criteria, listener, context)` [](#-servereventsoncecriteria-listener-context) Same as calling [`server.events.on()`](#server.events.on\(\)) with the `count` option set to `1`. Return value: none. const Hapi = require('@hapi/hapi'); async function example() { const server = Hapi.server({ port: 80 }); server.event('test'); server.events.once('test', (update) => console.log(update)); server.events.emit('test', 'hello'); server.events.emit('test', 'hello'); // Ignored } ### `await server.events.once(criteria)` [](#-await-servereventsoncecriteria) Same as calling [`server.events.on()`](#server.events.on\(\)) with the `count` option set to `1`. Return value: a promise that resolves when the event is emitted. const Hapi = require('@hapi/hapi'); async function example() { const server = Hapi.server({ port: 80 }); server.event('test'); const pending = server.events.once('test'); server.events.emit('test', 'hello'); const update = await pending; } ### `await server.events.gauge(criteria, data)` [](#-await-servereventsgaugecriteria-data) Behaves identically to [`server.events.emit()`](#server.events.emit\(\)), but also returns an array of the results of all the event listeners that run. The return value is that of `Promise.allSettled()`, where each item in the resulting array is `{ status: 'fulfilled', value }` in the case of a successful handler, or `{ status: 'rejected', reason }` in the case of a handler that throws. Please note that system errors such as a `TypeError` are not handled specially, and it's recommended to scrutinize any rejections using something like [bounce](https://hapi.dev/module/bounce/). ### `server.expose(key, value, [options])` [](#-serverexposekey-value-options) Used within a plugin to expose a property via [`server.plugins[name]`](#server.plugins) where: * `key` \- the key assigned ([`server.plugins[name][key]`](#server.plugins)). * `value` \- the value assigned. * `options` \- optional settings: * `scope` \- controls how to handle the presence of a plugin scope in the name (e.g. `@hapi/test`): * `false` \- the scope is removed (e.g. `@hapi/test` is changed to `test` under `server.plugins`). This is the default. * `true` \- the scope is retained as-is (e.g. `@hapi/test` is used as `server.plugins['@hapi/test']`). * `'underscore'` \- the scope is rewritten (e.g. `@hapi/test` is used as `server.plugins.hapi__test`). Return value: none. exports.plugin = name: 'example', register: function (server, options) { server.expose('util', () => console.log('something')); } }; ### `server.expose(obj)` [](#-serverexposeobj) Merges an object into to the existing content of [`server.plugins[name]`](#server.plugins) where: * `obj` \- the object merged into the exposed properties container. Return value: none. exports.plugin = { name: 'example', register: function (server, options) { server.expose({ util: () => console.log('something') }); } }; Note that all the properties of `obj` are deeply cloned into [`server.plugins[name]`](#server.plugins), so avoid using this method for exposing large objects that may be expensive to clone or singleton objects such as database client objects. Instead favor [`server.expose(key, value)`](#server.expose\(\)), which only copies a reference to `value`. ### `server.ext(events)` [](#-serverextevents) Registers an extension function in one of the [request lifecycle](#request-lifecycle) extension points where: * `events` \- an object or array of objects with the following: * `type` \- (required) the extension point event name. The available extension points include the [request extension points](#request-lifecycle) as well as the following server extension points: * `'onPreStart'` \- called before the connection listeners are started. * `'onPostStart'` \- called after the connection listeners are started. * `'onPreStop'` \- called before the connection listeners are stopped. * `'onPostStop'` \- called after the connection listeners are stopped. * `method` \- (required) a function or an array of functions to be executed at a specified point during request processing. The required extension function signature is: * server extension points: `async function(server)` where: * `server` \- the server object. * `this` \- the object provided via `options.bind` or the current active context set with [`server.bind()`](#server.bind\(\)). * request extension points: a [lifecycle method](#lifecycle-methods). * `options` \- (optional) an object with the following: * `before` \- a string or array of strings of plugin names this method must execute before (on the same event). Otherwise, extension methods are executed in the order added. * `after` \- a string or array of strings of plugin names this method must execute after (on the same event). Otherwise, extension methods are executed in the order added. * `bind` \- a context object passed back to the provided method (via `this`) when called. Ignored if the method is an arrow function. * `sandbox` \- if set to `'plugin'` when adding a [request extension points](#request-lifecycle) the extension is only added to routes defined by the current plugin. Not allowed when configuring route-level extensions, or when adding server extensions. Defaults to `'server'` which applies to any route added to the server the extension is added to. * `timeout` \- number of milliseconds to wait for the `method` to complete before returning a timeout error. Defaults to no timeout. Return value: none. const Hapi = require('@hapi/hapi'); async function example() { const server = Hapi.server({ port: 80 }); server.ext({ type: 'onRequest', method: function (request, h) { // Change all requests to '/test' request.setUrl('/test'); return h.continue; } }); server.route({ method: 'GET', path: '/test', handler: () => 'ok' }); await server.start(); // All requests will get routed to '/test' } ### `server.ext(event, [method, [options]])` [](#-serverextevent-method-options) Registers a single extension event using the same properties as used in [`server.ext(events)`](#server.ext\(\)), but passed as arguments. The `method` may be omitted (if `options` isn't present) or passed `null` which will cause the function to return a promise. The promise is resolved with the `request` object on the first invocation of the extension point. This is primarily used for writing tests without having to write custom handlers just to handle a single event. Return value: a promise if `method` is omitted, otherwise `undefined`. const Hapi = require('@hapi/hapi'); async function example() { const server = Hapi.server({ port: 80 }); server.ext('onRequest', function (request, h) { // Change all requests to '/test' request.setUrl('/test'); return h.continue; }); server.route({ method: 'GET', path: '/test', handler: () => 'ok' }); await server.start(); // All requests will get routed to '/test' } ### `await server.initialize()` [](#-await-serverinitialize) Initializes the server (starts the caches, finalizes plugin registration) but does not start listening on the connection port. Return value: none. Note that if the method fails and throws an error, the server is considered to be in an undefined state and should be shut down. In most cases it would be impossible to fully recover as the various plugins, caches, and other event listeners will get confused by repeated attempts to start the server or make assumptions about the healthy state of the environment. It is recommended to abort the process when the server fails to start properly. If you must try to resume after an error, call [`server.stop()`](#server.stop\(\)) first to reset the server state. const Hapi = require('@hapi/hapi'); const Hoek = require('@hapi/hoek'); async function example() { const server = Hapi.server({ port: 80 }); await server.initialize(); } ### `await server.inject(options)` [](#-await-serverinjectoptions) Injects a request into the server simulating an incoming HTTP request without making an actual socket connection. Injection is useful for testing purposes as well as for invoking routing logic internally without the overhead and limitations of the network stack. The method utilizes the [**shot**](https://hapi.dev/family/shot/api) module for performing injections, with some additional options and response properties: * `options` \- can be assigned a string with the requested URI, or an object with: * `method` \- (optional) the request HTTP method (e.g. `'POST'`). Defaults to `'GET'`. * `url` \- (required) the request URL. If the URI includes an authority (e.g. `'example.com:8080'`), it is used to automatically set an HTTP 'Host' header, unless one was specified in `headers`. * `authority` \- (optional) a string specifying the HTTP 'Host' header value. Only used if 'Host' is not specified in `headers` and the `url` does not include an authority component. Default is inferred from runtime server information. * `headers` \- (optional) an object with optional request headers where each key is the header name and the value is the header content. Defaults to no additions to the default **shot** headers. * `payload` \- (optional) an string, buffer or object containing the request payload. In case of an object it will be converted to a string for you. Defaults to no payload. Note that payload processing defaults to `'application/json'` if no 'Content-Type' header provided. * `auth` \- (optional) an object containing parsed authentication credentials where: * `strategy` \- (required) the authentication strategy name matching the provided credentials. * `credentials` \- (required) a credentials object containing authentication information. The `credentials` are used to bypass the default authentication strategies, and are validated directly as if they were received via an authentication scheme. * `artifacts` \- (optional) an artifacts object containing authentication artifact information. The `artifacts` are used to bypass the default authentication strategies, and are validated directly as if they were received via an authentication scheme. Defaults to no artifacts. * `payload` \- (optional) disables payload authentication when set to false. Only required when an authentication strategy requires payload authentication. Defaults to `true`. * `app` \- (optional) sets the initial value of `request.app`, defaults to `{}`. * `plugins` \- (optional) sets the initial value of `request.plugins`, defaults to `{}`. * `allowInternals` \- (optional) allows access to routes with `options.isInternal` set to `true`. Defaults to `false`. * `remoteAddress` \- (optional) sets the remote address for the incoming connection. * `simulate` \- (optional) an object with options used to simulate client request stream conditions for testing: * `error` \- if `true`, emits an `'error'` event after payload transmission (if any). Defaults to `false`. * `close` \- if `true`, emits a `'close'` event after payload transmission (if any). Defaults to `false`. * `end` \- if `false`, does not end the stream. Defaults to `true`. * `split` \- indicates whether the request payload will be split into chunks. Defaults to `undefined`, meaning payload will not be chunked. * `validate` \- (optional) if `false`, the `options` inputs are not validated. This is recommended for run-time usage of `inject()` to make it perform faster where input validation can be tested separately. Return value: a response object with the following properties: * `statusCode` \- the HTTP status code. * `headers` \- an object containing the headers set. * `payload` \- the response payload string. * `rawPayload` \- the raw response payload buffer. * `raw` \- an object with the injection request and response objects: * `req` \- the simulated node request object. * `res` \- the simulated node response object. * `result` \- the raw handler response (e.g. when not a stream or a view) before it is serialized for transmission. If not available, the value is set to `payload`. Useful for inspection and reuse of the internal objects returned (instead of parsing the response string). * `request` \- the [request object](#request). Throws a Boom error if the request processing fails. The partial response object is exposed on the `data` property. const Hapi = require('@hapi/hapi'); async function example() { const server = Hapi.server({ port: 80 }); server.route({ method: 'GET', path: '/', handler: () => 'Success!' }); const res = await server.inject('/'); console.log(res.result); // 'Success!' } ### `server.log(tags, [data, [timestamp]])` [](#-serverlogtags-data-timestamp) Logs server events that cannot be associated with a specific request. When called the server emits a `'log'` event which can be used by other listeners or [plugins](#plugins) to record the information or output to the console. The arguments are: * `tags` \- (required) a string or an array of strings (e.g. `['error', 'database', 'read']`) used to identify the event. Tags are used instead of log levels and provide a much more expressive mechanism for describing and filtering events. Any logs generated by the server internally include the `'hapi'` tag along with event-specific information. * `data` \- (optional) an message string or object with the application data being logged. If `data` is a function, the function signature is `function()` and it called once to generate (return value) the actual data emitted to the listeners. If no listeners match the event, the `data` function is not invoked. * `timestamp` \- (optional) an timestamp expressed in milliseconds. Defaults to `Date.now()` (now). Return value: none. const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); server.events.on('log', (event, tags) => { if (tags.error) { console.log(event); } }); server.log(['test', 'error'], 'Test event'); ### `server.lookup(id)` [](#-serverlookupid) Looks up a route configuration where: * `id` \- the [route identifier](#route.options.id). Return value: the [route information](#request.route) if found, otherwise `null`. const Hapi = require('@hapi/hapi'); const server = Hapi.server(); server.route({ method: 'GET', path: '/', options: { id: 'root', handler: () => 'ok' } }); const route = server.lookup('root'); ### `server.match(method, path, [host])` [](#-servermatchmethod-path-host) Looks up a route configuration where: * `method` \- the HTTP method (e.g. 'GET', 'POST'). * `path` \- the requested path (must begin with '/'). * `host` \- (optional) hostname (to match against routes with `vhost`). Return value: the [route information](#request.route) if found, otherwise `null`. const Hapi = require('@hapi/hapi'); const server = Hapi.server(); server.route({ method: 'GET', path: '/', options: { id: 'root', handler: () => 'ok' } }); const route = server.match('get', '/'); ### `server.method(name, method, [options])` [](#-servermethodname-method-options) Registers a [server method](#server.methods) where: * `name` \- a unique method name used to invoke the method via [`server.methods[name]`](#server.method). * `method` \- the method function with a signature `async function(...args, [flags])` where: * `...args` \- the method function arguments (can be any number of arguments or none). * `flags` \- when caching is enabled, an object used to set optional method result flags. This parameter is provided automatically and can only be accessed/modified within the method function. It cannot be passed as an argument. * `ttl` \- `0` if result is valid but cannot be cached. Defaults to cache policy. * `options` \- (optional) configuration object: * `bind` \- a context object passed back to the method function (via `this`) when called. Defaults to active context (set via [`server.bind()`](#server.bind\(\)) when the method is registered. Ignored if the method is an arrow function. * `cache` \- the same cache configuration used in [`server.cache()`](#server.cache\(\)). The `generateTimeout` option is required, and the `generateFunc` options is not allowed. * `generateKey` \- a function used to generate a unique key (for caching) from the arguments passed to the method function (the `flags` argument is not passed as input). The server will automatically generate a unique key if the function's arguments are all of types `'string'`, `'number'`, or `'boolean'`. However if the method uses other types of arguments, a key generation function must be provided which takes the same arguments as the function and returns a unique string (or `null` if no key can be generated). Return value: none. Method names can be nested (e.g. `utils.users.get`) which will automatically create the full path under [`server.methods`](#server.methods) (e.g. accessed via `server.methods.utils.users.get`). When configured with caching enabled, `server.methods[name].cache` is assigned an object with the following properties and methods: \- `await drop(...args)` \- a function that can be used to clear the cache for a given key. \- `stats` \- an object with cache statistics, see **catbox** for stats documentation. Simple arguments example: const Hapi = require('@hapi/hapi'); async function example() { const server = Hapi.server({ port: 80 }); const add = (a, b) => (a + b); server.method('sum', add, { cache: { expiresIn: 2000, generateTimeout: 100 } }); console.log(await server.methods.sum(4, 5)); // 9 } Object argument example: const Hapi = require('@hapi/hapi'); async function example() { const server = Hapi.server({ port: 80 }); const addArray = function (array) { let sum = 0; array.forEach((item) => { sum += item; }); return sum; }; const options = { cache: { expiresIn: 2000, generateTimeout: 100 }, generateKey: (array) => array.join(',') }; server.method('sumObj', addArray, options); console.log(await server.methods.sumObj([5, 6])); // 11 } ### `server.method(methods)` [](#-servermethodmethods) Registers a server method function as described in [`server.method()`](#server.method\(\)) using a configuration object where: * `methods` \- an object or an array of objects where each one contains: * `name` \- the method name. * `method` \- the method function. * `options` \- (optional) settings. Return value: none. const add = function (a, b) { return a + b; }; server.method({ name: 'sum', method: add, options: { cache: { expiresIn: 2000, generateTimeout: 100 } } }); ### `server.path(relativeTo)` [](#-serverpathrelativeto) Sets the path prefix used to locate static resources (files and view templates) when relative paths are used where: * `relativeTo` \- the path prefix added to any relative file path starting with `'.'`. Return value: none. Note that setting a path within a plugin only applies to resources accessed by plugin methods. If no path is set, the server default [route configuration](#server.options.routes) [`files.relativeTo`](#route.options.files) settings is used. The path only applies to routes added after it has been set. exports.plugin = { name: 'example', register: function (server, options) { // Assuming the Inert plugin was registered previously server.path(__dirname + '../static'); server.route({ path: '/file', method: 'GET', handler: { file: './test.html' } }); } }; ### `await server.register(plugins, [options])` [](#-await-serverregisterplugins-options) Registers a plugin where: * `plugins` \- one or an array of: * a [plugin object](#plugins). * an object with the following: * `plugin` \- a [plugin object](#plugins). * `options` \- (optional) options passed to the plugin during registration. * `once`, `routes` \- (optional) plugin-specific registration options as defined below. * `options` \- (optional) registration options (different from the options passed to the registration function): * `once` \- if `true`, subsequent registrations of the same plugin are skipped without error. Cannot be used with plugin options. Defaults to `false`. If not set to `true`, an error will be thrown the second time a plugin is registered on the server. * `routes` \- modifiers applied to each route added by the plugin: * `prefix` \- string added as prefix to any route path (must begin with `'/'`). If a plugin registers a child plugin the `prefix` is passed on to the child or is added in front of the child-specific prefix. * `vhost` \- virtual host string (or array of strings) applied to every route. The outer-most `vhost` overrides the any nested configuration. Return value: a reference to the `server`. async function example() { await server.register({ plugin: require('plugin_name'), options: { message: 'hello' } }); } ### `server.route(route)` [](#-serverrouteroute) Adds a route where: * `route` \- a route configuration object or an array of configuration objects where each object contains: * `path` \- (required) the absolute path used to match incoming requests (must begin with '/'). Incoming requests are compared to the configured paths based on the server's [`router`](#server.options.router) configuration. The path can include named parameters enclosed in `{}` which will be matched against literal values in the request as described in [Path parameters](#path-parameters). * `method` \- (required) the HTTP method. Typically one of 'GET', 'POST', 'PUT', 'PATCH', 'DELETE', or 'OPTIONS'. Any HTTP method is allowed, except for 'HEAD'. Use `'*'` to match against any HTTP method (only when an exact match was not found, and any match with a specific method will be given a higher priority over a wildcard match). Can be assigned an array of methods which has the same result as adding the same route with different methods manually. * `vhost` \- (optional) a domain string or an array of domain strings for limiting the route to only requests with a matching host header field. Matching is done against the hostname part of the header only (excluding the port). Defaults to all hosts. * `handler` \- (required when [`handler`](#route.options.handler) is not set) the route handler function called to generate the response after successful authentication and validation. * `options` \- additional [route options](#route-options). The `options` value can be an object or a function that returns an object using the signature `function(server)` where `server` is the server the route is being added to and `this` is bound to the current [realm](#server.realm)'s `bind` option. * `rules` \- route custom rules object. The object is passed to each rules processor registered with [`server.rules()`](#server.rules\(\)). Cannot be used if [`route.options.rules`](#route.options.rules) is defined. Return value: none. Note that the `options` object is deeply cloned (with the exception of `bind` which is shallowly copied) and cannot contain any values that are unsafe to perform deep copy on. const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); // Handler in top level server.route({ method: 'GET', path: '/status', handler: () => 'ok' }); // Handler in config const user = { cache: { expiresIn: 5000 }, handler: function (request, h) { return { name: 'John' }; } }; server.route({ method: 'GET', path: '/user', options: user }); // An array of routes server.route([ { method: 'GET', path: '/1', handler: function (request, h) { return 'ok'; } }, { method: 'GET', path: '/2', handler: function (request, h) { return 'ok'; } } ]); #### Path parameters [](#path-parameters) Parameterized paths are processed by matching the named parameters to the content of the incoming request path at that path segment. For example, `'/book/{id}/cover'` will match `'/book/123/cover'` and `request.params.id` will be set to `'123'`. Each path segment (everything between the opening `'/'` and the closing `'/'` unless it is the end of the path) can only include one named parameter. A parameter can cover the entire segment (`'/{param}'`) or part of the segment (`'/file.{ext}'`). A path parameter may only contain letters, numbers and underscores, e.g. `'/{file-name}'` is invalid and `'/{file_name}'` is valid. An optional `'?'` suffix following the parameter name indicates an optional parameter (only allowed if the parameter is at the ends of the path or only covers part of the segment as in `'/a{param?}/b'`). For example, the route `'/book/{id?}'` matches `'/book/'` with the value of `request.params.id` set to an empty string `''`. const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); const getAlbum = function (request, h) { return 'You asked for ' + (request.params.song ? request.params.song + ' from ' : '') + request.params.album; }; server.route({ path: '/{album}/{song?}', method: 'GET', handler: getAlbum }); In addition to the optional `?` suffix, a parameter name can also specify the number of matching segments using the `*` suffix, followed by a number greater than 1. If the number of expected parts can be anything, then use `*` without a number (matching any number of segments can only be used in the last path segment). const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); const getPerson = function (request, h) { const nameParts = request.params.name.split('/'); return { first: nameParts[0], last: nameParts[1] }; }; server.route({ path: '/person/{name*2}', // Matches '/person/john/doe' method: 'GET', handler: getPerson }); #### Path matching order [](#path-matching-order) The router iterates through the routing table on each incoming request and executes the first (and only the first) matching route. Route matching is done based on the combination of the request path and the HTTP verb (e.g. 'GET, 'POST'). The query is excluded from the routing logic. Requests are matched in a deterministic order where the order in which routes are added does not matter. Routes are matched based on the specificity of the route which is evaluated at each segment of the incoming request path. Each request path is split into its segment (the parts separated by `'/'`). The segments are compared to the routing table one at a time and are matched against the most specific path until a match is found. If no match is found, the next match is tried. When matching routes, string literals (no path parameter) have the highest priority, followed by mixed parameters (`'/a{p}b'`), parameters (`'/{p}'`), and then wildcard (`/{p*}`). Note that mixed parameters are slower to compare as they cannot be hashed and require an array iteration over all the regular expressions representing the various mixed parameter at each routing table node. #### Catch all route [](#catch-all-route) If the application needs to override the default Not Found (404) error response, it can add a catch-all route for a specific method or all methods. Only one catch-all route can be defined. const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); const handler = function (request, h) { return h.response('The page was not found').code(404); }; server.route({ method: '*', path: '/{p*}', handler }); ### `server.rules(processor, [options])` [](#-serverrulesprocessor-options) Defines a route rules processor for converting route rules object into route configuration where: * `processor` \- a function using the signature `function(rules, info)` where: * `rules` \- the [custom object](#route.options.rules) defined in your routes configuration for you to use its values. * `info` \- an object with the following properties: * `method` \- the route method. * `path` \- the route path. * `vhost` \- the route virtual host (if any defined). * returns a route config object. * `options` \- optional settings: * `validate` \- rules object validation: * `schema` \- **joi** schema. * `options` \- optional **joi** validation options. Defaults to `{ allowUnknown: true }`. Note that the root server and each plugin server instance can only register one rules processor. If a route is added after the rules are configured, it will not include the rules config. Routes added by plugins apply the rules to each of the parent realms' rules from the root to the route's realm. This means the processor defined by the plugin overrides the config generated by the root processor if they overlap. Similarly, the route's own config overrides the config produced by the rules processors. const validateSchema = { auth: Joi.string(), myCustomPre: Joi.array().min(2).items(Joi.string()), payload: Joi.object() }; const myPreHelper = (name) => { return { method: (request, h) => { return `hello ${name || 'world'}!`; }, assign: 'myPreHelper' }; }; const processor = (rules, info) => { if (!rules) { return null; } const options = {}; if (rules.auth) { options.auth = { strategy: rules.auth, validate: { entity: 'user' } }; } if (rules.myCustomPre) { options.pre = [ myPreHelper(...rules.myCustomPre) ]; } if (rules.payload) { options.validate = { payload: Joi.object(rules.payload) }; } return options; }; server.rules(processor, { validate: { schema: validateSchema } }); server.route({ method: 'GET', path: '/', rules: { auth: 'jwt', myCustomPre: ['arg1', 'arg2'], payload: { a: Joi.boolean(), b: Joi.string() } }, options: { id: 'my-route' } }); ### `await server.start()` [](#-await-serverstart) Starts the server by listening for incoming requests on the configured port (unless the connection was configured with [`autoListen`](#server.options.autoListen) set to `false`). Return value: none. Note that if the method fails and throws an error, the server is considered to be in an undefined state and should be shut down. In most cases it would be impossible to fully recover as the various plugins, caches, and other event listeners will get confused by repeated attempts to start the server or make assumptions about the healthy state of the environment. It is recommended to abort the process when the server fails to start properly. If you must try to resume after an error, call [`server.stop()`](#server.stop\(\)) first to reset the server state. If a started server is started again, the second call to `server.start()` is ignored. No events will be emitted and no extension points invoked. const Hapi = require('@hapi/hapi'); async function example() { const server = Hapi.server({ port: 80 }); await server.start(); console.log('Server started at: ' + server.info.uri); } ### `server.state(name, [options])` [](#-serverstatename-options) [HTTP state management](https://tools.ietf.org/html/rfc6265) uses client cookies to persist a state across multiple requests. Registers a cookie definitions where: * `name` \- the cookie name string. * `options` \- are the optional cookie settings: * `ttl` \- time-to-live in milliseconds. Defaults to `null` (session time-life - cookies are deleted when the browser is closed). * `isSecure` \- sets the 'Secure' flag. Defaults to `true`. * `isHttpOnly` \- sets the 'HttpOnly' flag. Defaults to `true`. * `isSameSite` \- sets the ['SameSite' flag](https://www.owasp.org/index.php/SameSite). The value must be one of: * `false` \- no flag. * `'Strict'` \- sets the value to `'Strict'` (this is the default value). * `'Lax'` \- sets the value to `'Lax'`. * `'None'` \- sets the value to `'None'`. * `isPartitioned` \- sets the ['Partitioned' flag](https://developers.google.com/privacy-sandbox/3pcd/chips). Defaults to `false`. Requires `isSecure` to be `true` and `isSameSite` to be `'None'`. * `path` \- the path scope. Defaults to `null` (no path). * `domain` \- the domain scope. Defaults to `null` (no domain). * `autoValue` \- if present and the cookie was not received from the client or explicitly set by the route handler, the cookie is automatically added to the response with the provided value. The value can be a function with signature `async function(request)` where: * `request` \- the [request object](#request). * `encoding` \- encoding performs on the provided value before serialization. Options are: * `'none'` \- no encoding. When used, the cookie value must be a string. This is the default value. * `'base64'` \- string value is encoded using Base64. * `'base64json'` \- object value is JSON-stringified then encoded using Base64. * `'form'` \- object value is encoded using the _x-www-form-urlencoded_ method. * `'iron'` \- Encrypts and sign the value using [**iron**](https://hapi.dev/family/iron/api). * `sign` \- an object used to calculate an HMAC for cookie integrity validation. This does not provide privacy, only a mean to verify that the cookie value was generated by the server. Redundant when `'iron'` encoding is used. Options are: * `integrity` \- algorithm options. Defaults to [`require('iron').defaults.integrity`](https://hapi.dev/family/iron/api/#options). * `password` \- password used for HMAC key generation (must be at least 32 characters long). * `password` \- password used for `'iron'` encoding (must be at least 32 characters long). * `iron` \- options for `'iron'` encoding. Defaults to [`require('iron').defaults`](https://hapi.dev/family/iron/api/#options). * `ignoreErrors` \- if `true`, errors are ignored and treated as missing cookies. * `clearInvalid` \- if `true`, automatically instruct the client to remove invalid cookies. Defaults to `false`. * `strictHeader` \- if `false`, allows any cookie value including values in violation of [RFC 6265](https://tools.ietf.org/html/rfc6265). Defaults to `true`. * `passThrough` \- used by proxy plugins (e.g. [**h2o2**](https://hapi.dev/family/h2o2/api)). * `contextualize` \- a function using the signature `async function(definition, request)` used to override a request-specific cookie settings where: * `definition` \- a copy of the `options` to be used for formatting the cookie that can be manipulated by the function to customize the request cookie header. Note that changing the `definition.contextualize` property will be ignored. * `request` \- the current request object. Return value: none. State defaults can be modified via the [server.options.state](#server.options.state) configuration option. const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); // Set cookie definition server.state('session', { ttl: 24 * 60 * 60 * 1000, // One day isSecure: true, path: '/', encoding: 'base64json' }); // Set state in route handler const handler = function (request, h) { let session = request.state.session; if (!session) { session = { user: 'joe' }; } session.last = Date.now(); return h.response('Success').state('session', session); }; Registered cookies are automatically parsed when received. Parsing rules depends on the route [`state.parse`](#route.options.state) configuration. If an incoming registered cookie fails parsing, it is not included in [`request.state`](#request.state), regardless of the [`state.failAction`](#route.options.state.failAction) setting. When [`state.failAction`](#route.options.state.failAction) is set to `'log'` and an invalid cookie value is received, the server will emit a [`'request'` event](#server.events.request). To capture these errors subscribe to the `'request'` event on the `'internal'` channel and filter on `'error'` and `'state'` tags: const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); server.events.on({ name: 'request', channels: 'internal' }, (request, event, tags) => { if (tags.error && tags.state) { console.error(event); } }); ### `server.states.add(name, [options])` [](#-serverstatesaddname-options) Access: read only. Same as calling [`server.state()`](#server.state\(\)). ### `await server.states.format(cookies)` [](#-await-serverstatesformatcookies) Formats an HTTP 'Set-Cookie' header based on the [`server.options.state`](#server.options.state) where: * `cookies` \- a single object or an array of object where each contains: * `name` \- the cookie name. * `value` \- the cookie value. * `options` \- cookie configuration to override the server settings. Return value: a header string. Note that this utility uses the server configuration but does not change the server state. It is provided for manual cookie formatting (e.g. when headers are set manually). ### `await server.states.parse(header)` [](#-await-serverstatesparseheader) Parses an HTTP 'Cookies' header based on the [`server.options.state`](#server.options.state) where: * `header` \- the HTTP header. Return value: an object where each key is a cookie name and value is the parsed cookie. Note that this utility uses the server configuration but does not change the server state. It is provided for manual cookie parsing (e.g. when server parsing is disabled). ### `await server.stop([options])` [](#-await-serverstopoptions) Stops the server's listener by refusing to accept any new connections or requests (existing connections will continue until closed or timeout), where: * `options` \- (optional) object with: * `timeout` \- sets the timeout in millisecond before forcefully terminating any open connections that arrived before the server stopped accepting new connections. The timeout only applies to waiting for existing connections to close, and not to any [`'onPreStop'` or `'onPostStop'` server extensions](#server.ext.args\(\)) which can delay or block the stop operation indefinitely. Ignored if [`server.options.operations.cleanStop`](#server.options.operations) is `false`. Note that if the server is set as a [group controller](#server.control\(\)), the timeout is per controlled server and the controlling server itself. Defaults to `5000` (5 seconds). Return value: none. const Hapi = require('@hapi/hapi'); async function example() { const server = Hapi.server({ port: 80 }); await server.start(); await server.stop({ timeout: 60 * 1000 }); console.log('Server stopped'); } ### `server.table([host])` [](#-servertablehost) Returns a copy of the routing table where: * `host` \- (optional) host to filter routes matching a specific virtual host. Defaults to all virtual hosts. Return value: an array of routes where each route contains: * `settings` \- the route config with defaults applied. * `method` \- the HTTP method in lower case. * `path` \- the route path. const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); server.route({ method: 'GET', path: '/example', handler: () => 'ok' }); const table = server.table(); ### `server.validator(validator)` [](#-servervalidatorvalidator) Registers a server validation module used to compile raw validation rules into validation schemas for all routes where: * `validator` \- the validation module (e.g. **joi**). Return value: none. Note: the validator is only used when validation rules are not pre-compiled schemas. When a validation rules is a function or schema object, the rule is used as-is and the validator is not used. When setting a validator inside a plugin, the validator is only applied to routes set up by the plugin and plugins registered by it. const Hapi = require('@hapi/hapi'); const Joi = require('joi'); async function example() { const server = Hapi.server({ port: 80 }); server.validator(Joi); } ## Route options [](#route-options) Each route can be customized to change the default behavior of the request lifecycle. ### `route.options.app` [](#-routeoptionsapp) Application-specific route configuration state. Should not be used by [plugins](#plugins) which should use `options.plugins[name]` instead. ### `route.options.auth` [](#-routeoptionsauth) Route authentication configuration. Value can be: * `false` to disable authentication if a default strategy is set. * a string with the name of an authentication strategy registered with [`server.auth.strategy()`](#server.auth.strategy\(\)). The strategy will be set to `'required'` mode. * an [authentication configuration object](#authentication-options). #### `route.options.auth.access` [](#-routeoptionsauthaccess) Default value: none. An object or array of objects specifying the route access rules. Each rule is evaluated against an incoming request and access is granted if at least one of the rules matches. Each rule object must include at least one of [`scope`](#route.options.auth.access.scope) or [`entity`](#route.options.auth.access.entity). #### `route.options.auth.access.scope` [](#-routeoptionsauthaccessscope) Default value: `false` (no scope requirements). The application scope required to access the route. Value can be a scope string or an array of scope strings. When authenticated, the credentials object `scope` property must contain at least one of the scopes defined to access the route. If a scope string begins with a `+` character, that scope is required. If a scope string begins with a `!` character, that scope is forbidden. For example, the scope `['!a', '+b', 'c', 'd']` means the incoming request credentials' `scope` must not include 'a', must include 'b', and must include one of 'c' or 'd'. You may also access properties on the request object (`query`, `params`, `payload`, and `credentials`) to populate a dynamic scope by using the '{' and '}' characters around the property name, such as `'user-{params.id}'`. #### `route.options.auth.access.entity` [](#-routeoptionsauthaccessentity) Default value: `'any'`. The required authenticated entity type. If set, must match the `entity` value of the request authenticated credentials. Available values: * `'any'` \- the authentication can be on behalf of a user or application. * `'user'` \- the authentication must be on behalf of a user which is identified by the presence of a `'user'` attribute in the `credentials` object returned by the authentication strategy. * `'app'` \- the authentication must be on behalf of an application which is identified by the lack of presence of a `user` attribute in the `credentials` object returned by the authentication strategy. #### `route.options.auth.mode` [](#-routeoptionsauthmode) Default value: `'required'`. The authentication mode. Available values: * `'required'` \- authentication is required. * `'optional'` \- authentication is optional - the request must include valid credentials or no credentials at all. * `'try'` \- similar to `'optional'`, any request credentials are attempted authentication, but if the credentials are invalid, the request proceeds regardless of the authentication error. #### `route.options.auth.payload` [](#-routeoptionsauthpayload) Default value: `false`, unless the scheme requires payload authentication. If set, the incoming request payload is authenticated after it is processed. Requires a strategy with payload authentication support (e.g. [Hawk](https://hapi.dev/family/hawk/api)). Cannot be set to a value other than `'required'` when the scheme sets the authentication `options.payload` to `true`. Available values: * `false` \- no payload authentication. * `'required'` \- payload authentication required. * `'optional'` \- payload authentication performed only when the client includes payload authentication information (e.g. `hash` attribute in Hawk). #### `route.options.auth.strategies` [](#-routeoptionsauthstrategies) Default value: the default strategy set via [`server.auth.default()`](#server.auth.default\(\)). An array of string strategy names in the order they should be attempted. Cannot be used together with [`strategy`](#route.options.auth.strategy). #### `route.options.auth.strategy` [](#-routeoptionsauthstrategy) Default value: the default strategy set via [`server.auth.default()`](#server.auth.default\(\)). A string strategy names. Cannot be used together with [`strategies`](#route.options.auth.strategies). ### `route.options.bind` [](#-routeoptionsbind) Default value: `null`. An object passed back to the provided `handler` (via `this`) when called. Ignored if the method is an arrow function. ### `route.options.cache` [](#-routeoptionscache) Default value: `{ privacy: 'default', statuses: [200], otherwise: 'no-cache' }`. If the route method is 'GET', the route can be configured to include HTTP caching directives in the response. Caching can be customized using an object with the following options: * `privacy` \- determines the privacy flag included in client-side caching using the 'Cache-Control' header. Values are: * `'default'` \- no privacy flag. * `'public'` \- mark the response as suitable for public caching. * `'private'` \- mark the response as suitable only for private caching. * `expiresIn` \- relative expiration expressed in the number of milliseconds since the item was saved in the cache. Cannot be used together with `expiresAt`. * `expiresAt` \- time of day expressed in 24h notation using the 'HH:MM' format, at which point all cache records for the route expire. Cannot be used together with `expiresIn`. * `statuses` \- an array of HTTP response status code numbers (e.g. `200`) which are allowed to include a valid caching directive. * `otherwise` \- a string with the value of the 'Cache-Control' header when caching is disabled. The default `Cache-Control: no-cache` header can be disabled by setting `cache` to `false`. ### `route.options.compression` [](#-routeoptionscompression) An object where each key is a content-encoding name and each value is an object with the desired encoder settings. Note that decoder settings are set in [`compression`](#route.options.payload.compression). ### `route.options.cors` [](#-routeoptionscors) Default value: `false` (no CORS headers). The [Cross-Origin Resource Sharing](https://www.w3.org/TR/cors/) protocol allows browsers to make cross-origin API calls. CORS is required by web applications running inside a browser which are loaded from a different domain than the API server. To enable, set `cors` to `true`, or to an object with the following options: * `origin` \- an array of allowed origin servers strings ('Access-Control-Allow-Origin'). The array can contain any combination of fully qualified origins along with origin strings containing a wildcard `'*'` character, or a single `'*'` origin string. If set to `'ignore'`, any incoming Origin header is ignored (present or not) and the 'Access-Control-Allow-Origin' header is set to `'*'`. Defaults to any origin `['*']`. * `maxAge` \- number of seconds the browser should cache the CORS response ('Access-Control-Max-Age'). The greater the value, the longer it will take before the browser checks for changes in policy. Defaults to `86400` (one day). * `headers` \- a strings array of allowed headers ('Access-Control-Allow-Headers'). Defaults to `['Accept', 'Authorization', 'Content-Type', 'If-None-Match']`. * `additionalHeaders` \- a strings array of additional headers to `headers`. Use this to keep the default headers in place. * `exposedHeaders` \- a strings array of exposed headers ('Access-Control-Expose-Headers'). Defaults to `['WWW-Authenticate', 'Server-Authorization']`. * `additionalExposedHeaders` \- a strings array of additional headers to `exposedHeaders`. Use this to keep the default headers in place. * `credentials` \- if `true`, allows user credentials to be sent ('Access-Control-Allow-Credentials'). Defaults to `false`. * `preflightStatusCode` \- the status code used for CORS preflight responses, either `200` or `204`. Defaults to `200`. ### `route.options.description` [](#-routeoptionsdescription) Default value: none. Route description used for generating documentation (string). This setting is not available when setting server route defaults using [`server.options.routes`](#server.options.routes). ### `route.options.ext` [](#-routeoptionsext) Default value: none. Route-level [request extension points](#request-lifecycle) by setting the option to an object with a key for each of the desired extension points (`'onRequest'` is not allowed), and the value is the same as the [`server.ext(events)`](#server.ext\(\)) `event` argument. ### `route.options.files` [](#-routeoptionsfiles) Default value: `{ relativeTo: '.' }`. Defines the behavior for accessing files: * `relativeTo` \- determines the folder relative paths are resolved against. ### `route.options.handler` [](#-routeoptionshandler) Default value: none. The route handler function performs the main business logic of the route and sets the response. `handler` can be assigned: * a [lifecycle method](#lifecycle-methods). * an object with a single property using the name of a handler type registered with the [`server.decorate()`](#server.decorate\(\)) method. The matching property value is passed as options to the registered handler generator. const handler = function (request, h) { return 'success'; }; Note: handlers using a fat arrow style function cannot be bound to any `bind` property. Instead, the bound context is available under [`h.context`](#h.context). ### `route.options.id` [](#-routeoptionsid) Default value: none. An optional unique identifier used to look up the route using [`server.lookup()`](#server.lookup\(\)). Cannot be assigned to routes added with an array of methods. ### `route.options.isInternal` [](#-routeoptionsisinternal) Default value: `false`. If `true`, the route cannot be accessed through the HTTP listener but only through the [`server.inject()`](#server.inject\(\)) interface with the `allowInternals` option set to `true`. Used for internal routes that should not be accessible to the outside world. ### `route.options.json` [](#-routeoptionsjson) Default value: none. Optional arguments passed to `JSON.stringify()` when converting an object or error response to a string payload or escaping it after stringification. Supports the following: * `replacer` \- the replacer function or array. Defaults to no action. * `space` \- number of spaces to indent nested object keys. Defaults to no indentation. * `suffix` \- string suffix added after conversion to JSON string. Defaults to no suffix. * `escape` \- calls [`Hoek.jsonEscape()`](https://hapi.dev/family/hoek/api/#escapejsonstring) after conversion to JSON string. Defaults to `false`. ### `route.options.log` [](#-routeoptionslog) Default value: `{ collect: false }`. Request logging options: * `collect` \- if `true`, request-level logs (both internal and application) are collected and accessible via [`request.logs`](#request.logs). ### `route.options.notes` [](#-routeoptionsnotes) Default value: none. Route notes used for generating documentation (string or array of strings). This setting is not available when setting server route defaults using [`server.options.routes`](#server.options.routes). ### `route.options.payload` [](#-routeoptionspayload) Determines how the request payload is processed. #### `route.options.payload.allow` [](#-routeoptionspayloadallow) Default value: allows parsing of the following mime types: * application/json * application/*+json * application/octet-stream * application/x-www-form-urlencoded * multipart/form-data * text/* A string or an array of strings with the allowed mime types for the endpoint. Use this settings to limit the set of allowed mime types. Note that allowing additional mime types not listed above will not enable them to be parsed, and if [`parse`](#route.options.payload.parse) is `true`, the request will result in an error response. #### `route.options.payload.compression` [](#-routeoptionspayloadcompression) Default value: none. An object where each key is a content-encoding name and each value is an object with the desired decoder settings. Note that encoder settings are set in [`compression`](#server.options.compression). #### `route.options.payload.defaultContentType` [](#-routeoptionspayloaddefaultcontenttype) Default value: `'application/json'`. The default content type if the 'Content-Type' request header is missing. #### `route.options.payload.failAction` [](#-routeoptionspayloadfailaction) Default value: `'error'` (return a Bad Request (400) error response). A [`failAction` value](#lifecycle-failAction) which determines how to handle payload parsing errors. #### `route.options.payload.maxBytes` [](#-routeoptionspayloadmaxbytes) Default value: `1048576` (1MB). Limits the size of incoming payloads to the specified byte count. Allowing very large payloads may cause the server to run out of memory. #### `route.options.payload.maxParts` [](#-routeoptionspayloadmaxparts) Default value: `1000`. Limits the number of parts allowed in multipart payloads. #### `route.options.payload.multipart` [](#-routeoptionspayloadmultipart) Default value: `false`. Overrides payload processing for multipart requests. Value can be one of: * `false` \- disable multipart processing (this is the default value). * `true` \- enable multipart processing using the [`output`](#route.options.payload.output) value. * an object with the following required options: * `output` \- same as the [`output`](#route.options.payload.output) option with an additional value option: * `annotated` \- wraps each multipart part in an object with the following keys: * `headers` \- the part headers. * `filename` \- the part file name. * `payload` \- the processed part payload. #### `route.options.payload.output` [](#-routeoptionspayloadoutput) Default value: `'data'`. The processed payload format. The value must be one of: * `'data'` \- the incoming payload is read fully into memory. If [`parse`](#route.options.payload.parse) is `true`, the payload is parsed (JSON, form-decoded, multipart) based on the 'Content-Type' header. If [`parse`](#route.options.payload.parse) is `false`, a raw `Buffer` is returned. * `'stream'` \- the incoming payload is made available via a `Stream.Readable` interface. If the payload is 'multipart/form-data' and [`parse`](#route.options.payload.parse) is `true`, field values are presented as text while files are provided as streams. File streams from a 'multipart/form-data' upload will also have a `hapi` property containing the `filename` and `headers` properties. Note that payload streams for multipart payloads are a synthetic interface created on top of the entire multipart content loaded into memory. To avoid loading large multipart payloads into memory, set [`parse`](#route.options.payload.parse) to `false` and handle the multipart payload in the handler using a streaming parser (e.g. [**pez**](https://hapi.dev/family/pez/api)). * `'file'` \- the incoming payload is written to temporary file in the directory specified by the [`uploads`](#route.options.payload.uploads) settings. If the payload is 'multipart/form-data' and [`parse`](#route.options.payload.parse) is `true`, field values are presented as text while files are saved to disk. Note that it is the sole responsibility of the application to clean up the files generated by the framework. This can be done by keeping track of which files are used (e.g. using the `request.app` object), and listening to the server `'response'` event to perform cleanup. #### `route.options.payload.override` [](#-routeoptionspayloadoverride) Default value: none. A mime type string overriding the 'Content-Type' header value received. #### `route.options.payload.parse` [](#-routeoptionspayloadparse) Default value: `true`. Determines if the incoming payload is processed or presented raw. Available values: * `true` \- if the request 'Content-Type' matches the allowed mime types set by [`allow`](#route.options.payload.allow) (for the whole payload as well as parts), the payload is converted into an object when possible. If the format is unknown, a Bad Request (400) error response is sent. Any known content encoding is decoded. * `false` \- the raw payload is returned unmodified. * `'gunzip'` \- the raw payload is returned unmodified after any known content encoding is decoded. #### `route.options.payload.protoAction` [](#-routeoptionspayloadprotoaction) Default value: `'error'`. Sets handling of incoming payload that may contain a prototype poisoning security attack. Available values: * `'error'` \- returns a `400` bad request error when the payload contains a prototype. * `'remove'` \- sanitizes the payload to remove the prototype. * `'ignore'` \- disables the protection and allows the payload to pass as received. Use this option only when you are sure that such incoming data cannot pose any risks to your application. #### `route.options.payload.timeout` [](#-routeoptionspayloadtimeout) Default value: to `10000` (10 seconds). Payload reception timeout in milliseconds. Sets the maximum time allowed for the client to transmit the request payload (body) before giving up and responding with a Request Timeout (408) error response. Set to `false` to disable. #### `route.options.payload.uploads` [](#-routeoptionspayloaduploads) Default value: `os.tmpdir()`. The directory used for writing file uploads. ### `route.options.plugins` [](#-routeoptionsplugins) Default value: `{}`. Plugin-specific configuration. `plugins` is an object where each key is a plugin name and the value is the plugin configuration. ### `route.options.pre` [](#-routeoptionspre) Default value: none. The `pre` option allows defining methods for performing actions before the handler is called. These methods allow breaking the handler logic into smaller, reusable components that can be shared across routes, as well as provide a cleaner error handling of prerequisite operations (e.g. load required reference data from a database). `pre` is assigned an ordered array of methods which are called serially in order. If the `pre` array contains another array of methods as one of its elements, those methods are called in parallel. Note that during parallel execution, if any of the methods error, return a [takeover response](#takeover-response), or abort signal, the other parallel methods will continue to execute but will be ignored once completed. `pre` can be assigned a mixed array of: * an array containing the elements listed below, which are executed in parallel. * an object with: * `method` \- a [lifecycle method](#lifecycle-methods). * `assign` \- key name used to assign the response of the method to in [`request.pre`](#request.pre) and [`request.preResponses`](#request.preResponses). * `failAction` \- A [`failAction` value](#lifecycle-failAction) which determine what to do when a pre-handler method throws an error. If `assign` is specified and the `failAction` setting is not `'error'`, the error will be assigned. * a method function - same as including an object with a single `method` key. Note that pre-handler methods do not behave the same way other [lifecycle methods](#lifecycle-methods) do when a value is returned. Instead of the return value becoming the new response payload, the value is used to assign the corresponding [`request.pre`](#request.pre) and [`request.preResponses`](#request.preResponses) properties. Otherwise, the handling of errors, [takeover response](#takeover-response) response, or abort signal behave the same as any other [lifecycle methods](#lifecycle-methods). const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); const pre1 = function (request, h) { return 'Hello'; }; const pre2 = function (request, h) { return 'World'; }; const pre3 = function (request, h) { return request.pre.m1 + ' ' + request.pre.m2; }; server.route({ method: 'GET', path: '/', options: { pre: [ [ // m1 and m2 executed in parallel { method: pre1, assign: 'm1' }, { method: pre2, assign: 'm2' } ], { method: pre3, assign: 'm3' }, ], handler: function (request, h) { return request.pre.m3 + '!\n'; } } }); ### `route.options.response` [](#-routeoptionsresponse) Processing rules for the outgoing response. #### `route.options.response.disconnectStatusCode` [](#-routeoptionsresponsedisconnectstatuscode) Default value: `499`. The default HTTP status code used to set a response error when the request is closed or aborted before the response is fully transmitted. Value can be any integer greater or equal to `400`. The default value `499` is based on the non-standard nginx "CLIENT CLOSED REQUEST" error. The value is only used for logging as the request has already ended. #### `route.options.response.emptyStatusCode` [](#-routeoptionsresponseemptystatuscode) Default value: `204`. The default HTTP status code when the payload is considered empty. Value can be `200` or `204`. Note that a `200` status code is converted to a `204` only at the time of response transmission (the response status code will remain `200` throughout the request lifecycle unless manually set). #### `route.options.response.failAction` [](#-routeoptionsresponsefailaction) Default value: `'error'` (return an Internal Server Error (500) error response). A [`failAction` value](#lifecycle-failAction) which defines what to do when a response fails payload validation. #### `route.options.response.modify` [](#-routeoptionsresponsemodify) Default value: `false`. If `true`, applies the validation rule changes to the response payload. #### `route.options.response.options` [](#-routeoptionsresponseoptions) Default value: none. [**joi**](https://joi.dev/api) options object pass to the validation function. Useful to set global options such as `stripUnknown` or `abortEarly`. If a custom validation function is defined via [`schema`](#route.options.response.schema) or [`status`](#route.options.response.status) then `options` can an arbitrary object that will be passed to this function as the second argument. #### `route.options.response.ranges` [](#-routeoptionsresponseranges) Default value: `true`. If `false`, payload [range](https://tools.ietf.org/html/rfc7233#section-3) support is disabled. #### `route.options.response.sample` [](#-routeoptionsresponsesample) Default value: `100` (all responses). The percent of response payloads validated (0 - 100). Set to `0` to disable all validation. #### `route.options.response.schema` [](#-routeoptionsresponseschema) Default value: `true` (no validation). The default response payload validation rules (for all non-error responses) expressed as one of: * `true` \- any payload allowed (no validation). * `false` \- no payload allowed. * a [**joi**](https://joi.dev/api) validation object. The [`options`](#route.options.response.options) along with the request context (`{ headers, params, query, payload, state, app, auth }`) are passed to the validation function. * a validation function using the signature `async function(value, options)` where: * `value` \- the pending response payload. * `options` \- The [`options`](#route.options.response.options) along with the request context (`{ headers, params, query, payload, state, app, auth }`). * if the function returns a value and [`modify`](#route.options.response.modify) is `true`, the value is used as the new response. If the original response is an error, the return value is used to override the original error `output.payload`. If an error is thrown, the error is processed according to [`failAction`](#route.options.response.failAction). #### `route.options.response.status` [](#-routeoptionsresponsestatus) Default value: none. Validation schemas for specific HTTP status codes. Responses (excluding errors) not matching the listed status codes are validated using the default [`schema`](#route.options.response.schema). `status` is set to an object where each key is a 3 digit HTTP status code and the value has the same definition as [`schema`](#route.options.response.schema). ### `route.options.rules` [](#-routeoptionsrules) Default value: none. A custom rules object passed to each rules processor registered with [`server.rules()`](#server.rules\(\)). ### `route.options.security` [](#-routeoptionssecurity) Default value: `false` (security headers disabled). Sets common security headers. To enable, set `security` to `true` or to an object with the following options: * `hsts` \- controls the 'Strict-Transport-Security' header, where: * `true` \- the header will be set to `max-age=15768000`. This is the default value. * a number - the maxAge parameter will be set to the provided value. * an object with the following fields: * `maxAge` \- the max-age portion of the header, as a number. Default is `15768000`. * `includeSubDomains` \- a boolean specifying whether to add the `includeSubDomains` flag to the header. * `preload` \- a boolean specifying whether to add the `'preload'` flag (used to submit domains inclusion in Chrome's HTTP Strict Transport Security (HSTS) preload list) to the header. * `xframe` \- controls the 'X-Frame-Options' header, where: * `true` \- the header will be set to `'DENY'`. This is the default value. * `'deny'` \- the headers will be set to `'DENY'`. * `'sameorigin'` \- the headers will be set to `'SAMEORIGIN'`. * an object for specifying the 'allow-from' rule, where: * `rule` \- one of: * `'deny'` * `'sameorigin'` * `'allow-from'` * `source` \- when `rule` is `'allow-from'` this is used to form the rest of the header, otherwise this field is ignored. If `rule` is `'allow-from'` but `source` is unset, the rule will be automatically changed to `'sameorigin'`. * `xss` \- controls the 'X-XSS-Protection' header, where: * `'disabled'` \- the header will be set to `'0'`. This is the default value. * `'enabled'` \- the header will be set to `'1; mode=block'`. * `false` \- the header will be omitted. Note: when enabled, this setting can create a security vulnerabilities in versions of Internet Explorer below 8, unpatched versions of IE8, and browsers that employ an XSS filter/auditor. See [here](https://hackademix.net/2009/11/21/ies-xss-filter-creates-xss-vulnerabilities/), [here](https://technet.microsoft.com/library/security/ms10-002), and [here](https://blog.innerht.ml/the-misunderstood-x-xss-protection/) for more information. * `noOpen` \- boolean controlling the 'X-Download-Options' header for Internet Explorer, preventing downloads from executing in your context. Defaults to `true` setting the header to `'noopen'`. * `noSniff` \- boolean controlling the 'X-Content-Type-Options' header. Defaults to `true` setting the header to its only and default option, `'nosniff'`. * `referrer` \- controls the ['Referrer-Policy'](https://www.w3.org/TR/referrer-policy/) header, which has the following possible values. * `false` \- the 'Referrer-Policy' header will not be sent to clients with responses. This is the default value. * `''` \- instructs clients that the Referrer-Policy will be [defined elsewhere](https://www.w3.org/TR/referrer-policy/#referrer-policy-empty-string), such as in a meta html tag. * `'no-referrer'` \- instructs clients to never include the referrer header when making requests. * `'no-referrer-when-downgrade'` \- instructs clients to never include the referrer when navigating from HTTPS to HTTP. * `'same-origin'` \- instructs clients to only include the referrer on the current site origin. * `'origin'` \- instructs clients to include the referrer but strip off path information so that the value is the current origin only. * `'strict-origin'` \- same as `'origin'` but instructs clients to omit the referrer header when going from HTTPS to HTTP. * `'origin-when-cross-origin'` \- instructs clients to include the full path in the referrer header for same-origin requests but only the origin components of the URL are included for cross origin requests. * `'strict-origin-when-cross-origin'` \- same as `'origin-when-cross-origin'` but the client is instructed to omit the referrer when going from HTTPS to HTTP. * `'unsafe-url'` \- instructs the client to always include the referrer with the full URL. ### `route.options.state` [](#-routeoptionsstate) Default value: `{ parse: true, failAction: 'error' }`. HTTP state management (cookies) allows the server to store information on the client which is sent back to the server with every request (as defined in [RFC 6265](https://tools.ietf.org/html/rfc6265)). `state` supports the following options: * `parse` \- determines if incoming 'Cookie' headers are parsed and stored in the [`request.state`](#request.state) object. * `failAction` \- A [`failAction` value](#lifecycle-failAction) which determines how to handle cookie parsing errors. Defaults to `'error'` (return a Bad Request (400) error response). ### `route.options.tags` [](#-routeoptionstags) Default value: none. Route tags used for generating documentation (array of strings). This setting is not available when setting server route defaults using [`server.options.routes`](#server.options.routes). ### `route.options.timeout` [](#-routeoptionstimeout) Default value: `{ server: false }`. Timeouts for processing durations. #### `route.options.timeout.server` [](#-routeoptionstimeoutserver) Default value: `false`. Response timeout in milliseconds. Sets the maximum time allowed for the server to respond to an incoming request before giving up and responding with a Service Unavailable (503) error response. #### `route.options.timeout.socket` [](#-routeoptionstimeoutsocket) Default value: none (use node default of 2 minutes). By default, node sockets automatically timeout after 2 minutes. Use this option to override this behavior. Set to `false` to disable socket timeouts. ### `route.options.validate` [](#-routeoptionsvalidate) Default value: `{ headers: true, params: true, query: true, payload: true, state: true, failAction: 'error' }`. Request input validation rules for various request components. #### `route.options.validate.errorFields` [](#-routeoptionsvalidateerrorfields) Default value: none. An optional object with error fields copied into every validation error response. #### `route.options.validate.failAction` [](#-routeoptionsvalidatefailaction) Default value: `'error'` (return a Bad Request (400) error response). A [`failAction` value](#lifecycle-failAction) which determines how to handle failed validations. When set to a function, the `err` argument includes the type of validation error under `err.output.payload.validation.source`. The default error that would otherwise have been logged or returned can be accessed under `err.data.defaultError`. #### `route.options.validate.headers` [](#-routeoptionsvalidateheaders) Default value: `true` (no validation). Validation rules for incoming request headers: * `true` \- any headers allowed (no validation performed). * a [**joi**](https://joi.dev/api) validation object. * a validation function using the signature `async function(value, options)` where: * `value` \- the [`request.headers`](#request.headers) object containing the request headers. * `options` \- [`options`](#route.options.validate.options). * if a value is returned, the value is used as the new [`request.headers`](#request.headers) value and the original value is stored in [`request.orig.headers`](#request.orig). Otherwise, the headers are left unchanged. If an error is thrown, the error is handled according to [`failAction`](#route.options.validate.failAction). Note that all header field names must be in lowercase to match the headers normalized by node. #### `route.options.validate.options` [](#-routeoptionsvalidateoptions) Default value: none. An options object passed to the [**joi**](https://joi.dev/api) rules or the custom validation methods. Used for setting global options such as `stripUnknown` or `abortEarly`. If a custom validation function (see `headers`, `params`, `query`, or `payload` above) is defined then `options` can an arbitrary object that will be passed to this function as the second parameter. The values of the other inputs (i.e. `headers`, `query`, `params`, `payload`, `state`, `app`, and `auth`) are added to the `options` object under the validation `context` (accessible in rules as `Joi.ref('$query.key')`). Note that validation is performed in order (i.e. headers, params, query, and payload) and if type casting is used (e.g. converting a string to a number), the value of inputs not yet validated will reflect the raw, unvalidated and unmodified values. If the validation rules for `headers`, `params`, `query`, and `payload` are defined at both the server [`routes`](#server.options.routes) level and at the route level, the individual route settings override the routes defaults (the rules are not merged). #### `route.options.validate.params` [](#-routeoptionsvalidateparams) Default value: `true` (no validation). Validation rules for incoming request path parameters, after matching the path against the route, extracting any parameters, and storing them in [`request.params`](#request.params), where: * `true` \- any path parameter value allowed (no validation performed). * a [**joi**](https://joi.dev/api) validation object. * a validation function using the signature `async function(value, options)` where: * `value` \- the [`request.params`](#request.params) object containing the request path parameters. * `options` \- [`options`](#route.options.validate.options). * if a value is returned, the value is used as the new [`request.params`](#request.params) value and the original value is stored in [`request.orig.params`](#request.orig). Otherwise, the path parameters are left unchanged. If an error is thrown, the error is handled according to [`failAction`](#route.options.validate.failAction). Note that failing to match the validation rules to the route path parameters definition will cause all requests to fail. #### `route.options.validate.payload` [](#-routeoptionsvalidatepayload) Default value: `true` (no validation). Validation rules for incoming request payload (request body), where: * `true` \- any payload allowed (no validation performed). * `false` \- no payload allowed. * a [**joi**](https://joi.dev/api) validation object. * Note that empty payloads are represented by a `null` value. If a validation schema is provided and empty payload are allowed, the schema must be explicitly defined by setting the rule to a **joi** schema with `null` allowed (e.g. `Joi.object({ /* keys here */ }).allow(null)`). * a validation function using the signature `async function(value, options)` where: * `value` \- the [`request.payload`](#request.payload) object containing the request payload. * `options` \- [`options`](#route.options.validate.options). * if a value is returned, the value is used as the new [`request.payload`](#request.payload) value and the original value is stored in [`request.orig.payload`](#request.orig). Otherwise, the payload is left unchanged. If an error is thrown, the error is handled according to [`failAction`](#route.options.validate.failAction). Note that validating large payloads and modifying them will cause memory duplication of the payload (since the original is kept), as well as the significant performance cost of validating large amounts of data. #### `route.options.validate.query` [](#-routeoptionsvalidatequery) Default value: `true` (no validation). Validation rules for incoming request URI query component (the key-value part of the URI between '?' and '#'). The query is parsed into its individual key-value pairs, decoded, and stored in [`request.query`](#request.query) prior to validation. Where: * `true` \- any query parameter value allowed (no validation performed). * `false` \- no query parameter value allowed. * a [**joi**](https://joi.dev/api) validation object. * a validation function using the signature `async function(value, options)` where: * `value` \- the [`request.query`](#request.query) object containing the request query parameters. * `options` \- [`options`](#route.options.validate.options). * if a value is returned, the value is used as the new [`request.query`](#request.query) value and the original value is stored in [`request.orig.query`](#request.orig). Otherwise, the query parameters are left unchanged. If an error is thrown, the error is handled according to [`failAction`](#route.options.validate.failAction). Note that changes to the query parameters will not be reflected in [`request.url`](#request.url). #### `route.options.validate.state` [](#-routeoptionsvalidatestate) Default value: `true` (no validation). Validation rules for incoming cookies. The `cookie` header is parsed and decoded into the [`request.state`](#request.state) prior to validation. Where: * `true` \- any cookie value allowed (no validation performed). * `false` \- no cookies allowed. * a [**joi**](https://joi.dev/api) validation object. * a validation function using the signature `async function(value, options)` where: * `value` \- the [`request.state`](#request.state) object containing all parsed cookie values. * `options` \- [`options`](#route.options.validate.options). * if a value is returned, the value is used as the new [`request.state`](#request.state) value and the original value is stored in [`request.orig.state`](#request.orig). Otherwise, the cookie values are left unchanged. If an error is thrown, the error is handled according to [`failAction`](#route.options.validate.failAction). #### `route.options.validate.validator` [](#-routeoptionsvalidatevalidator) Default value: `null` (no default validator). Sets a server validation module used to compile raw validation rules into validation schemas (e.g. **joi**). Note: the validator is only used when validation rules are not pre-compiled schemas. When a validation rules is a function or schema object, the rule is used as-is and the validator is not used. ## Request lifecycle [](#request-lifecycle) Each incoming request passes through the request lifecycle. The specific steps vary based on the server and route configurations, but the order in which the applicable steps are executed is always the same. The following is the complete list of steps a request can go through: * _**onRequest**_ * always called when `onRequest` extensions exist. * the request path and method can be modified via the [`request.setUrl()`](#request.setUrl\(\)) and [`request.setMethod()`](#request.setMethod\(\)) methods. Changes to the request path or method will impact how the request is routed and can be used for rewrite rules. * [`request.payload`](#request.payload) is `undefined` and can be overridden with any non-`undefined` value to bypass payload processing. * [`request.route`](#request.route) is unassigned. * [`request.url`](#request.url) can be `null` if the incoming request path is invalid. * [`request.path`](#request.path) can be an invalid path. * _**Route lookup**_ * lookup based on `request.path` and `request.method`. * skips to _**onPreResponse**_ if no route is found or if the path violates the HTTP specification. * _**Cookies processing**_ * based on the route [`state`](#route.options.state) option. * error handling based on [`failAction`](#route.options.state.failAction). * _**onPreAuth**_ * called regardless if authentication is performed. * _**Authentication**_ * based on the route [`auth`](#route.options.auth) option. * _**Payload processing**_ * based on the route [`payload`](#route.options.payload) option and if [`request.payload`](#request.payload) has not been overridden in _**onRequest**_. * error handling based on [`failAction`](#route.options.payload.failAction). * _**Payload authentication**_ * based on the route [`auth`](#route.options.auth) option. * _**onCredentials**_ * called only if authentication is performed. * _**Authorization**_ * based on the route authentication [`access`](#route.options.auth.access) option. * _**onPostAuth**_ * called regardless if authentication is performed. * _**Headers validation**_ * based on the route [`validate.headers`](#route.options.validate.headers) option. * error handling based on [`failAction`](#route.options.validate.failAction). * _**Path parameters validation**_ * based on the route [`validate.params`](#route.options.validate.params) option. * error handling based on [`failAction`](#route.options.validate.failAction). * _**Query validation**_ * based on the route [`validate.query`](#route.options.validate.query) option. * error handling based on [`failAction`](#route.options.validate.failAction). * _**Payload validation**_ * based on the route [`validate.payload`](#route.options.validate.payload) option. * error handling based on [`failAction`](#route.options.validate.failAction). * _**State validation**_ * based on the route [`validate.state`](#route.options.validate.state) option. * error handling based on [`failAction`](#route.options.validate.failAction). * _**onPreHandler**_ * _**Pre-handler methods**_ * based on the route [`pre`](#route.options.pre) option. * error handling based on each pre-handler method's `failAction` setting. * _**Route handler**_ * executes the route [`handler`](#route.options.handler). * _**onPostHandler**_ * the response contained in [`request.response`](#request.response) may be modified (but not assigned a new value). To return a different response type (for example, replace an error with an HTML response), return a new response value. * _**Response validation**_ * error handling based on [`failAction`](#route.options.response.failAction). * _**onPreResponse**_ * always called, unless the request is aborted. * the response contained in [`request.response`](#request.response) may be modified (but not assigned a new value). To return a different response type (for example, replace an error with an HTML response), return a new response value. Note that any errors generated will not be passed back to _**onPreResponse**_ to prevent an infinite loop. * _**Response transmission**_ * may emit a [`'request'` event](#server.events.request) on the `'error'` channel. * _**Finalize request**_ * emits `'response'` event. * _**onPostResponse**_ * return value is ignored since the response is already set. * emits a [`'request'` event](#server.events.request) on the `'error'` channel if an error is returned. * all extension handlers are executed even if some error. * note that since the handlers are executed in serial (each is `await`ed), care must be taken to avoid blocking execution if other extension handlers expect to be called immediately when the response is sent. If an _**onPostResponse**_ handler is performing IO, it should defer that activity to another tick and return immediately (either without a return value or without a promise that is solve to resolve). ### Lifecycle methods [](#lifecycle-methods) Lifecycle methods are the interface between the framework and the application. Many of the request lifecycle steps: [extensions](#server.ext\(\)), [authentication](#authentication-scheme), [handlers](#route.options.handler), [pre-handler methods](#route.options.pre), and [`failAction` function values](#lifecycle-failAction) are lifecyle methods provided by the developer and executed by the framework. Each lifecycle method is a function with the signature `await function(request, h, [err])` where: * `request` \- the [request object](#request). * `h` \- the [response toolkit](#response-toolkit) the handler must call to set a response and return control back to the framework. * `err` \- an error object available only when the method is used as a [`failAction` value](#lifecycle-failAction). Each lifecycle method must return a value or a promise that resolves into a value. If a lifecycle method returns without a value or resolves to an `undefined` value, an Internal Server Error (500) error response is sent. The return value must be one of: * Plain value: * `null` * string * number * boolean * `Buffer` object * `Error` object * plain `Error`. * a [`Boom`](https://hapi.dev/family/boom/api) object. * `Stream` object * must be compatible with the "streams2" API and not be in `objectMode`. * if the stream object has a `statusCode` property, that status code will be used as the default response code based on the [`passThrough`](#response.settings.passThrough) option. * if the stream object has a `headers` property, the headers will be included in the response based on the [`passThrough`](#response.settings.passThrough) option. * if the stream object has a function property `setCompressor(compressor)` and the response passes through a compressor, a reference to the compressor stream will be passed to the response stream via this method. * any object or array * must not include circular references. * a toolkit signal: * [`h.abandon`](#h.abandon) \- abort processing the request. * [`h.close`](#h.close) \- abort processing the request and call `end()` to ensure the response is closed. * [`h.continue`](#h.continue) \- continue processing the request lifecycle without changing the response. * a toolkit method response: * [`h.response()`](#h.response\(\)) \- wraps a plain response in a [response object](#response-object). * [`h.redirect()`](#h.redirect\(\)) \- wraps a plain response with a redirection directive. * [`h.authenticated()`](#h.authenticated\(\)) \- indicate request authenticated successfully (auth scheme only). * [`h.unauthenticated()`](#h.unauthenticated\(\)) \- indicate request failed to authenticate (auth scheme only). * a promise object that resolve to any of the above values Any error thrown by a lifecycle method will be used as the [response object](#response-object). While errors and valid values can be returned, it is recommended to throw errors. Throwing non-error values will generate a Bad Implementation (500) error response. const handler = function (request, h) { if (request.query.forbidden) { throw Boom.badRequest(); } return 'success'; }; If the route has a [`bind`](#route.options.bind) option or [`server.bind()`](#server.bind\(\)) was called, the lifecycle method will be bound to the provided context via `this` as well as accessible via [`h.context`](#h.context). #### Lifecycle workflow [](#lifecycle-workflow) The flow between each lifecycle step depends on the value returned by each lifecycle method as follows: * an error: * the lifecycle skips to the _**Response validation**_ step. * if returned by the _**onRequest**_ step it skips to the _**onPreResponse**_ step. * if returned by the _**Response validation**_ step it skips to the _**onPreResponse**_ step. * if returned by the _**onPreResponse**_ step it skips to the _**Response transmission**_ step. * an abort signal ([`h.abandon`](#h.abandon) or [`h.close`](#h.close)): * skips to the _**Finalize request**_ step. * a [`h.continue`](#h.continue) signal: * continues processing the request lifecycle without changing the request response. * cannot be used by the [`authenticate()`](#authentication-scheme) scheme method. * a [takeover response](#takeover-response): * overrides the request response with the provided value and skips to the _**Response validation**_ step. * if returned by the _**Response validation**_ step it skips to the _**onPreResponse**_ step. * if returned by the _**onPreResponse**_ step it skips to the _**Response transmission**_ step. * any other response: * overrides the request response with the provided value and continues processing the request lifecycle. * cannot be returned from any step prior to the _**Pre-handler methods**_ step. The [`authenticate()`](#authentication-scheme) method has access to two additional return values: \- [`h.authenticated()`](#h.authenticated\(\)) \- indicate request authenticated successfully. \- [`h.unauthenticated()`](#h.unauthenticated\(\)) \- indicate request failed to authenticate. Note that these rules apply somewhat differently when used in a [pre-handler method](#route.options.pre). #### Takeover response [](#takeover-response) A takeover response is a [`response object`](#response-object) on which [`response.takeover()`](#response.takever\(\)) was called to signal that the [lifecycle method](#lifecycle-methods) return value should be set as the response and skip to immediately validate and trasmit the value, bypassing other lifecycle steps. #### `failAction` configuration [](#-failaction-configuration) Various configuration options allows defining how errors are handled. For example, when invalid payload is received or malformed cookie, instead of returning an error, the framework can be configured to perform another action. When supported the `failAction` option supports the following values: * `'error'` \- return the error object as the response. * `'log'` \- report the error but continue processing the request. * `'ignore'` \- take no action and continue processing the request. * a [lifecycle method](#lifecycle-methods) with the signature `async function(request, h, err)` where: * `request` \- the [request object](#request). * `h` \- the [response toolkit](#response-toolkit). * `err` \- the error object. #### Errors [](#errors) **hapi** uses the [**boom**](https://hapi.dev/family/boom/api) error library for all its internal error generation. **boom** provides an expressive interface to return HTTP errors. Any error thrown by a [lifecycle method](#lifecycle-methods) is converted into a **boom** object and defaults to status code `500` if the error is not already a **boom** object. When the error is sent back to the client, the response contains a JSON object with the `statusCode`, `error`, and `message` keys. const Hapi = require('@hapi/hapi'); const Boom = require('@hapi/boom'); const server = Hapi.server(); server.route({ method: 'GET', path: '/badRequest', handler: function (request, h) { throw Boom.badRequest('Unsupported parameter'); // 400 } }); server.route({ method: 'GET', path: '/internal', handler: function (request, h) { throw new Error('unexpect error'); // 500 } }); ##### Error transformation [](#error-transformation) Errors can be customized by changing their `output` content. The **boom** error object includes the following properties: * `isBoom` \- if `true`, indicates this is a `Boom` object instance. * `message` \- the error message. * `output` \- the formatted response. Can be directly manipulated after object construction to return a custom error response. Allowed root keys: * `statusCode` \- the HTTP status code (typically 4xx or 5xx). * `headers` \- an object containing any HTTP headers where each key is a header name and value is the header content. * `payload` \- the formatted object used as the response payload. Can be directly manipulated but any changes will be lost if `reformat()` is called. Any content allowed and by default includes the following content: * `statusCode` \- the HTTP status code, derived from `error.output.statusCode`. * `error` \- the HTTP status message (e.g. 'Bad Request', 'Internal Server Error') derived from `statusCode`. * `message` \- the error message derived from `error.message`. * inherited `Error` properties. It also supports the following method: * `reformat()` \- rebuilds `error.output` using the other object properties. const Boom = require('@hapi/boom'); const handler = function (request, h) { const error = Boom.badRequest('Cannot feed after midnight'); error.output.statusCode = 499; // Assign a custom error code error.reformat(); error.output.payload.custom = 'abc_123'; // Add custom key throw error; }); When a different error representation is desired, such as an HTML page or a different payload format, the `'onPreResponse'` extension point may be used to identify errors and replace them with a different [response object](#response-object), as in this example using [Vision's](https://hapi.dev/family/vision/api) `.view()` [response toolkit](#response-toolkit) property. const Hapi = require('@hapi/hapi'); const Vision = require('@hapi/vision'); const server = Hapi.server({ port: 80 }); server.register(Vision, (err) => { server.views({ engines: { html: require('handlebars') } }); }); const preResponse = function (request, h) { const response = request.response; if (!response.isBoom) { return h.continue; } // Replace error with friendly HTML const error = response; const ctx = { message: (error.output.statusCode === 404 ? 'page not found' : 'something went wrong') }; return h.view('error', ctx).code(error.output.statusCode); }; server.ext('onPreResponse', preResponse); ### Response Toolkit [](#response-toolkit) Access: read only. The response toolkit is a collection of properties and utilities passed to every [lifecycle method](#lifecycle-methods). It is somewhat hard to define as it provides both utilities for manipulating responses as well as other information. Since the toolkit is passed as a function argument, developers can name it whatever they want. For the purpose of this document the `h` notation is used. It is named in the spirit of the RethinkDB `r` method, with `h` for **h** api. #### Toolkit properties [](#toolkit-properties) ##### `h.abandon` [](#-habandon) Access: read only. A response symbol. When returned by a lifecycle method, the request lifecycle skips to the finalizing step without further interaction with the node response stream. It is the developer's responsibility to write and end the response directly via [`request.raw.res`](#request.raw). ##### `h.close` [](#-hclose) Access: read only. A response symbol. When returned by a lifecycle method, the request lifecycle skips to the finalizing step after calling `request.raw.res.end())` to close the node response stream. ##### `h.context` [](#-hcontext) Access: read / write (will impact the shared context if the object is modified). A response symbol. Provides access to the route or server context set via the route [`bind`](#route.options.bind) option or [`server.bind()`](#server.bind\(\)). ##### `h.continue` [](#-hcontinue) Access: read only. A response symbol. When returned by a lifecycle method, the request lifecycle continues without changing the response. ##### `h.realm` [](#-hrealm) Access: read only. The [server realm](#server.realm) associated with the matching route. Defaults to the root server realm in the _**onRequest**_ step. ##### `h.request` [](#-hrequest) Access: read only and public request interface. The [request] object. This is a duplication of the `request` lifecycle method argument used by [toolkit decorations](#server.decorate\(\)) to access the current request. #### `h.authenticated(data)` [](#-hauthenticateddata) Used by the [authentication] method to pass back valid credentials where: * `data` \- an object with: * `credentials` \- (required) object representing the authenticated entity. * `artifacts` \- (optional) authentication artifacts object specific to the authentication scheme. Return value: an internal authentication object. #### `h.entity(options)` [](#-hentityoptions) Sets the response 'ETag' and 'Last-Modified' headers and checks for any conditional request headers to decide if the response is going to qualify for an HTTP 304 (Not Modified). If the entity values match the request conditions, `h.entity()` returns a [response object](#response-object) for the lifecycle method to return as its value which will set a 304 response. Otherwise, it sets the provided entity headers and returns `undefined`. The method arguments are: * `options` \- a required configuration object with: * `etag` \- the ETag string. Required if `modified` is not present. Defaults to no header. * `modified` \- the Last-Modified header value. Required if `etag` is not present. Defaults to no header. * `vary` \- same as the [`response.etag()`](#response.etag\(\)) option. Defaults to `true`. Return value: \- a [response object](#response-object) if the response is unmodified. \- `undefined` if the response has changed. If `undefined` is returned, the developer must return a valid lifecycle method value. If a response is returned, it should be used as the return value (but may be customize using the response methods). const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); server.route({ method: 'GET', path: '/', options: { cache: { expiresIn: 5000 }, handler: function (request, h) { const response = h.entity({ etag: 'abc' }); if (response) { response.header('X', 'y'); return response; } return 'ok'; } } }); #### `h.redirect(uri)` [](#-hredirecturi) Redirects the client to the specified uri. Same as calling `h.response().redirect(uri)`. Returns a [response object](#response-object). const handler = function (request, h) { return h.redirect('http://example.com'); }; #### `h.response([value])` [](#-hresponsevalue) Wraps the provided value and returns a [`response`](#response-object) object which allows customizing the response (e.g. setting the HTTP status code, custom headers, etc.), where: * `value` \- (optional) return value. Defaults to `null`. Returns a [response object](#response-object). // Detailed notation const handler = function (request, h) { const response = h.response('success'); response.type('text/plain'); response.header('X-Custom', 'some-value'); return response; }; // Chained notation const handler = function (request, h) { return h.response('success') .type('text/plain') .header('X-Custom', 'some-value'); }; #### `h.state(name, value, [options])` [](#-hstatename-value-options) Sets a response cookie using the same arguments as [`response.state()`](#response.state\(\)). Return value: none. const ext = function (request, h) { h.state('cookie-name', 'value'); return h.continue; }; #### `h.unauthenticated(error, [data])` [](#-hunauthenticatederror-data) Used by the [authentication] method to indicate authentication failed and pass back the credentials received where: * `error` \- (required) the authentication error. * `data` \- (optional) an object with: * `credentials` \- (required) object representing the authenticated entity. * `artifacts` \- (optional) authentication artifacts object specific to the authentication scheme. The method is used to pass both the authentication error and the credentials. For example, if a request included expired credentials, it allows the method to pass back the user information (combined with a `'try'` authentication [`mode`](#route.options.auth.mode)) for error customization. There is no difference between throwing the error or passing it with the `h.unauthenticated()` method if no credentials are passed, but it might still be helpful for code clarity. #### `h.unstate(name, [options])` [](#-hunstatename-options) Clears a response cookie using the same arguments as [`response.unstate()`](#response.unstate\(\)). const ext = function (request, h) { h.unstate('cookie-name'); return h.continue; }; ### Response object [](#response-object) The response object contains the request response value along with various HTTP headers and flags. When a [lifecycle method](#lifecycle-methods) returns a value, the value is wrapped in a response object along with some default flags (e.g. `200` status code). In order to customize a response before it is returned, the [`h.response()`](#h.response\(\)) method is provided. #### Response properties [](#response-properties) ##### `response.app` [](#-responseapp) Access: read / write. Default value: `{}`. Application-specific state. Provides a safe place to store application data without potential conflicts with the framework. Should not be used by [plugins](#plugins) which should use [`plugins[name]`](#response.plugins). ##### `response.contentType` [](#-responsecontenttype) Access: read. Default value: none. Provides a preview of the response HTTP Content-Type header based on the implicit response type, any explicit Content-Type header set, and any content character-set defined. The returned value is only a preview as the content type can change later both internally and by user code (it represents current response state). The value is `null` if no implicit type can be determined. ##### `response.events` [](#-responseevents) Access: read only and the public **podium** interface. The `response.events` object supports the following events: * `'peek'` \- emitted for each chunk of data written back to the client connection. The event method signature is `function(chunk, encoding)`. * `'finish'` \- emitted when the response finished writing but before the client response connection is ended. The event method signature is `function ()`. const Crypto = require('crypto'); const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); const preResponse = function (request, h) { const response = request.response; if (response.isBoom) { return null; } const hash = Crypto.createHash('sha1'); response.events.on('peek', (chunk) => { hash.update(chunk); }); response.events.once('finish', () => { console.log(hash.digest('hex')); }); return h.continue; }; server.ext('onPreResponse', preResponse); ##### `response.headers` [](#-responseheaders) Access: read only. Default value: `{}`. An object containing the response headers where each key is a header field name and the value is the string header value or array of string. Note that this is an incomplete list of headers to be included with the response. Additional headers will be added once the response is prepared for transmission. ##### `response.plugins` [](#-responseplugins) Access: read / write. Default value: `{}`. Plugin-specific state. Provides a place to store and pass request-level plugin data. `plugins` is an object where each key is a plugin name and the value is the state. ##### `response.settings` [](#-responsesettings) Access: read only. Object containing the response handling flags. ###### `response.settings.passThrough` [](#-responsesettingspassthrough) Access: read only. Defaults value: `true`. If `true` and [`source`](#response.source) is a `Stream`, copies the `statusCode` and `headers` properties of the stream object to the outbound response. ###### `response.settings.stringify` [](#-responsesettingsstringify) Access: read only. Default value: `null` (use route defaults). Override the route [`json`](#route.options.json) options used when [`source`](#response.source) value requires stringification. ###### `response.settings.ttl` [](#-responsesettingsttl) Access: read only. Default value: `null` (use route defaults). If set, overrides the route [`cache`](#route.options.cache) with an expiration value in milliseconds. ###### `response.settings.varyEtag` [](#-responsesettingsvaryetag) Default value: `false`. If `true`, a suffix will be automatically added to the 'ETag' header at transmission time (separated by a `'-'` character) when the HTTP 'Vary' header is present. ##### `response.source` [](#-responsesource) Access: read only. The raw value returned by the [lifecycle method](#lifecycle-methods). ##### `response.statusCode` [](#-responsestatuscode) Access: read only. Default value: `200`. The HTTP response status code. ##### `response.variety` [](#-responsevariety) Access: read only. A string indicating the type of [`source`](#response.source) with available values: * `'plain'` \- a plain response such as string, number, `null`, or simple object. * `'buffer'` \- a `Buffer`. * `'stream'` \- a `Stream`. #### `response.bytes(length)` [](#-responsebyteslength) Sets the HTTP 'Content-Length' header (to avoid chunked transfer encoding) where: * `length` \- the header value. Must match the actual payload size. Return value: the current response object. #### `response.charset(charset)` [](#-responsecharsetcharset) Sets the 'Content-Type' HTTP header 'charset' property where: * `charset` \- the charset property value. When `charset` value is falsy, it will prevent hapi from using its default charset setting. Return value: the current response object. #### `response.code(statusCode)` [](#-responsecodestatuscode) Sets the HTTP status code where: * `statusCode` \- the HTTP status code (e.g. 200). Return value: the current response object. #### `response.message(httpMessage)` [](#-responsemessagehttpmessage) Sets the HTTP status message where: * `httpMessage` \- the HTTP status message (e.g. 'Ok' for status code 200). Return value: the current response object. #### `response.compressed(encoding)` [](#-responsecompressedencoding) Sets the HTTP 'content-encoding' header where: * `encoding` \- the header value string. Return value: the current response object. Note that setting content encoding via this method does not set a 'vary' HTTP header with 'accept-encoding' value. To vary the response, use the `response.header()` method instead. #### `response.created(uri)` [](#-responsecreateduri) Sets the HTTP status code to Created (201) and the HTTP 'Location' header where: * `uri` \- an absolute or relative URI used as the 'Location' header value. Return value: the current response object. #### `response.encoding(encoding)` [](#-responseencodingencoding) Sets the string encoding scheme used to serial data into the HTTP payload where: * `encoding` \- the encoding property value (see [node Buffer encoding](https://nodejs.org/api/buffer.html#buffer_buffers_and_character_encodings)). Return value: the current response object. #### `response.etag(tag, options)` [](#-responseetagtag-options) Sets the representation [entity tag](https://tools.ietf.org/html/rfc7232#section-2.3) where: * `tag` \- the entity tag string without the double-quote. * `options` \- (optional) settings where: * `weak` \- if `true`, the tag will be prefixed with the `'W/'` weak signifier. Weak tags will fail to match identical tags for the purpose of determining 304 response status. Defaults to `false`. * `vary` \- if `true` and content encoding is set or applied to the response (e.g 'gzip' or 'deflate'), the encoding name will be automatically added to the tag at transmission time (separated by a `'-'` character). Ignored when `weak` is `true`. Defaults to `true`. Return value: the current response object. #### `response.header(name, value, options)` [](#-responseheadername-value-options) Sets an HTTP header where: * `name` \- the header name. * `value` \- the header value. * `options` \- (optional) object where: * `append` \- if `true`, the value is appended to any existing header value using `separator`. Defaults to `false`. * `separator` \- string used as separator when appending to an existing value. Defaults to `','`. * `override` \- if `false`, the header value is not set if an existing value present. Defaults to `true`. * `duplicate` \- if `false`, the header value is not modified if the provided value is already included. Does not apply when `append` is `false` or if the `name` is `'set-cookie'`. Defaults to `true`. Return value: the current response object. #### `response.location(uri)` [](#-responselocationuri) Sets the HTTP 'Location' header where: * `uri` \- an absolute or relative URI used as the 'Location' header value. Return value: the current response object. #### `response.redirect(uri)` [](#-responseredirecturi) Sets an HTTP redirection response (302) and decorates the response with additional methods, where: * `uri` \- an absolute or relative URI used to redirect the client to another resource. Return value: the current response object. Decorates the response object with the [`response.temporary()`](#response.temporary\(\)), [`response.permanent()`](#response.permanent\(\)), and [`response.rewritable()`](#response.rewritable\(\)) methods to easily change the default redirection code (302). | Permanent | Temporary ---|---|--- Rewritable | 301 | 302 Non-rewritable | 308 | 307 #### `response.replacer(method)` [](#-responsereplacermethod) Sets the `JSON.stringify()` `replacer` argument where: * `method` \- the replacer function or array. Defaults to none. Return value: the current response object. #### `response.spaces(count)` [](#-responsespacescount) Sets the `JSON.stringify()` `space` argument where: * `count` \- the number of spaces to indent nested object keys. Defaults to no indentation. Return value: the current response object. #### `response.state(name, value, [options])` [](#-responsestatename-value-options) Sets an HTTP cookie where: * `name` \- the cookie name. * `value` \- the cookie value. If no `options.encoding` is defined, must be a string. See [`server.state()`](#server.state\(\)) for supported `encoding` values. * `options` \- (optional) configuration. If the state was previously registered with the server using [`server.state()`](#server.state\(\)), the specified keys in `options` are merged with the default server definition. Return value: the current response object. #### `response.suffix(suffix)` [](#-responsesuffixsuffix) Sets a string suffix when the response is process via `JSON.stringify()` where: * `suffix` \- the string suffix. Return value: the current response object. #### `response.ttl(msec)` [](#-responsettlmsec) Overrides the default route cache expiration rule for this response instance where: * `msec` \- the time-to-live value in milliseconds. Return value: the current response object. #### `response.type(mimeType)` [](#-responsetypemimetype) Sets the HTTP 'Content-Type' header where: * `mimeType` \- is the mime type. Return value: the current response object. Should only be used to override the built-in default for each response type. #### `response.unstate(name, [options])` [](#-responseunstatename-options) Clears the HTTP cookie by setting an expired value where: * `name` \- the cookie name. * `options` \- (optional) configuration for expiring cookie. If the state was previously registered with the server using [`server.state()`](#serverstatename-options), the specified `options` are merged with the server definition. Return value: the current response object. #### `response.vary(header)` [](#-responsevaryheader) Adds the provided header to the list of inputs affected the response generation via the HTTP 'Vary' header where: * `header` \- the HTTP request header name. Return value: the current response object. #### `response.takeover()` [](#-responsetakeover) Marks the response object as a [takeover response](#takeover-response). Return value: the current response object. #### `response.temporary(isTemporary)` [](#-responsetemporaryistemporary) Sets the status code to `302` or `307` (based on the [`response.rewritable()`](#response.rewriteable\(\)) setting) where: * `isTemporary` \- if `false`, sets status to permanent. Defaults to `true`. Return value: the current response object. Only available after calling the [`response.redirect()`](#response.redirect\(\)) method. #### `response.permanent(isPermanent)` [](#-responsepermanentispermanent) Sets the status code to `301` or `308` (based on the [`response.rewritable()`](#response.rewritable\(\)) setting) where: * `isPermanent` \- if `false`, sets status to temporary. Defaults to `true`. Return value: the current response object. Only available after calling the [`response.redirect()`](#response.redirect\(\)) method. #### `response.rewritable(isRewritable)` [](#-responserewritableisrewritable) Sets the status code to `301`/`302` for rewritable (allows changing the request method from 'POST' to 'GET') or `307`/`308` for non-rewritable (does not allow changing the request method from 'POST' to 'GET'). Exact code based on the [`response.temporary()`](#response.temporary\(\)) or [`response.permanent()`](#response.permanent\(\)) setting. Arguments: * `isRewritable` \- if `false`, sets to non-rewritable. Defaults to `true`. Return value: the current response object. Only available after calling the [`response.redirect()`](#response.redirect\(\)) method. ## Request [](#request) The request object is created internally for each incoming request. It is not the same object received from the node HTTP server callback (which is available via [`request.raw.req`](#request.raw)). The request properties change throughout the [request lifecycle](#request-lifecycle). ### Request properties [](#request-properties) #### `request.app` [](#-requestapp) Access: read / write. Application-specific state. Provides a safe place to store application data without potential conflicts with the framework. Should not be used by [plugins](#plugins) which should use `plugins[name]`. #### `request.auth` [](#-requestauth) Access: read only. Authentication information: * `artifacts` \- an artifact object received from the authentication strategy and used in authentication-related actions. * `credentials` \- the `credential` object received during the authentication process. The presence of an object does not mean successful authentication. * `error` \- the authentication error if failed and mode set to `'try'`. * `isAuthenticated` \- `true` if the request has been successfully authenticated, otherwise `false`. * `isAuthorized` \- `true` is the request has been successfully authorized against the route authentication [`access`](#route.options.auth.access) configuration. If the route has not access rules defined or if the request failed authorization, set to `false`. * `isInjected` \- `true` if the request has been authenticated via the [`server.inject()`](#server.inject\(\)) `auth` option, otherwise `undefined`. * `mode` \- the route authentication mode. * `strategy` \- the name of the strategy used. #### `request.events` [](#-requestevents) Access: read only and the public **podium** interface. The `request.events` supports the following events: * `'peek'` \- emitted for each chunk of payload data read from the client connection. The event method signature is `function(chunk, encoding)`. * `'finish'` \- emitted when the request payload finished reading. The event method signature is `function ()`. * `'disconnect'` \- emitted when a request errors or aborts unexpectedly. const Crypto = require('crypto'); const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); const onRequest = function (request, h) { const hash = Crypto.createHash('sha1'); request.events.on('peek', (chunk) => { hash.update(chunk); }); request.events.once('finish', () => { console.log(hash.digest('hex')); }); request.events.once('disconnect', () => { console.error('request aborted'); }); return h.continue; }; server.ext('onRequest', onRequest); #### `request.headers` [](#-requestheaders) Access: read only. The raw request headers (references `request.raw.req.headers`). #### `request.info` [](#-requestinfo) Access: read only. Request information: * `acceptEncoding` \- the request preferred encoding. * `completed` \- request processing completion timestamp (`0` is still processing). * `cors` \- request CORS information (available only after the `'onRequest'` extension point as CORS is configured per-route and no routing decisions are made at that point in the request lifecycle), where: * `isOriginMatch` \- `true` if the request 'Origin' header matches the configured CORS restrictions. Set to `false` if no 'Origin' header is found or if it does not match. * `host` \- content of the HTTP 'Host' header (e.g. 'example.com:8080'). * `hostname` \- the hostname part of the 'Host' header (e.g. 'example.com'). * `id` \- a unique request identifier (using the format '{now}:{server.info.id}:{5 digits counter}'). * `received` \- request reception timestamp. * `referrer` \- content of the HTTP 'Referrer' (or 'Referer') header. * `remoteAddress` \- remote client IP address. * `remotePort` \- remote client port. * `responded` \- request response timestamp (`0` is not responded yet or response failed when `completed` is set). Note that the `request.info` object is not meant to be modified. #### `request.isInjected` [](#-requestisinjected) Access: read only. `true` if the request was created via [`server.inject()`](#server.inject\(\)), and `false` otherwise. #### `request.logs` [](#-requestlogs) Access: read only. An array containing the logged request events. Note that this array will be empty if route [`log.collect`](#route.options.log) is set to `false`. #### `request.method` [](#-requestmethod) Access: read only. The request method in lower case (e.g. `'get'`, `'post'`). #### `request.mime` [](#-requestmime) Access: read only. The parsed content-type header. Only available when payload parsing enabled and no payload error occurred. #### `request.orig` [](#-requestorig) Access: read only. An object containing the values of `params`, `query`, `payload` and `state` before any validation modifications made. Only set when input validation is performed. #### `request.params` [](#-requestparams) Access: read only. An object where each key is a path parameter name with matching value as described in [Path parameters](#path-parameters). #### `request.paramsArray` [](#-requestparamsarray) Access: read only. An array containing all the path `params` values in the order they appeared in the path. #### `request.path` [](#-requestpath) Access: read only. The request URI's [pathname](https://nodejs.org/api/url.html#url_urlobject_pathname) component. #### `request.payload` [](#-requestpayload) Access: read only / write in `'onRequest'` extension method. The request payload based on the route `payload.output` and `payload.parse` settings. Set to `undefined` in `'onRequest'` extension methods and can be overridden to any non-`undefined` value to bypass payload processing. #### `request.plugins` [](#-requestplugins) Access: read / write. Plugin-specific state. Provides a place to store and pass request-level plugin data. The `plugins` is an object where each key is a plugin name and the value is the state. #### `request.pre` [](#-requestpre) Access: read only. An object where each key is the name assigned by a [route pre-handler methods](#route.options.pre) function. The values are the raw values provided to the continuation function as argument. For the wrapped response object, use `responses`. #### `request.response` [](#-requestresponse) Access: read / write (see limitations below). The response object when set. The object can be modified but must not be assigned another object. To replace the response with another from within an [extension point](#server.ext\(\)), return a new response value. Contains an error when a request terminates prematurely when the client disconnects. #### `request.preResponses` [](#-requestpreresponses) Access: read only. Same as `pre` but represented as the response object created by the pre method. #### `request.query` [](#-requestquery) Access: read only. An object where each key is a query parameter name and each matching value is the parameter value or an array of values if a parameter repeats. Can be modified indirectly via [request.setUrl](#request.setUrl\(\)). #### `request.raw` [](#-requestraw) Access: read only. An object containing the Node HTTP server objects. **Direct interaction with these raw objects is not recommended.** * `req` \- the node request object. * `res` \- the node response object. #### `request.route` [](#-requestroute) Access: read only. The request route information object, where: * `method` \- the route HTTP method. * `path` \- the route path. * `vhost` \- the route vhost option if configured. * `realm` \- the [active realm](#server.realm) associated with the route. * `settings` \- the [route options](#route-options) object with all defaults applied. * `fingerprint` \- the route internal normalized string representing the normalized path. #### `request.server` [](#-requestserver) Access: read only and the public server interface. The server object. #### `request.state` [](#-requeststate) Access: read only. An object containing parsed HTTP state information (cookies) where each key is the cookie name and value is the matching cookie content after processing using any registered cookie definition. #### `request.url` [](#-requesturl) Access: read only. The parsed request URI. ### `request.generateResponse(source, [options])` [](#-requestgenerateresponsesource-options) Returns a [`response`](#response-object) which you can pass to [h.response()](#h.response\(\)) where: * `source` \- the value to set as the source of [h.response()](#h.response\(\)), optional. * `options` \- optional object with the following optional properties: * `variety` \- a sting name of the response type (e.g. `'file'`). * `prepare` \- a function with the signature `async function(response)` used to prepare the response after it is returned by a [lifecycle method](#lifecycle-methods) such as setting a file descriptor, where: * `response` \- the response object being prepared. * must return the prepared response object (`response`). * may throw an error which is used as the prepared response. * `marshal` \- a function with the signature `async function(response)` used to prepare the response for transmission to the client before it is sent, where: * `response` \- the response object being marshaled. * must return the prepared value (not as response object) which can be any value accepted by the [`h.response()`](#h.response\(\)) `value` argument. * may throw an error which is used as the marshaled value. * `close` \- a function with the signature `function(response)` used to close the resources opened by the response object (e.g. file handlers), where: * `response` \- the response object being marshaled. * should not throw errors (which are logged but otherwise ignored). ### `request.active()` [](#-requestactive) Returns `true` when the request is active and processing should continue and `false` when the request terminated early or completed its lifecycle. Useful when request processing is a resource-intensive operation and should be terminated early if the request is no longer active (e.g. client disconnected or aborted early). const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); server.route({ method: 'POST', path: '/worker', handler: function (request, h) { // Do some work... // Check if request is still active if (!request.active()) { return h.close; } // Do some more work... return null; } }); ### `request.log(tags, [data])` [](#-requestlogtags-data) Logs request-specific events. When called, the server emits a [`'request'` event](#server.events.request) on the `'app'` channel which can be used by other listeners or [plugins](#plugins). The arguments are: * `tags` \- a string or an array of strings (e.g. `['error', 'database', 'read']`) used to identify the event. Tags are used instead of log levels and provide a much more expressive mechanism for describing and filtering events. * `data` \- (optional) an message string or object with the application data being logged. If `data` is a function, the function signature is `function()` and it called once to generate (return value) the actual data emitted to the listeners. const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80, routes: { log: { collect: true } } }); server.events.on({ name: 'request', channels: 'app' }, (request, event, tags) => { if (tags.error) { console.log(event); } }); const handler = function (request, h) { request.log(['test', 'error'], 'Test event'); return null; }; Note that any logs generated by the server internally will be emitted using the [`'request'` event](#server.events.request) on the `'internal'` channel. server.events.on({ name: 'request', channels: 'internal' }, (request, event, tags) => { console.log(event); }); ### `request.route.auth.access(request)` [](#-requestrouteauthaccessrequest) Validates a request against the route's authentication [`access`](#route.options.auth.access) configuration, where: * `request` \- the [request object](#request). Return value: `true` if the `request` would have passed the route's access requirements. Note that the route's authentication mode and strategies are ignored. The only match is made between the `request.auth.credentials` scope and entity information and the route [`access`](#route.options.auth.access) configuration. If the route uses dynamic scopes, the scopes are constructed against the [`request.query`](#request.query), [`request.params`](#request.params), [`request.payload`](#request.payload), and [`request.auth.credentials`](#request.auth) which may or may not match between the route and the request's route. If this method is called using a request that has not been authenticated (yet or not at all), it will return `false` if the route requires any authentication. ### `request.setMethod(method)` [](#-requestsetmethodmethod) Changes the request method before the router begins processing the request where: * `method` \- is the request HTTP method (e.g. `'GET'`). const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); const onRequest = function (request, h) { // Change all requests to 'GET' request.setMethod('GET'); return h.continue; }; server.ext('onRequest', onRequest); Can only be called from an `'onRequest'` extension method. ### `request.setUrl(url, [stripTrailingSlash]` [](#-requestseturlurl-striptrailingslash) Changes the request URI before the router begins processing the request where: * `url` \- the new request URI. `url` can be a string or an instance of [`Url.URL`](https://nodejs.org/dist/latest-v10.x/docs/api/url.html#url_class_url) in which case `url.href` is used. * `stripTrailingSlash` \- if `true`, strip the trailing slash from the path. Defaults to `false`. const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); const onRequest = function (request, h) { // Change all requests to '/test' request.setUrl('/test'); return h.continue; }; server.ext('onRequest', onRequest); Can only be called from an `'onRequest'` extension method. ## Plugins [](#plugins) Plugins provide a way to organize application code by splitting the server logic into smaller components. Each plugin can manipulate the server through the standard server interface, but with the added ability to sandbox certain properties. For example, setting a file path in one plugin doesn't affect the file path set in another plugin. A plugin is an object with the following properties: * `register` \- (required) the registration function with the signature `async function(server, options)` where: * `server` \- the server object with a plugin-specific [`server.realm`](#server.realm). * `options` \- any options passed to the plugin during registration via [`server.register()`](#server.register\(\)). * `name` \- (required) the plugin name string. The name is used as a unique key. Published plugins (e.g. published in the npm registry) should use the same name as the name field in their 'package.json' file. Names must be unique within each application. * `version` \- (optional) plugin version string. The version is only used informatively to enable other plugins to find out the versions loaded. The version should be the same as the one specified in the plugin's 'package.json' file. * `multiple` \- (optional) if `true`, allows the plugin to be registered multiple times with the same server. Defaults to `false`. * `dependencies` \- (optional) a string or an array of strings indicating a plugin dependency. Same as setting dependencies via [`server.dependency()`](#server.dependency\(\)). * `requirements` \- (optional) object declaring the plugin supported [semver range](https://semver.org/) for: * `node` runtime [semver range](https://nodejs.org/en/about/releases/) string. * `hapi` framework [semver range](#server.version) string. * `once` \- (optional) if `true`, will only register the plugin once per server. If set, overrides the `once` option passed to [`server.register()`](#server.register\(\)). Defaults to no override. const plugin = { name: 'test', version: '1.0.0', register: function (server, options) { server.route({ method: 'GET', path: '/test', handler: function (request, h) { return 'ok'; } }); } }; Alternatively, the `name` and `version` can be included via the `pkg` property containing the 'package.json' file for the module which already has the name and version included: const plugin = { pkg: require('./package.json'), register: function (server, options) { server.route({ method: 'GET', path: '/test', handler: function (request, h) { return 'ok'; } }); } }; ![clipboard](/img/clipboardCheck.png) --- # hapi Documentation # Source: https://hapi.dev/family/ Modules Sort By: Name Stars Forks Updated Clear # hapi Modules [accept](/module/accept) HTTP Accept-* headers parsing. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/accept) ![star](/img/star.png) 54 ![fork](/img/fork.png) 30 Updated: Wed Oct 23 2024 [ammo](/module/ammo) HTTP Range processing utilities. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/ammo) ![star](/img/star.png) 1 ![fork](/img/fork.png) 8 Updated: Wed Oct 23 2024 [b64](/module/b64) Base64 streaming encoder and decoder. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/b64) ![star](/img/star.png) 42 ![fork](/img/fork.png) 13 Updated: Wed Oct 23 2024 [basic](/module/basic) Basic authentication plugin. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/basic) ![star](/img/star.png) 147 ![fork](/img/fork.png) 66 Updated: Wed Oct 23 2024 [bell](/module/bell) Third-party login plugin for hapi.js. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/bell) ![star](/img/star.png) 623 ![fork](/img/fork.png) 211 Updated: Wed Mar 12 2025 [boom](/module/boom) HTTP-friendly error objects. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/boom) ![star](/img/star.png) 2934 ![fork](/img/fork.png) 195 Updated: Wed Oct 23 2024 [bossy](/module/bossy) Command line options parser. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/bossy) ![star](/img/star.png) 45 ![fork](/img/fork.png) 31 Updated: Wed Oct 23 2024 [bounce](/module/bounce) Selective error catching and rewrite rules. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/bounce) ![star](/img/star.png) 176 ![fork](/img/fork.png) 13 Updated: Wed Oct 23 2024 [bourne](/module/bourne) JSON.parse() drop-in replacement with prototype poisoning protection. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/bourne) ![star](/img/star.png) 173 ![fork](/img/fork.png) 13 Updated: Wed Oct 23 2024 [call](/module/call) Simple HTTP Router. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/call) ![star](/img/star.png) 37 ![fork](/img/fork.png) 27 Updated: Wed Oct 23 2024 [catbox](/module/catbox) Multi-strategy object caching service. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/catbox) ![star](/img/star.png) 495 ![fork](/img/fork.png) 74 Updated: Wed Oct 23 2024 [catbox-memcached](/module/catbox-memcached) Memcached adaptor for [catbox](https://github.com/hapijs/catbox). [![github logo](/img/githubLogo.png)](https://github.com/hapijs/catbox-memcached) ![star](/img/star.png) 11 ![fork](/img/fork.png) 18 Updated: Sun Nov 06 2022 [catbox-memory](/module/catbox-memory) Memory adaptor for [catbox](https://github.com/hapijs/catbox). [![github logo](/img/githubLogo.png)](https://github.com/hapijs/catbox-memory) ![star](/img/star.png) 33 ![fork](/img/fork.png) 30 Updated: Wed Oct 23 2024 [catbox-object](/module/catbox-object) Object cache adaptor for [catbox](https://github.com/hapijs/catbox). [![github logo](/img/githubLogo.png)](https://github.com/hapijs/catbox-object) ![star](/img/star.png) 2 ![fork](/img/fork.png) 7 Updated: Wed Oct 23 2024 [catbox-redis](/module/catbox-redis) Redis adapter for [catbox](https://github.com/hapijs/catbox). [![github logo](/img/githubLogo.png)](https://github.com/hapijs/catbox-redis) ![star](/img/star.png) 70 ![fork](/img/fork.png) 63 Updated: Wed Oct 23 2024 [code](/module/code) BDD assertion library. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/code) ![star](/img/star.png) 232 ![fork](/img/fork.png) 74 Updated: Wed Oct 23 2024 [content](/module/content) HTTP Content-* headers parsing. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/content) ![star](/img/star.png) 7 ![fork](/img/fork.png) 13 Updated: Wed Oct 23 2024 [cookie](/module/cookie) Cookie authentication plugin. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/cookie) ![star](/img/star.png) 229 ![fork](/img/fork.png) 99 Updated: Wed Oct 23 2024 [crumb](/module/crumb) CSRF crumb generation and validation for hapi. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/crumb) ![star](/img/star.png) 171 ![fork](/img/fork.png) 50 Updated: Wed Oct 23 2024 [cryptiles](/module/cryptiles) General purpose crypto utilities. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/cryptiles) ![star](/img/star.png) 181 ![fork](/img/fork.png) 26 Updated: Wed Oct 23 2024 [eslint-plugin](/module/eslint-plugin) ESLint plugin containing hapi style guide rules and config. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/eslint-plugin) ![star](/img/star.png) 22 ![fork](/img/fork.png) 10 Updated: Tue Oct 22 2024 [file](/module/file) General purpose file utilities. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/file) ![star](/img/star.png) 5 ![fork](/img/fork.png) 7 Updated: Mon May 30 2022 [glue](/module/glue) Server composer for hapi.js. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/glue) ![star](/img/star.png) 245 ![fork](/img/fork.png) 62 Updated: Wed Oct 23 2024 [h2o2](/module/h2o2) Proxy handler for hapi.js. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/h2o2) ![star](/img/star.png) 164 ![fork](/img/fork.png) 63 Updated: Wed Oct 23 2024 [heavy](/module/heavy) Measure process load. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/heavy) ![star](/img/star.png) 75 ![fork](/img/fork.png) 15 Updated: Wed Oct 23 2024 [hoek](/module/hoek) Utility methods for the hapi ecosystem. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/hoek) ![star](/img/star.png) 482 ![fork](/img/fork.png) 173 Updated: Wed Aug 06 2025 [inert](/module/inert) Static file and directory handlers for hapi.js. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/inert) ![star](/img/star.png) 237 ![fork](/img/fork.png) 49 Updated: Wed Oct 23 2024 [iron](/module/iron) Encapsulated tokens (encrypted and mac'ed objects). [![github logo](/img/githubLogo.png)](https://github.com/hapijs/iron) ![star](/img/star.png) 635 ![fork](/img/fork.png) 54 Updated: Wed Oct 23 2024 [jwt](/module/jwt) JWT (JSON Web Token) Authentication. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/jwt) ![star](/img/star.png) 36 ![fork](/img/fork.png) 25 Updated: Sat Mar 16 2024 [lab](/module/lab) Node test utility. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/lab) ![star](/img/star.png) 740 ![fork](/img/fork.png) 177 Updated: Wed Jun 18 2025 [log](/module/log) Logging for hapi framework. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/log) ![star](/img/star.png) 6 ![fork](/img/fork.png) 5 Updated: Wed Oct 23 2024 [mimos](/module/mimos) Mime database interface. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/mimos) ![star](/img/star.png) 20 ![fork](/img/fork.png) 13 Updated: Wed Oct 23 2024 [nes](/module/nes) WebSocket adapter plugin for hapi routes. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/nes) ![star](/img/star.png) 502 ![fork](/img/fork.png) 87 Updated: Wed Jan 08 2025 [nigel](/module/nigel) Boyer-Moore-Horspool algorithms [![github logo](/img/githubLogo.png)](https://github.com/hapijs/nigel) ![star](/img/star.png) 16 ![fork](/img/fork.png) 10 Updated: Wed Oct 23 2024 [oppsy](/module/oppsy) An EventEmitter useful for collecting hapi server ops information. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/oppsy) ![star](/img/star.png) 25 ![fork](/img/fork.png) 20 Updated: Wed Oct 23 2024 [pez](/module/pez) Multipart parser. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/pez) ![star](/img/star.png) 34 ![fork](/img/fork.png) 17 Updated: Wed Oct 23 2024 [podium](/module/podium) Event emitter with async features. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/podium) ![star](/img/star.png) 87 ![fork](/img/fork.png) 22 Updated: Tue Jan 07 2025 [scooter](/module/scooter) User-agent information plugin. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/scooter) ![star](/img/star.png) 46 ![fork](/img/fork.png) 24 Updated: Sat Nov 11 2023 [shot](/module/shot) Injects a fake HTTP request/response into your node server logic. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/shot) ![star](/img/star.png) 197 ![fork](/img/fork.png) 42 Updated: Wed Aug 13 2025 [somever](/module/somever) Semantic versioning rules parser, compatible with version ranges used in package.json files and the canonical [semver](https://www.npmjs.com/package/semver) module. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/somever) ![star](/img/star.png) 0 ![fork](/img/fork.png) 10 Updated: Wed Oct 23 2024 [statehood](/module/statehood) HTTP State Management Utilities. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/statehood) ![star](/img/star.png) 20 ![fork](/img/fork.png) 26 Updated: Fri Feb 28 2025 [subtext](/module/subtext) HTTP payload parser. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/subtext) ![star](/img/star.png) 24 ![fork](/img/fork.png) 25 Updated: Wed Aug 06 2025 [teamwork](/module/teamwork) Wait for multiple callbacks [![github logo](/img/githubLogo.png)](https://github.com/hapijs/teamwork) ![star](/img/star.png) 14 ![fork](/img/fork.png) 13 Updated: Wed Oct 23 2024 [topo](/module/topo) Topological sorting with grouping support. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/topo) ![star](/img/star.png) 108 ![fork](/img/fork.png) 26 Updated: Wed Oct 23 2024 [vise](/module/vise) Treat multiple buffers as one. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/vise) ![star](/img/star.png) 7 ![fork](/img/fork.png) 13 Updated: Wed Oct 23 2024 [vision](/module/vision) Template rendering support for hapi.js. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/vision) ![star](/img/star.png) 197 ![fork](/img/fork.png) 69 Updated: Wed Oct 23 2024 [wreck](/module/wreck) HTTP client utilities. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/wreck) ![star](/img/star.png) 382 ![fork](/img/fork.png) 103 Updated: Wed Apr 10 2024 [yar](/module/yar) A hapi session manager. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/yar) ![star](/img/star.png) 133 ![fork](/img/fork.png) 59 Updated: Sat Mar 22 2025 --- # hapi Documentation # Source: https://hapi.dev/plugins/ Plugins * [Authorization](#authorization) * [Authentication](#authentication) * [Automation/Integrations](#automation) * [Boilerplate](#boilerplate) * [Documentation](#documentation) * [Encoding](#encoding) * [GraphQL](#graphql) * [Kubernetes](#kubernetes) * [Hypermedia](#hypermedia) * [Localization/Internationalization](#localization) * [Logging/Metrics](#logging) * [Messaging](#messaging) * [Security](#security) * [Session](#session) * [Templating](#templating) * [Testing](#testing) * [Utility](#utility) * [Validation](#validation) * [hapi pal](#hapipal) # Plugins There are dozens of plugins for hapi, ranging from documentation to authentication, and much more. If you wrote or use a plugin that you don't see on this list, please send us a [pull request](https://github.com/hapijs/hapi.dev/blob/master/static/lib/plugins.json). ![](/img/family.svg) \- Designates an offical hapi family plugin ## Authorization [ hacli ](https://github.com/antoniogiordano/hacli) ACL support based on permissions hierarchy [![github logo](/img/githubLogo.png)](https://github.com/antoniogiordano/hacli) [ hapi-acl-auth ](https://github.com/charlesread/hapi-acl-auth) Authentication provider agnostic authorization plugin for hapi apps [![github logo](/img/githubLogo.png)](https://github.com/charlesread/hapi-acl-auth) [ hapi-authorization ](https://github.com/toymachiner62/hapi-authorization) ACL Support for hapi apps [![github logo](/img/githubLogo.png)](https://github.com/toymachiner62/hapi-authorization) [ hapi-auth-ip-whitelist ](https://github.com/chamini2/hapi-auth-ip-whitelist) IP whitelisting auth scheme [![github logo](/img/githubLogo.png)](https://github.com/chamini2/hapi-auth-ip-whitelist) [ hapi-rbac ](https://github.com/franciscogouveia/hapi-rbac) A Rule Based Access Control module for hapi [![github logo](/img/githubLogo.png)](https://github.com/franciscogouveia/hapi-rbac) ## Authentication [ basic ](https://hapi.dev/family/basic) ![](/img/family.svg) An HTTP Basic authentication scheme [![github logo](/img/githubLogo.png)](https://github.com/hapijs/basic) ![star](/img/star.png) 147 ![fork](/img/fork.png) 66 Updated: Wed Oct 23 2024 [ bell ](https://hapi.dev/family/bell) ![](/img/family.svg) Third-party login plugin for hapi with built in Facebook, GitHub, Google, Instagram, LinkedIn, Twitter, Yahoo, Foursquare, VK, ArcGIS Online and Windows Live support [![github logo](/img/githubLogo.png)](https://github.com/hapijs/bell) ![star](/img/star.png) 623 ![fork](/img/fork.png) 211 Updated: Wed Mar 12 2025 [ cookie ](https://hapi.dev/family/cookie) ![](/img/family.svg) A cookie-based session authentication scheme [![github logo](/img/githubLogo.png)](https://github.com/hapijs/cookie) ![star](/img/star.png) 229 ![fork](/img/fork.png) 99 Updated: Wed Oct 23 2024 [ hapi-auth-bearer-token ](https://github.com/johnbrett/hapi-auth-bearer-token) A bearer token based authentication scheme [![github logo](/img/githubLogo.png)](https://github.com/johnbrett/hapi-auth-bearer-token) [ hapi-auth-jwt2 ](https://www.npmjs.com/package/hapi-auth-jwt2) Simplified JSON Web Token (JWT) authentication plugin [![github logo](/img/githubLogo.png)](https://www.npmjs.com/package/hapi-auth-jwt2) [ hapi-jsonwebtoken ](https://github.com/odorisioe/hapi-jsonwebtoken) JsonWebToken implementation for Hapi.js v17+ with authentication plugin [![github logo](/img/githubLogo.png)](https://github.com/odorisioe/hapi-jsonwebtoken) [ hapi-auth-keycloak ](https://github.com/felixheck/hapi-auth-keycloak) JSON Web Token based Authentication powered by Keycloak [![github logo](/img/githubLogo.png)](https://github.com/felixheck/hapi-auth-keycloak) [ hapi-now-auth ](https://github.com/puchesjr/hapi-now-auth) A Hapi v17+ plugin for simplified JSON Web Token (JWT) and Bearer auth tokens [![github logo](/img/githubLogo.png)](https://github.com/puchesjr/hapi-now-auth) [ hapi-openid-connect ](https://github.com/gaaiatinc/hapi-openid-connect) A Hapi plugin that implements the OpenID-Connect authorization flow [![github logo](/img/githubLogo.png)](https://github.com/gaaiatinc/hapi-openid-connect) [ hapi-passport-saml ](https://github.com/molekilla/hapi-passport-saml) A Hapi plugin that wraps passport-saml for SAML SSO [![github logo](/img/githubLogo.png)](https://github.com/molekilla/hapi-passport-saml) [ hapi-saml2 ](https://github.com/toriihq/hapi-saml2) A Hapi plugin that wraps node-saml for SAML SSO [![github logo](/img/githubLogo.png)](https://github.com/toriihq/hapi-saml2) [ jwt ](https://hapi.dev/family/jwt) ![](/img/family.svg) JWT (JSON Web Token) Authentication. [![github logo](/img/githubLogo.png)](https://github.com/hapijs/jwt) ![star](/img/star.png) 36 ![fork](/img/fork.png) 25 Updated: Sat Mar 16 2024 ## Automation/Integrations [ apitraffic-hapi ](https://github.com/apitraffic/apitraffic-hapi) Seamlessly integrate with over 240 external systems [![github logo](/img/githubLogo.png)](https://github.com/apitraffic/apitraffic-hapi) ## Boilerplate [ hapi-mvc ](https://github.com/the-provost/hapi-mvc) MVC structure and boilerplating for Hapi.js Projects [![github logo](/img/githubLogo.png)](https://github.com/the-provost/hapi-mvc) ## Documentation [ hapi-ending ](https://github.com/desirable-objects/hapi-ending.git) A simplified browsable api documentation generator [![github logo](/img/githubLogo.png)](https://github.com/desirable-objects/hapi-ending.git) [ hapi-swagger ](https://github.com/glennjones/hapi-swagger) A swagger documentation UI generator plugin for hapi [![github logo](/img/githubLogo.png)](https://github.com/glennjones/hapi-swagger) [ hapi-swaggered ](https://github.com/z0mt3c/hapi-swaggered) A plugin to generate swagger v2.0 compliant specifications based on hapi routes and joi schemas [![github logo](/img/githubLogo.png)](https://github.com/z0mt3c/hapi-swaggered) [ hapi-swaggered-ui ](https://github.com/z0mt3c/hapi-swaggered-ui) A plugin to serve and configure swagger-ui [![github logo](/img/githubLogo.png)](https://github.com/z0mt3c/hapi-swaggered-ui) [ optic-hapi-middleware ](https://www.npmjs.com/package/@useoptic/hapi-middleware) Document API endpoints using Optic [![github logo](/img/githubLogo.png)](https://github.com/opticdev/optic-node/tree/main/frameworks/hapi) ## Encoding [ brok ](https://github.com/kanongil/brok) Brotli encoder and decoder [![github logo](/img/githubLogo.png)](https://github.com/kanongil/brok) ## GraphQL [ hapi-plugin-graphiql ](https://github.com/rse/hapi-plugin-graphiql) HAPI plugin for integrating GraphiQL, an interactive GraphQL user interface [![github logo](/img/githubLogo.png)](https://github.com/rse/hapi-plugin-graphiql) [ graphi ](https://www.npmjs.com/package/graphi) Simple to use hapi GraphQL server plugin [![github logo](/img/githubLogo.png)](https://github.com/geek/graphi) ## Kubernetes [ hapi-on-kubernetes ](https://github.com/NextStepGuru/hapi-on-kubernetes) A simple plugin design to connect the kubernetes probes to the lifecycles of Hapi [![github logo](/img/githubLogo.png)](https://github.com/NextStepGuru/hapi-on-kubernetes) ## Hypermedia [ boom ](https://hapi.dev/family/boom) ![](/img/family.svg) HTTP-friendly error objects [![github logo](/img/githubLogo.png)](https://github.com/hapijs/boom) ![star](/img/star.png) 2934 ![fork](/img/fork.png) 195 Updated: Wed Oct 23 2024 [ hapi-openapi ](https://github.com/krakenjs/hapi-openapi) hapi plugin to build design-driven apis with OpenAPI (formerly swagger). [![github logo](/img/githubLogo.png)](https://github.com/krakenjs/hapi-openapi) [ hapi-http-problem-details ](https://github.com/PDMLab/hapi-http-problem-details) Create HTTP Problem Details (RFC7807) for hapi application errors [![github logo](/img/githubLogo.png)](https://github.com/PDMLab/hapi-http-problem-details) [ inert ](https://hapi.dev/family/inert) ![](/img/family.svg) Static file and directory handlers [![github logo](/img/githubLogo.png)](https://github.com/hapijs/inert) ![star](/img/star.png) 237 ![fork](/img/fork.png) 49 Updated: Wed Oct 23 2024 ## Localization/Internationalization [ hapi-i18n ](https://github.com/codeva/hapi-i18n) Translation module for hapi based on mashpie's i18n module [![github logo](/img/githubLogo.png)](https://github.com/codeva/hapi-i18n) [ hapi-locale ](https://github.com/ozum/hapi-locale) Configurable plugin to determine request language from URL, Cookie, Query and Header [![github logo](/img/githubLogo.png)](https://github.com/ozum/hapi-locale) ## Logging/Metrics [ apitraffic-hapi ](https://github.com/apitraffic/apitraffic-hapi) Collects API request/response data for monitoring and analytical purposes [![github logo](/img/githubLogo.png)](https://github.com/apitraffic/apitraffic-hapi) [ blipp ](https://github.com/danielb2/blipp) Displays the routes table at startup [![github logo](/img/githubLogo.png)](https://github.com/danielb2/blipp) [ hapi-statsd ](https://github.com/mac-/hapi-statsd) Sends request round trip metrics to statsd [![github logo](/img/githubLogo.png)](https://github.com/mac-/hapi-statsd) [ hapi-plugin-traffic ](https://github.com/rse/hapi-plugin-traffic) Network traffic accounting [![github logo](/img/githubLogo.png)](https://github.com/rse/hapi-plugin-traffic) [ hapi-alive ](https://github.com/idosh/hapi-alive) Health route for your hapi.js server [![github logo](/img/githubLogo.png)](https://github.com/idosh/hapi-alive) [ hapi-pino ](https://github.com/mcollina/hapi-pino) Fast and simple JSON logger [![github logo](/img/githubLogo.png)](https://github.com/mcollina/hapi-pino) [ hapijs-status-monitor ](https://github.com/ziyasal/hapijs-status-monitor) Realtime Monitoring solution for Hapi.js apps, inspired by GitHub Status [![github logo](/img/githubLogo.png)](https://github.com/ziyasal/hapijs-status-monitor) [ laabr ](https://github.com/felixheck/laabr) Well-formatted pino logger for hapi.js - inspired by morgan [![github logo](/img/githubLogo.png)](https://github.com/felixheck/laabr) [ hapi-k8s-health ](https://github.com/radenui/hapi-k8s-health) Prometheus metrics and liveness / readiness probes [![github logo](/img/githubLogo.png)](https://github.com/radenui/hapi-k8s-health) [ hapi-audit-rest ](https://github.com/denlap007/hapi-audit-rest) Hapi.js plugin that generates audit logs for RESTful APIs [![github logo](/img/githubLogo.png)](https://github.com/denlap007/hapi-audit-rest) ## Messaging [ hapi-plugin-websocket ](https://github.com/rse/hapi-plugin-websocket) Seamless WebSocket integration by injecting WebSocket messages as HTTP request [![github logo](/img/githubLogo.png)](https://github.com/rse/hapi-plugin-websocket) [ multines ](https://github.com/mcollina/multines) Support for multi-process publish/subscribe for nes [![github logo](/img/githubLogo.png)](https://github.com/mcollina/multines) [ nes ](https://hapi.dev/family/nes) ![](/img/family.svg) WebSocket adapter plugin for hapi routes [![github logo](/img/githubLogo.png)](https://github.com/hapijs/nes) ![star](/img/star.png) 502 ![fork](/img/fork.png) 87 Updated: Wed Jan 08 2025 [ susie ](https://github.com/mtharrison/susie) Server-Sent Events for hapi with support for streaming events [![github logo](/img/githubLogo.png)](https://github.com/mtharrison/susie) [ hapi-wechat ](https://github.com/dhso/hapi-wechat) Wechat plugin for hapi [![github logo](/img/githubLogo.png)](https://github.com/dhso/hapi-wechat) ## Security [ blankie ](https://github.com/nlf/blankie) A plugin that makes Content-Security-Policy headers easy [![github logo](/img/githubLogo.png)](https://github.com/nlf/blankie) [ crumb ](https://hapi.dev/family/crumb) ![](/img/family.svg) CSRF crumb generation and validation for hapi [![github logo](/img/githubLogo.png)](https://github.com/hapijs/crumb) ![star](/img/star.png) 171 ![fork](/img/fork.png) 50 Updated: Wed Oct 23 2024 [ ralphi ](https://github.com/yonjah/ralphi) Simple and minimal rate limiting and bruteforce protection [![github logo](/img/githubLogo.png)](https://github.com/yonjah/ralphi) ## Session [ hapi-server-session ](https://github.com/btmorex/hapi-server-session) Simple server-side session support for hapi [![github logo](/img/githubLogo.png)](https://github.com/btmorex/hapi-server-session) [ yar ](https://hapi.dev/family/yar) ![](/img/family.svg) A hapi session plugin and cookie jar [![github logo](/img/githubLogo.png)](https://github.com/hapijs/yar) ![star](/img/star.png) 133 ![fork](/img/fork.png) 59 Updated: Sat Mar 22 2025 ## Templating [ ndsk ](https://github.com/ndskstack/ndsk) React framework developed based on hapi [![github logo](/img/githubLogo.png)](https://github.com/ndskstack/ndsk) [ hapi-react-views ](https://github.com/jedireza/hapi-react-views) A hapi view engine for React components [![github logo](/img/githubLogo.png)](https://github.com/jedireza/hapi-react-views) [ vision ](https://hapi.dev/family/vision) ![](/img/family.svg) Templates rendering support [![github logo](/img/githubLogo.png)](https://github.com/hapijs/vision) ![star](/img/star.png) 197 ![fork](/img/fork.png) 69 Updated: Wed Oct 23 2024 ## Testing [ lab ](https://hapi.dev/family/lab) ![](/img/family.svg) A simple testing utility with code coverage analysis [![github logo](/img/githubLogo.png)](https://github.com/hapijs/lab) ![star](/img/star.png) 740 ![fork](/img/fork.png) 177 Updated: Wed Jun 18 2025 [ shot ](https://hapi.dev/family/shot) ![](/img/family.svg) Injects a fake HTTP request/response into your node server logic [![github logo](/img/githubLogo.png)](https://github.com/hapijs/shot) ![star](/img/star.png) 197 ![fork](/img/fork.png) 42 Updated: Wed Aug 13 2025 ## Utility [ admin-bro-hapijs ](https://github.com/SoftwareBrothers/admin-bro-hapijs) AdminBro - Admin Panel integrated into your hapijs routes [![github logo](/img/githubLogo.png)](https://github.com/SoftwareBrothers/admin-bro-hapijs) [ akaya ](https://github.com/felixheck/akaya) Generate URIs fast based on named hapi routes their parameters [![github logo](/img/githubLogo.png)](https://github.com/felixheck/akaya) [ bissle ](https://github.com/felixheck/bissle) Minimalist HALicious pagination reply interface for HapiJS [![github logo](/img/githubLogo.png)](https://github.com/felixheck/bissle) [ configue ](https://github.com/AdrieanKhisbe/configue) Config plugin for Hapi [![github logo](/img/githubLogo.png)](https://github.com/AdrieanKhisbe/configue) [ cron ](https://github.com/antonsamper/hapi-cron) Cron jobs for internal hapi.js routes [![github logo](/img/githubLogo.png)](https://github.com/antonsamper/hapi-cron) [ cron-cluster ](https://github.com/Meg4mi/hapi-cron-cluster) Cron jobs for internal hapi.js routes with leader election (mongodb or redis) - cluster mode [![github logo](/img/githubLogo.png)](https://github.com/Meg4mi/hapi-cron-cluster) [ disinfect ](https://github.com/genediazjr/disinfect) Request query, payload, and params sanitization [![github logo](/img/githubLogo.png)](https://github.com/genediazjr/disinfect) [ errorh ](https://github.com/genediazjr/errorh) Custom error pages [![github logo](/img/githubLogo.png)](https://github.com/genediazjr/errorh) [ hapi-scaffold ](https://github.com/jeffsouza/hapi-scaffold) Code generation for the hapijs framework [![github logo](/img/githubLogo.png)](https://github.com/jeffsouza/hapi-scaffold) [ hapi-api-version ](https://github.com/p-meier/hapi-api-version) An API versioning plugin for hapi. [![github logo](/img/githubLogo.png)](https://github.com/p-meier/hapi-api-version) [ hapi-auto-route ](https://github.com/hsitraka/hapi-auto-route) Automatically load routes from directory [![github logo](/img/githubLogo.png)](https://github.com/hsitraka/hapi-auto-route) [ hapi-aws ](https://github.com/ar4mirez/hapi-aws) A HapiJS plugin for AWS services. [![github logo](/img/githubLogo.png)](https://github.com/ar4mirez/hapi-aws) [ hapi-bookshelf-serializer ](https://github.com/lob/hapi-bookshelf-serializer) Serialize Bookshelf.js models sent through Hapi reply [![github logo](/img/githubLogo.png)](https://github.com/lob/hapi-bookshelf-serializer) [ hapi-boom-decorators ](https://github.com/brainsiq/hapi-boom-decorators) Exposes boom errors through the hapi reply interface [![github logo](/img/githubLogo.png)](https://github.com/brainsiq/hapi-boom-decorators) [ hapi-ecma-decorators ](https://github.com/mehl/hapi-ecma-decorators) New Decorators for hapi routes following ECMA/TC39 Proposal Stage 3 [![github logo](/img/githubLogo.png)](https://github.com/mehl/hapi-ecma-decorators) [ hapi-decorators ](https://github.com/knownasilya/hapi-decorators) Decorators for HapiJS routes [![github logo](/img/githubLogo.png)](https://github.com/knownasilya/hapi-decorators) [ hapi-dev-errors ](https://github.com/fs-opensource/hapi-dev-errors) Get better error details during development and skip the command line round trip to catch the issue [![github logo](/img/githubLogo.png)](https://github.com/fs-opensource/hapi-dev-errors) [ hapi-error ](https://www.npmjs.com/package/hapi-error) Custom error handling with ability to pass an object and render a custom error template or redirect to a specific url on error. [![github logo](/img/githubLogo.png)](https://www.npmjs.com/package/hapi-error) [ hapi-gate ](https://github.com/captainjackrana/hapi-gate) Easily handle http to https and www/non-www redirections [![github logo](/img/githubLogo.png)](https://github.com/captainjackrana/hapi-gate) [ hapi-geo-locate ](https://github.com/fs-opensource/hapi-geo-locate) Geo locate requests by IP and provide the user’s location in your route handlers [![github logo](/img/githubLogo.png)](https://github.com/fs-opensource/hapi-geo-locate) [ hapi-level-db ](https://github.com/maxnachlinger/hapi-level-db) HapiJS / LevelDB integration [![github logo](/img/githubLogo.png)](https://github.com/maxnachlinger/hapi-level-db) [ hapi-maxmind-web ](https://github.com/midnightcodr/hapi-maxmind-web) Hapi.js plugin for MaxMind GeoIP2 Web Service [![github logo](/img/githubLogo.png)](https://github.com/midnightcodr/hapi-maxmind-web) [ hapi-mongo-models ](https://github.com/jedireza/hapi-mongo-models) MongoDB object models for hapi applications [![github logo](/img/githubLogo.png)](https://github.com/jedireza/hapi-mongo-models) [ hapi-mongodb ](https://github.com/Marsup/hapi-mongodb) A simple Hapi MongoDB connection plugin, accessing one or several connections pools through server or request properties [![github logo](/img/githubLogo.png)](https://github.com/Marsup/hapi-mongodb) [ hapi-mongoose ](https://github.com/asilluron/hapi-mongoose) A lightweight mongoose connection and configuration plugin for Hapi 9+ [![github logo](/img/githubLogo.png)](https://github.com/asilluron/hapi-mongoose) [ @watchup/hapi-mongoose ](https://github.com/watchup/hapi-mongoose) Hapi.js plugin that maps mongoose models to routes [![github logo](/img/githubLogo.png)](https://github.com/watchup/hapi-mongoose) [ hapi-multi-mongo ](https://github.com/metoikos/hapi-multi-mongo) Hapi mongodb connection plugin, especially for multiple connections [![github logo](/img/githubLogo.png)](https://github.com/metoikos/hapi-multi-mongo) [ hapi-mysql2 ](https://github.com/midnightcodr/hapi-mysql2) Another mysql plugin for Hapijs that supports multiple connections, inspired by Marsup/hapi-mongodb [![github logo](/img/githubLogo.png)](https://github.com/midnightcodr/hapi-mysql2) [ hapi-postgres ](https://github.com/liviaerxin/hapi-postgres) Hapi postgres connection plugin, supports both client and pool mode, inspired by Marsup/hapi-mongodb [![github logo](/img/githubLogo.png)](https://github.com/liviaerxin/hapi-postgres) [ hapi-named-routes ](https://github.com/poeticninja/hapi-named-routes) Add named routes to your view templates [![github logo](/img/githubLogo.png)](https://github.com/poeticninja/hapi-named-routes) [ hapio ](https://github.com/caligone/hapio) A simple bridge plugin between HapiJS and SocketIO [![github logo](/img/githubLogo.png)](https://github.com/caligone/hapio) [ hapi-octopus ](https://github.com/ar4mirez/hapi-octopus) A multi-purpose plugin that allows you to autoload methods, handlers, routes and decorators using a simple signature convention. [![github logo](/img/githubLogo.png)](https://github.com/ar4mirez/hapi-octopus) [ hapi-oracledb ](https://github.com/midnightcodr/hapi-oracledb) Oracledb plugin for hapijs. [![github logo](/img/githubLogo.png)](https://github.com/midnightcodr/hapi-oracledb) [ hapi-pagination ](https://github.com/fknop/hapi-pagination) A simple / customizable pagination plugin for HapiJS [![github logo](/img/githubLogo.png)](https://github.com/fknop/hapi-pagination) [ hapi-plugin-co ](https://github.com/rse/hapi-plugin-co) Co-routine based route handlers for asynchronous processing [![github logo](/img/githubLogo.png)](https://github.com/rse/hapi-plugin-co) [ hapi-plugin-header ](https://github.com/rse/hapi-plugin-header) Always send one or more custom HTTP headers, independent of the current route [![github logo](/img/githubLogo.png)](https://github.com/rse/hapi-plugin-header) [ hapi-pulse ](https://github.com/fs-opensource/hapi-pulse) Gracefully stop the hapi server on SIGINT (for graceful PM2 reloads) [![github logo](/img/githubLogo.png)](https://github.com/fs-opensource/hapi-pulse) [ hapi-rate-limitor ](https://github.com/fs-opensource/hapi-rate-limitor) Easy to use rate limiting to prevent brute-force attacks [![github logo](/img/githubLogo.png)](https://github.com/fs-opensource/hapi-rate-limitor) [ hapi-redis2 ](https://github.com/midnightcodr/hapi-redis2) A redis plugin for Hapijs that supports multiple connections, inspired by Marsup/hapi-mongodb [![github logo](/img/githubLogo.png)](https://github.com/midnightcodr/hapi-redis2) [ hapi-request-user ](https://github.com/fs-opensource/hapi-request-user) A hapi plugin that shortcuts “request.auth.credentials” to “request.user” [![github logo](/img/githubLogo.png)](https://github.com/fs-opensource/hapi-request-user) [ hapi-response-time ](https://github.com/pankajpatel/hapi-response-time) A Hapi plugin for adding `x-response-time` header to responses [![github logo](/img/githubLogo.png)](https://github.com/pankajpatel/hapi-response-time) [ hapi-router ](https://github.com/bsiddiqui/hapi-router) A plugin to automatically load your routes [![github logo](/img/githubLogo.png)](https://github.com/bsiddiqui/hapi-router) [ hapi-sanitize-payload ](https://github.com/lob/hapi-sanitize-payload) Hapi plugin to sanitize the request payload [![github logo](/img/githubLogo.png)](https://github.com/lob/hapi-sanitize-payload) [ hapi-sequelizejs ](https://github.com/valtlfelipe/hapi-sequelizejs) A Hapi plugin for Sequelize ORM [![github logo](/img/githubLogo.png)](https://github.com/valtlfelipe/hapi-sequelizejs) [ hoek ](https://hapi.dev/family/hoek) ![](/img/family.svg) General purpose node utilities [![github logo](/img/githubLogo.png)](https://github.com/hapijs/hoek) ![star](/img/star.png) 482 ![fork](/img/fork.png) 173 Updated: Wed Aug 06 2025 [ mrhorse ](https://github.com/mark-bradshaw/mrhorse) Plugin for adding pre-handlers and post-handlers to routes [![github logo](/img/githubLogo.png)](https://github.com/mark-bradshaw/mrhorse) [ patova ](https://github.com/dschenkelman/patova) A limitd plugin for hapi, useful for rate-limiting/throttling [![github logo](/img/githubLogo.png)](https://github.com/dschenkelman/patova) [ rate-limiter-flexible ](https://github.com/animir/node-rate-limiter-flexible) Mature and flexible rate limiter, DDoS and bruteforce protection at any scale in process Memory, Cluster or PM2, Redis, Memcached, MongoDb, etc. Block key for some duration, enable Leaky Bucket analogy, manage failover with insurance options, configure smart key blocking in memory and many others. [![github logo](/img/githubLogo.png)](https://github.com/animir/node-rate-limiter-flexible) [ recourier ](https://github.com/ruiquelhas/recourier) Request lifecycle property sealing [![github logo](/img/githubLogo.png)](https://github.com/ruiquelhas/recourier) [ rest-hapi ](https://github.com/JKHeadley/rest-hapi) A RESTful API generator for hapi [![github logo](/img/githubLogo.png)](https://github.com/JKHeadley/rest-hapi) [ scooter ](https://hapi.dev/family/scooter) ![](/img/family.svg) User-agent information plugin [![github logo](/img/githubLogo.png)](https://github.com/hapijs/scooter) ![star](/img/star.png) 46 ![fork](/img/fork.png) 24 Updated: Sat Nov 11 2023 [ spazy ](https://github.com/AlexanderElias/spazy) Static file and single page application (spa) plugin for hapi [![github logo](/img/githubLogo.png)](https://github.com/AlexanderElias/spazy) [ therealyou ](https://github.com/briandela/therealyou) A plugin for setting the request.info.remoteAddress and request.info.remotePort based on the X-Forwarded-For and X-Forwarded-Port headers [![github logo](/img/githubLogo.png)](https://github.com/briandela/therealyou) [ wozu ](https://github.com/felixheck/wozu) Server decorator to list all defined hapi.js routes [![github logo](/img/githubLogo.png)](https://github.com/felixheck/wozu) [ wurst ](https://github.com/felixheck/wurst) Directory based autoloader for routes [![github logo](/img/githubLogo.png)](https://github.com/felixheck/wurst) [ Wildcard API ](https://github.com/reframejs/wildcard-api) RPC implementation for browser ⇔ Node.js communication. [![github logo](/img/githubLogo.png)](https://github.com/reframejs/wildcard-api) [ topo ](https://hapi.dev/family/topo) ![](/img/family.svg) Topological sorting with grouping support [![github logo](/img/githubLogo.png)](https://hapi.dev/family/topo) ![star](/img/star.png) 108 ![fork](/img/fork.png) 26 Updated: Wed Oct 23 2024 [ wreck ](https://hapi.dev/family/wreck) ![](/img/family.svg) HTTP Client utilities [![github logo](/img/githubLogo.png)](https://github.com/hapijs/wreck) ![star](/img/star.png) 382 ![fork](/img/fork.png) 103 Updated: Wed Apr 10 2024 [ glue ](https://hapi.dev/family/glue) ![](/img/family.svg) Server composer [![github logo](/img/githubLogo.png)](https://github.com/hapijs/glue) ![star](/img/star.png) 245 ![fork](/img/fork.png) 62 Updated: Wed Oct 23 2024 [ h2o2 ](https://hapi.dev/family/h2o2) ![](/img/family.svg) Proxy handler [![github logo](/img/githubLogo.png)](https://github.com/hapijs/h2o2) ![star](/img/star.png) 164 ![fork](/img/fork.png) 63 Updated: Wed Oct 23 2024 [ hapi-graceful-pm2 ](https://github.com/roylines/hapi-graceful-pm2) Handle true zero downtime reloads when issuing a pm2 gracefulReload command [![github logo](/img/githubLogo.png)](https://github.com/roylines/hapi-graceful-pm2) [ podium-hapi-layout ](https://github.com/podium-lib/hapi-layout) Hapi plugin for writing Micro Frontend Layout servers with Podium - https://podium-lib.io [![github logo](/img/githubLogo.png)](https://github.com/podium-lib/hapi-layout) [ podium-hapi-podlet ](https://github.com/podium-lib/hapi-podlet) Hapi plugin for writing Micro Frontend Fragment servers with Podium - https://podium-lib.io [![github logo](/img/githubLogo.png)](https://github.com/podium-lib/hapi-podlet) [ qs ](https://github.com/hapijs/qs) ![](/img/family.svg) A querystring parser with support for arrays and objects [![github logo](/img/githubLogo.png)](https://github.com/hapijs/qs) [ tarm ](https://github.com/kanongil/tarm) Add tarmount handler for serving tar file contents [![github logo](/img/githubLogo.png)](https://github.com/kanongil/tarm) [ hapi-orientdb ](https://github.com/petervavro/hapi-orientdb) OrientDB plugin for hapijs. [![github logo](/img/githubLogo.png)](https://github.com/petervavro/hapi-orientdb) ## Validation [ blaine ](https://github.com/ruiquelhas/blaine) Server-level file signature validation for raw request payloads in memory [![github logo](/img/githubLogo.png)](https://github.com/ruiquelhas/blaine) [ burton ](https://github.com/ruiquelhas/burton) Server-level file signature validation for raw stream request payloads [![github logo](/img/githubLogo.png)](https://github.com/ruiquelhas/burton) [ copperfield ](https://github.com/ruiquelhas/copperfield) Server-level file signature validation for parsed request payloads in memory [![github logo](/img/githubLogo.png)](https://github.com/ruiquelhas/copperfield) [ coutts ](https://github.com/ruiquelhas/coutts) Server-level file signature validation for raw temporary file request payloads [![github logo](/img/githubLogo.png)](https://github.com/ruiquelhas/coutts) [ fischbacher ](https://github.com/ruiquelhas/fischbacher) Server-level file signature validation for parsed temporary file request payloads [![github logo](/img/githubLogo.png)](https://github.com/ruiquelhas/fischbacher) [ hapi-plugin-ducky ](https://github.com/rse/hapi-plugin-ducky) Validating payloads with the DuckyJS JSON validation language [![github logo](/img/githubLogo.png)](https://github.com/rse/hapi-plugin-ducky) [ henning ](https://github.com/ruiquelhas/henning) Server-level file signature validation for parsed request payload file streams [![github logo](/img/githubLogo.png)](https://github.com/ruiquelhas/henning) [ houdin ](https://github.com/ruiquelhas/houdin) Route-level file signature validation for request payloads in memory [![github logo](/img/githubLogo.png)](https://github.com/ruiquelhas/houdin) [ joi ](https://joi.dev) Object schema description language and validator for JavaScript objects [![github logo](/img/githubLogo.png)](https://joi.dev) [ lafayette ](https://github.com/ruiquelhas/lafayette) Route-level file signature validation for temporary file request payloads [![github logo](/img/githubLogo.png)](https://github.com/ruiquelhas/lafayette) [ supervizor ](https://github.com/ruiquelhas/supervizor) Server-level request payload validation [![github logo](/img/githubLogo.png)](https://github.com/ruiquelhas/supervizor) [ thurston ](https://github.com/ruiquelhas/thurston) Route-level file signature validation for request payload file streams [![github logo](/img/githubLogo.png)](https://github.com/ruiquelhas/thurston) ## hapi pal [ ahem ](https://hapipal.com/docs/ahem) hapi plugins as libraries [![github logo](/img/githubLogo.png)](https://github.com/hapipal/ahem) [ avocat ](https://hapipal.com/docs/avocat) Convert objection DB errors to boom HTTP errors [![github logo](/img/githubLogo.png)](https://github.com/hapipal/avocat) [ boilerplate ](https://hapipal.com/docs/boilerplate) A friendly, proven starting place for your next hapi plugin or deployment [![github logo](/img/githubLogo.png)](https://github.com/hapipal/boilerplate) [ confidence ](https://github.com/hapipal/confidence) A configuration document format, an API, and a foundation for A/B testing [![github logo](/img/githubLogo.png)](https://github.com/hapipal/confidence) [ haute-couture ](https://hapipal.com/docs/haute-couture) File-based hapi plugin composer [![github logo](/img/githubLogo.png)](https://github.com/hapipal/haute-couture) [ hecks ](https://hapipal.com/docs/hecks) Mount your express app onto your hapi server, aw heck! [![github logo](/img/githubLogo.png)](https://github.com/hapipal/hecks) [ hodgepodge ](https://hapipal.com/docs/hodgepodge) A plugin dependency resolver [![github logo](/img/githubLogo.png)](https://github.com/hapipal/hodgepodge) [ hpal ](https://hapipal.com/docs/hpal) The hapi pal CLI, for searching hapi docs, scaffolding projects, and running custom server commands [![github logo](/img/githubLogo.png)](https://github.com/hapipal/hpal) [ hpal-debug ](https://hapipal.com/docs/hpal-debug) hapijs debugging tools for the hapi pal CLI [![github logo](/img/githubLogo.png)](https://github.com/hapipal/hpal-debug) [ lalalambda ](https://hapipal.com/docs/lalalambda) Serverless functions powered by hapijs [![github logo](/img/githubLogo.png)](https://github.com/hapipal/lalalambda) [ schmervice ](https://hapipal.com/docs/schmervice) A service layer for hapi [![github logo](/img/githubLogo.png)](https://github.com/hapipal/schmervice) [ schwifty ](https://hapipal.com/docs/schwifty) A model layer for hapi integrating Objection ORM [![github logo](/img/githubLogo.png)](https://github.com/hapipal/schwifty) [ tandy ](https://hapipal.com/docs/tandy) Auto-generated, RESTful, CRUDdy route handlers for Objection models [![github logo](/img/githubLogo.png)](https://github.com/hapipal/tandy) [ toys ](https://hapipal.com/docs/toys) The hapi utility toy chest [![github logo](/img/githubLogo.png)](https://github.com/hapipal/toys) [ underdog ](https://hapipal.com/docs/underdog) HTTP/2 server-push for hapi [![github logo](/img/githubLogo.png)](https://github.com/hapipal/underdog) --- # hapi Documentation # Source: https://hapi.dev/tutorials/auth/?lang=en_US Tutorials Languages: en-US pt-BR ko-KR tr-TR zh-CN * [Getting Started](/tutorials/gettingstarted/?lang=en_US) * * * * [Express Migration](/tutorials/expresstohapi/?lang=en_US) * * * * [Authentication](/tutorials/auth/?lang=en_US) * * * * [Caching](/tutorials/caching/?lang=en_US) * * * * [Cookies](/tutorials/cookies/?lang=en_US) * * * * [Logging](/tutorials/logging/?lang=en_US) * * * * [Plugins](/tutorials/plugins/?lang=en_US) * * * * [Routing](/tutorials/routing/?lang=en_US) * * * * [Server Methods](/tutorials/servermethods/?lang=en_US) * * * * [Serving Static Files](/tutorials/servingfiles/?lang=en_US) * * * * [Testing](/tutorials/testing/?lang=en_US) * * * * [Validation](/tutorials/validation/?lang=en_US) * * * * [Views](/tutorials/views/?lang=en_US) * * * * [Community Tutorials](/tutorials/community/?lang=en_US) # Authentication _This tutorial is compatible with hapi v17 and newer_ ## Overview Most modern web apps use some form of authentication. Authentication within hapi is based on the concept of `schemes` and `strategies`. `Schemes` are a way of handling authentication within hapi. For example, the `@hapi/basic` and `@hapi/cookie` plugins would be considered `schemes`. A `strategy` is a pre-configured instance of a `scheme`. You use `strategies` to implement authentication `schemes` into your application. ## Schemes A `scheme` is a method with the signature `function (server, options)`. The `server` parameter is a reference to the server the scheme is being added to, while the `options` parameter is the configuration object provided when registering a strategy that uses this scheme. This method must return an object with _at least_ the key `authenticate`. Other optional methods that can be used are `payload` and `response`. You can either write your own authentication `scheme`, or use one of the many hapi auth plugins, such as `@hapi/basic` or `@hapi/cookie`. ### authenticate The `authenticate` method has a signature of `function (request, h)`, and is the only _required_ method in a scheme. In this context, `request` is the `request` object created by the server. It is the same object that becomes available in a route handler, and is documented in the [API reference](/api#request). `h` is the standard hapi [response toolkit](/api#response-toolkit). When authentication is successful, you must call and return `h.authenticated({ credentials, artifacts })`. `credentials` property is an object representing the authenticated user (or the credentials the user attempted to authenticate with). Additionally, you may also have an `artifacts` key, which can contain any authentication related data that is not part of the user's credentials. The `credentials` and `artifacts` properties can be accessed later (in a route handler, for example) as part of the `request.auth` object. If authentication is unsuccessful, you can either throw an error or call and return `h.unauthenticated(error, [data])` where `error` is an authentication error and `data` is an optional object containing `credentials` and `artifacts`. There's no difference between calling `return h.unauthenticated(error)` or throwing an error if no `data` object is provided. The specifics of the error passed will affect the behavior. More information can be found in the API documentation for [`server.auth.scheme(name, scheme)`](/api#server.auth.scheme\(\)). It is recommend to use [boom](/module/boom) for errors. ### payload The `payload` method has the signature `function (request, h)`. Again, the standard hapi response toolkit is available here. To signal a failure throw an error, again it's recommended to use [boom](/module/boom) for errors. To signal a successful authentication, return `h.continue`. ### response The `response` method also has the signature `function (request, h)` and utilizes the standard response toolkit. This method is intended to decorate the response object (`request.response`) with additional headers, before the response is sent to the user. Once any decoration is complete, you must return `h.continue`, and the response will be sent. If an error occurs, you should instead throw an error where the error is recommended to be a [boom](/module/boom). ## Strategies Once you've registered your scheme, you need a way to use it. This is where strategies come in. As mentioned above, a strategy is essentially a pre-configured instance of a scheme. To register a strategy, you must first have a scheme registered. Once that's complete, use `server.auth.strategy(name, scheme, [options])` to register your strategy. The `name` parameter must be a string, and will be used later to identify this specific strategy. `scheme` is also a string, and is the scheme's name this strategy is to be an instance of. The `options` parameter is used to customize the `strategy`'s options. server.auth.strategy('session', 'cookie', { name: 'sid-example', password: '!wsYhFA*C2U6nz=Bu^%A@^F#SF3&kSR6', isSecure: false }); In the above example, you register the `strategy` with `server.auth.strategy()`. You name the `strategy` `session`, and say that you are using the `cookie` scheme. Lastly, you configure the `strategy` by giving it a `name`, `password`, and setting `isSecure: false`. ## Default Strategy You may set a default strategy by using `server.auth.default()`. This method accepts one parameter, which may be either a string with the name of the strategy to be used as default, or an object in the same format as the route handler's [auth options](#route-configuration). Note that all routes will have the default applied to them, even the ones added _before_ `server.auth.default()` is called. ## Route Configuration Authentication can also be configured on a route, by the `options.auth` parameter. If set to `false`, authentication is disabled for the route. It may also be set to a string with the name of the strategy to use, or an object with `mode`, `strategies`, and `payload` parameters. The `mode` parameter may be set to `'required'`, `'optional'`, or `'try'` and works the same as when registering a strategy. If set to `'required'`, in order to access the route, the user must be authenticated, and their authentication must be valid, otherwise they will receive an error. If `mode` is set to `'optional'` the strategy will still be applied to the route but in this case the user does _not_ need to be authenticated. Authentication data is optional, but must be valid if provided. The last `mode` setting is `'try'`. The difference between `'try'` and `'optional'` is that with `'try'` invalid authentication is accepted, and the user will still reach the route handler. When specifying one strategy, you may set the `strategy` property to a string with the name of the strategy. When specifying more than one strategy, the parameter name must be `strategies` and should be an array of strings each naming a strategy to try. The strategies will then be attempted in order until one succeeds, or they have all failed. Lastly, the `payload` parameter can be set to `false` denoting the payload is not to be authenticated, `'required'` or `true` meaning that it _must_ be authenticated, or `'optional'` meaning that if the client includes payload authentication information, the authentication must be valid. Is only possible to use the `payload` parameter, with a strategy that supports the `payload` method in its scheme. ## basic The first `scheme` we will look at is the [@hapi/basic](/module/basic) plugin. Just like the name says, the `@hapi/basic` plugin uses basic authentication to validate users. Here is an example of setting up `@hapi/basic`: 'use strict'; const Bcrypt = require('bcrypt'); const Hapi = require('@hapi/hapi'); const users = { john: { username: 'john', password: '$2a$10$iqJSHD.BGr0E2IxQwYgJmeP3NvhPrXAeLSaGCj6IR/XU5QtjVu5Tm', // 'secret' name: 'John Doe', id: '2133d32a' } }; const validate = async (request, username, password) => { const user = users[username]; if (!user) { return { credentials: null, isValid: false }; } const isValid = await Bcrypt.compare(password, user.password); const credentials = { id: user.id, name: user.name }; return { isValid, credentials }; }; const start = async () => { const server = Hapi.server({ port: 4000 }); await server.register(require('@hapi/basic')); server.auth.strategy('simple', 'basic', { validate }); server.route({ method: 'GET', path: '/', options: { auth: 'simple' }, handler: function (request, h) { return 'welcome'; } }); await server.start(); console.log('server running at: ' + server.info.uri); }; start(); First, you define your `users` database, which is a simple object in this example. Then you define a validation function, which is a feature specific to [@hapi/basic](/module/basic) and allows you to verify that the user has provided valid credentials. For this validation function, you use `Bcrypt` to compare the user provided password with the hashed password in your database. Next, you register the plugin, which creates a scheme with the name of `basic`. This is done within the plugin via [server.auth.scheme()](/api#-serverauthschemename-scheme). Once the plugin has been registered, you use [server.auth.strategy()](/api#server.auth.strategy\(\)) to create a strategy with the name of `simple` that refers to your scheme named `basic`. You also pass an options object that gets passed to the scheme and allows you to configure its behavior. The last thing you do is tell a route to use the strategy named `simple` for authentication. ## cookie [@hapi/cookie](/module/cookie) is a plugin that will store a cookie in the users browser once they are authenticated. This has the option of keeping the user logged in, even after they leave the site. Here is an example of setting up `@hapi/cookie`: In this example, the home route, "/", is restricted and can only be accessed once a user has authenticated themselves: 'use strict'; const Bcrypt = require('bcrypt'); const Hapi = require('@hapi/hapi'); const users = [ { username: 'john', password: '$2a$10$iqJSHD.BGr0E2IxQwYgJmeP3NvhPrXAeLSaGCj6IR/XU5QtjVu5Tm', // 'secret' name: 'John Doe', id: '2133d32a' } ]; const start = async () => { const server = Hapi.server({ port: 4000 }); await server.register(require('@hapi/cookie')); server.auth.strategy('session', 'cookie', { cookie: { name: 'sid-example', password: '!wsYhFA*C2U6nz=Bu^%A@^F#SF3&kSR6', isSecure: false }, redirectTo: '/login', validate: async (request, session) => { const account = await users.find( (user) => (user.id === session.id) ); if (!account) { return { isValid: false }; } return { isValid: true, credentials: account }; } }); server.auth.default('session'); server.route([ { method: 'GET', path: '/', handler: function (request, h) { return 'Welcome to the restricted home page!'; } }, { method: 'GET', path: '/login', handler: function (request, h) { return ` Login page

Please Log In

Username:
Password:
`; }, options: { auth: false } }, { method: 'POST', path: '/login', handler: async (request, h) => { const { username, password } = request.payload; const account = users.find( (user) => user.username === username ); if (!account || !(await Bcrypt.compare(password, account.password))) { return h.redirect('/login'); } request.cookieAuth.set({ id: account.id }); return h.redirect('/'); }, options: { auth: { mode: 'try' } } } ]); await server.start(); console.log('server running at: ' + server.info.uri); }; start(); First, you need to do is register the `@hapi/cookie` plugin with `server.register`. Once the plugin is registered, you configure your `strategy` by calling `server.auth.strategy`. `server.auth.strategy` takes three parameters: name of the strategy, what scheme you are using, and an options object. For your strategy, you name it `session`. For the scheme, you will be using the `cookie` scheme. If you were using `@hapi/basic`, this parameter would be `basic`. The last parameter is an options object. This is how you can customize your auth strategy to fit your needs. The first property you configure is the `cookie` object. In your `strategy`, you will configure three properties of the `cookie` object. First, you set the name of the cookie, in this case `sid-example`. Next, you set the password that will be used to encrypt the cookie. This should be at least 32 characters long. Last, you set `isSecure` to `false`. This is ok for development while working over HTTP. In production, this should be switched back to `true`, which is the default setting. The next property is `redirectTo`. This will tell the server where to redirect to if an unauthenticated user tries to access a resource that requires authentication. The last property is the `validate` function, which validates that a current cookie is still valid. For example, if a user authenticates themselves successfully, receives a cookie, and then leaves the site. Once they return, the `validate` function will check if their current cookie is still valid. You setup the default strategy by calling `server.auth.default('session')`. This will set the default auth strategy for all routes. Once your strategy is set up, you need to set up route that will validate the provided username and password. In this case, your `POST` route to `'/login'` will do just that. First, it will pull the `username` and `password` from `request.payload`, which the user provided in the form from the `'/login'` `'GET'` route. Next, you find the user from the database by searching for their username: const account = users.find( (user) => user.username === username ); If the user doesn't exist, or if the provided password is wrong, you redirect the user back to the login page. You use `Bcrypt` to compare the user provided password with the hashed password from the database. Lastly, if the user does exist, and the password matches, the user is then redirected to the homepage. For more info on additional hapi auth plugins, please see the [plugin section](/plugins). ![clipboard](/img/clipboardCheck.png) --- # hapi Documentation # Source: https://hapi.dev/tutorials/caching/?lang=en_US Tutorials Languages: en-US pt-BR ko-KR tr-TR zh-CN * [Getting Started](/tutorials/gettingstarted/?lang=en_US) * * * * [Express Migration](/tutorials/expresstohapi/?lang=en_US) * * * * [Authentication](/tutorials/auth/?lang=en_US) * * * * [Caching](/tutorials/caching/?lang=en_US) * * * * [Cookies](/tutorials/cookies/?lang=en_US) * * * * [Logging](/tutorials/logging/?lang=en_US) * * * * [Plugins](/tutorials/plugins/?lang=en_US) * * * * [Routing](/tutorials/routing/?lang=en_US) * * * * [Server Methods](/tutorials/servermethods/?lang=en_US) * * * * [Serving Static Files](/tutorials/servingfiles/?lang=en_US) * * * * [Testing](/tutorials/testing/?lang=en_US) * * * * [Validation](/tutorials/validation/?lang=en_US) * * * * [Views](/tutorials/views/?lang=en_US) * * * * [Community Tutorials](/tutorials/community/?lang=en_US) # Caching _This tutorial is compatible with hapi v17 and newer_ ## Overview One of the best ways to improve website performance is to configure caching on your server. hapi makes it easy to configure both client-side and server-side caching. ## Client-side Caching The HTTP protocol defines several HTTP headers to instruct how clients, such as browsers, should cache resources. To learn more about these headers and to decide which are suitable for your use-case check out this useful [guide put together by Google](https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching). The first part of this tutorial shows how to easily configure hapi to send these headers to clients. ### Cache-Control The `Cache-Control` header tells the browser and any intermediate caches if a resource is cacheable and for what duration. For example, `Cache-Control:max-age=30, must-revalidate, private` means that the browser can cache the associated resource for thirty seconds and `private` means it should not be cached by intermediate caches, only by the browser. `must-revalidate` means that once it expires it has to request the resource again from the server. Let's see how you can set this header in hapi: server.route({ path: '/hapi/{ttl?}', method: 'GET', handler: function (request, h) { const response = h.response({ be: 'hapi' }); if (request.params.ttl) { response.ttl(request.params.ttl); } return response; }, options: { cache: { expiresIn: 30 * 1000, privacy: 'private' } } }); The above example shows how you can set a `cache` options object on a route. Here you set `expiresIn` to 30 seconds and `privacy` to private. The example also illustrates that the `expiresIn` value can be overridden with the `ttl(msec)` method provided by the [response object](/api#response-object) interface. If you make a request to `/hapi` you'll receive the response header `cache-control: max-age=30, must-revalidate, private`. If you make a request to `/hapi/5000` you'll instead get the header `cache-control: max-age=5, must-revalidate, private`. See [route-options](/api#route-options) for more information about common `cache` configuration options. ### Last-Modified In some cases, the server can provide information about when a resource was last modified. When using the [inert](/module/inert) plugin for serving static content, a `Last-Modified` header is added automatically to every response. When the `Last-Modified` header is set on a response, hapi compares it with the `If-Modified-Since` header coming from the client to decide if the response status code should be `304 Not Modified`. This is also known as a conditional GET request. The advantage being that there's no need for the browser to download the file again for a `304` response. Assuming `lastModified` is a `Date` object you can set this header via the [response object](/api#response-object) as seen here: return h.response(result) .header('Last-Modified', lastModified.toUTCString()); There is one more example using `Last-Modified` in the [last section](#clientandserver) of this tutorial. ### ETag The ETag header is an alternative to `Last-Modified` where the server provides a token (usually a checksum of the resource) instead of a last modified timestamp. The browser will use this token to set the `If-None-Match` header in the next request. The server compares this header value with the new `ETag` checksum and responds with `304` if they are the same. You only need to set `ETag` in your handler via `etag(tag, options)` function: return h.response(result).etag('xxxxxxxxx'); Check the documentation of `etag` under the [response object](/api#response-object) for more details about the arguments and available options. ## Server-side Caching hapi provides powerful, convenient server-side caching via [catbox](/module/catbox). This tutorial section will help you understand how to use catbox. ### catbox [catbox](/module/catbox) is a multi-strategy key-value object store. It comes with extensions supporting a memory cache, [Redis](https://redis.io), and [Memcached](http://memcached.org). In order to reduce module dependencies, catbox does not include the external caching strategies. To use other strategies, each service must be manually installed via npm or package dependencies manually. catbox has two interfaces; client and policy. ### Client [Client](/module/catbox/api#client) is a low-level interface that allows you set/get key-value pairs. It is initialized with one of the available adapters: ([Memory](/module/catbox-memory), [Redis](/module/catbox-redis), or [Memcached](/module/catbox-memcached). hapi initializes a default [client](/module/catbox#client) using the [catbox memory](/module/catbox-memory) adapter. Let's see how you can define another client using the [redis](http://redis.io/) strategy. 'use strict'; const Hapi = require('@hapi/hapi'); const CatboxRedis = require('@hapi/catbox-redis'); const server = Hapi.server({ port: 8000, cache: [ { name: 'my_cache', provider: { constructor: CatboxRedis, options: { partition : 'my_cached_data', host: 'redis-cluster.domain.com', port: 6379, database: 0, tls: {} } } } ] }); In the above example, you defined a new catbox client, `my_cache`. Including the default memory cache created by hapi, there are now two available cache clients. You can replace the default client by omitting the `name` property when registering a new cache client. `partition` tells the adapter how cache should be named ('catbox' by default). In the case of [redis](http://redis.io/) it is used as key prefix. ### Policy [Policy](/module/catbox/api#policy) is a more high-level interface than Client. The following is a simple example of caching the result of adding two numbers together. The principles of this simple example can be applied to any situation where you want to cache the result of a function call, async or otherwise. [server.cache(options)](/api#server.cache\(\)) creates a new [policy](/module/catbox/api#policy), which is then used in the route handler. const start = async () => { const server = Hapi.server(); const add = async (a, b) => { await Hoek.wait(1000); // Simulate some slow I/O return Number(a) + Number(b); }; const sumCache = server.cache({ cache: 'my_cache', expiresIn: 10 * 1000, segment: 'customSegment', generateFunc: async (id) => { return await add(id.a, id.b); }, generateTimeout: 2000 }); server.route({ path: '/add/{a}/{b}', method: 'GET', handler: async function (request, h) { const { a, b } = request.params; const id = `${a}:${b}`; return await sumCache.get({ id, a, b }); } }); await server.start(); console.log('Server running at:', server.info.uri); }; start(); If you make a request to `http://localhost:8000/add/1/5`, you should get the response `6` after about a second. If you hit that endpoint again the response should come immediately because it's being served from the cache. If you were to wait 10s and then call it again, you'd see that it took a while because the cached value has now been ejected from the cache. `server.cache(options)` provisions a cache segment within the server cache facility. In this case, your policy will be using `'my_cache'` which you created above with `server.cache`. `expiresIn` states the time, in milliseconds, the cache will expire in relation to the time the item was saved in the cache. In this case, our cache will expire 10 seconds after the item was saved. `segment` that allow you to further isolate caches within one [client](/module/catbox/api#client) partition. If you want to cache results from two different methods, you usually don't want to mix the results together. In [redis](http://redis.io/), `segment` is an additional prefix along with the `partition` option. The default value for `segment` when [server.cache()](/api#-servercacheoptions) is called inside of a plugin will be `'!pluginName'`. When creating [server methods](/tutorials/servermethods), the `segment` value will be `'#methodName'`. If you have a use case for multiple policies sharing one segment there is a [shared](/api#-servercacheoptions) option available as well. `generateFunc` is a function that will generate a new cache item if one is not found in the cache when calling `get()`. In this example, the generate function will generate a value of two numbers add together. The `generateFunc` function will also be called if an item in the cache exists, but is found to be stale. You can set the time when an item in the cache will be stale by configuring the `staleIn` option. `staleIn` is a number in milliseconds to mark an item stored in cache as stale and attempt to regenerate it when `generateFunc` is provided. `staleIn` must be less than `expiredIn`. `generateTimeout` is the number of milliseconds to wait before returning a timeout error when the `generateFunc` function takes too long to return a value. `get(id)` is used to retrieve an item from the cache. If the item is not found, and the `generateFunc` method was provided, a new value is generated, stored in the cache, and is returned. The first parameter of the `sumCache.get()` function is an id, which may either be a string or an object with a mandatory property `id`, which is a unique cache item identifier. Look into catbox policy [options](/module/catbox/api#policy) and pay extra attention to `staleIn`, `staleTimeout`, `generateTimeout`, to leverage the full potential of catbox caching. ### Server methods But it can get better than that! In 95% cases you will use server methods for caching purposes, because it reduces boilerplate to minimum. Here's a rewrite of the previous example using a server method: const start = async () => { const server = Hapi.server(); server.method('sum', add, { cache: { cache: 'my_cache', expiresIn: 10 * 1000, generateTimeout: 2000 } }); server.route({ path: '/add/{a}/{b}', method: 'GET', handler: async function (request, h) { const { a, b } = request.params; return await server.methods.sum(a, b); } }); await server.start(); }; start(); [server.method()](/api#server.method\(\)) created a new [policy](/module/catbox/api#policy) with `segment: '#sum'` automatically for us. Also the unique item `id` (cache key) was automatically generated from parameters. By default, it handles `string`, `number` and `boolean` parameters. For more complex parameters, you have to provide your own `generateKey` function to create unique ids based on the parameters - check out the server methods tutorial for more information. ## Client and Server caching Optionally, [Catbox Policy](/module/catbox/api#policy) can provide more information about the value retrieved from the cache. To enable this set the `getDecoratedValue` option to `true` when creating the policy. Any value returned from the server method will then be an object `{ value, cached, report }`. `value` is just the item from the cache, `cached` and `report` provides some extra details about the cache state of the item. An example of server-side and client-side caching working together is using the `cached.stored` timestamp to set the `last-modified` header: const start = async () => { const server = Hapi.server(); server.method('sum', add, { cache: { cache: 'my_cache', expiresIn: 10 * 1000, generateTimeout: 2000, getDecoratedValue: true } }); server.route({ path: '/add/{a}/{b}', method: 'GET', handler: async function (request, h) { const { a, b } = request.params; const { value, cached } = await server.methods.sum(a, b); const lastModified = cached ? new Date(cached.stored) : new Date(); return h.response(value) .header('Last-modified', lastModified.toUTCString()); } }); await server.start(); }; You can find more details about `cached` and `report` in the [Catbox Policy API docs](/module/catbox/api#api-1). ![clipboard](/img/clipboardCheck.png) --- # hapi Documentation # Source: https://hapi.dev/tutorials/cookies/?lang=en_US Tutorials Languages: en-US pt-BR ko-KR tr-TR zh-CN * [Getting Started](/tutorials/gettingstarted/?lang=en_US) * * * * [Express Migration](/tutorials/expresstohapi/?lang=en_US) * * * * [Authentication](/tutorials/auth/?lang=en_US) * * * * [Caching](/tutorials/caching/?lang=en_US) * * * * [Cookies](/tutorials/cookies/?lang=en_US) * * * * [Logging](/tutorials/logging/?lang=en_US) * * * * [Plugins](/tutorials/plugins/?lang=en_US) * * * * [Routing](/tutorials/routing/?lang=en_US) * * * * [Server Methods](/tutorials/servermethods/?lang=en_US) * * * * [Serving Static Files](/tutorials/servingfiles/?lang=en_US) * * * * [Testing](/tutorials/testing/?lang=en_US) * * * * [Validation](/tutorials/validation/?lang=en_US) * * * * [Views](/tutorials/views/?lang=en_US) * * * * [Community Tutorials](/tutorials/community/?lang=en_US) # Cookies _This tutorial is compatible with hapi v17 and newer_ ## Overview When writing a web application, cookies are often used to keep state about a user between requests. With hapi, cookies are flexible, secure, and simple to use. ## Configuring the server hapi has several configurable options when dealing with cookies. The defaults are probably good for most cases, but can be changed when needed. To prepare a cookie, you first need to name it and configure a list of options. You do this by calling `server.state(name, [options])`. ### server.state() To use a cookie, you first need to configure it by calling [`server.state(name, [options])`](/api#server.state\(\)) where `name` is the name of the cookie, and `options` is an object used to configure the cookie. Please note that the default settings for `options` is good for most cases and don't need to be configured. For learning purposes, you will configure them in this tutorial: server.state('data', { ttl: null, isSecure: true, isHttpOnly: true, encoding: 'base64json', clearInvalid: true, strictHeader: true }); In the example above, you first name the cookie `data`. You then configure the options to customize the cookie. The first option is `ttl`. This represents the cookies time to live in milliseconds. The default setting is `null`, which will delete the cookie once the browser is closed. Next we have two flags, `isSecure` and `isHttpOnly`. For more info on these flags, see ([RFC 6265](http://tools.ietf.org/html/rfc6265), specifically sections [4.1.2.5](http://tools.ietf.org/html/rfc6265#section-4.1.2.5) and [4.1.2.6](http://tools.ietf.org/html/rfc6265#section-4.1.2.6). You then tell hapi that the value is a base64 encoded JSON string. By setting `clearInvalid` to `true`, it instructs the client to remove invalid cookies. Last, you set `strictHeader` to `true` so that there are no violations of [RFC 6265](https://tools.ietf.org/html/rfc6265). ### route.options.state() In addition to this, you can further configure cookie behavior at a route-level by specifying two properties at the route's `options.state` object. Please note that configurations to cookies on the route-level are in addition to those configurations made by `server.state`. { options: { state: { parse: true, failAction: 'error' } } } The `parse` option determines if cookies are parsed and stored in `request.state`. The `failAction` options determines how cookie parsing errors will be handled. ## Setting a cookie Setting a cookie is done via the [response toolkit](/api#response-toolkit) in a request handler, pre-requisite, or request lifecycle extension point. ### h.state() You set a cookie by calling [`h.state(name, value, [options]`](/api#h.state\(\)). In the following example, you set a cookie in a route handler: server.route({ method: 'GET', path: '/', handler: function (request, h) { h.state('data', { firstVisit: false }); return h.response('Hello'); } }); In this example, you use the cookie we configured in the section above. Here, hapi will reply with the string `Hello` as well as set a cookie named `data` to a base64 encoded JSON string representation of `{ firstVisit: false }`. The `state()` method is also available on the [response object](/api#response-object) which allows for convenient chaining. The above example can therefore also be written: return h.response('Hello').state('data', { firstVisit: false }); ## Overriding options When setting a cookie, you may also pass the same options available to `server.state()` as a third parameter, such as: return h.response('Hello').state('data', 'test', { encoding: 'none' }); In this example the cookie will simply be set to the string `"test"` with no encoding. ## Getting a cookie value Access a cookie’s value via `request.state` in a route handler, pre-requisite, or request lifecycle extension point. The `request.state` object contains the parsed HTTP state. Each key represents the cookie name and its value is the defined content. If multiple cookies with the same name are present on the request, the values are exposed as an array rather than a single value. The sample code uses the `data` cookie key from above where the related value is set to `{ firstVisit: false }`: const value = request.state.data; // console.log(value) will give you { firstVisit : false } ## Clearing a cookie The cookie can be cleared by calling the `unstate()` method on the [response toolkit](/api#response-toolkit) or [response object](/api#response-object): return h.response('Bye').unstate('data'); Here, you just pass the name of the cookie into `unstate()` to clear the cookie. ![clipboard](/img/clipboardCheck.png) --- # hapi Documentation # Source: https://hapi.dev/tutorials/expresstohapi/?lang=en_US Tutorials Languages: en-US pt-BR ko-KR tr-TR zh-CN * [Getting Started](/tutorials/gettingstarted/?lang=en_US) * * * * [Express Migration](/tutorials/expresstohapi/?lang=en_US) * * * * [Authentication](/tutorials/auth/?lang=en_US) * * * * [Caching](/tutorials/caching/?lang=en_US) * * * * [Cookies](/tutorials/cookies/?lang=en_US) * * * * [Logging](/tutorials/logging/?lang=en_US) * * * * [Plugins](/tutorials/plugins/?lang=en_US) * * * * [Routing](/tutorials/routing/?lang=en_US) * * * * [Server Methods](/tutorials/servermethods/?lang=en_US) * * * * [Serving Static Files](/tutorials/servingfiles/?lang=en_US) * * * * [Testing](/tutorials/testing/?lang=en_US) * * * * [Validation](/tutorials/validation/?lang=en_US) * * * * [Views](/tutorials/views/?lang=en_US) * * * * [Community Tutorials](/tutorials/community/?lang=en_US) # Express Migration _This guide is compatible with hapi v17 and newer_ ## Overview This Express to hapi guide will show you how to take what you know how to do in Express, and do it in hapi. While Express relies heavily on middleware for much of its functionality, hapi has more built into the core. Body parsing, cookie handling, input/output validation, and HTTP-friendly error objects are already built-in to the hapi framework. For additional functionality, hapi has a robust selection of plugins in its core ecosystem. hapi is also the only framework that doesn't rely on outside dependencies. Every dependency is managed by the core hapi team, which makes security and reliability some of hapi's greatest strengths. ## Setup ### Installation Express: `npm install express` hapi: `npm install @hapi/hapi` ### Creating a Server Express: var express = require('express'); var app = express(); app.listen(3000, function () { console.log('Server is running on port 3000'); })); hapi: const Hapi = require('@hapi/hapi'); const init = async () => { const server = Hapi.server({ port: 3000, host: 'localhost' }); await server.start(); console.log('Server running on port 3000'); }; init(); Unlike Express, in hapi you create a server object that will be the focal point of your application. The properties set in the server object will determine how your application behaves. Once you create your server object, you can start your server by calling `server.start()`. ## Routes Routes in hapi get called in a specific order, so you will never have an issue where two routes are conflicting with one another. Routes are called from most specific to least specific. For example, a route with a path `'/home'` will be called before `'/{any*}'`. Lets look at how to set up a basic route in hapi: Express: app.get('/hello', function (req, res) { res.send('Hello World!'); }); hapi: server.route({ method: 'GET', path:'/hello', handler: (request, h) => { return 'Hello World!'; } }); To create a route, Express has the structure of `app.METHOD(PATH, HANDLER)` and hapi has the structure `server.route({METHOD, PATH, HANDLER})`. The method, path, and handler are passed to the hapi server as an object. As you can see, to return a string in Express, you call `res.send()`, whereas in hapi, you simply return the string. ### Methods hapi can use all the route methods that Express can, except `HEAD`. hapi also has the ability to use multiple methods on a single route object. For example: server.route({ method: ['PUT', 'POST'], path: '/', handler: function (request, h) { return 'I did something!'; } }); To use all available methods, like in Express `app.all()`, use `method: '*'`. ### Path Like in Express, the path option in hapi must be a string, which can also contain parameters. Parameters in Express are preceded by `:`, such as: `'/users/:userId'`. In hapi, you would put the parameter in curly braces, like: `path: '/users/{userId}'`. ### Parameters You saw above how hapi handles simple parameters as compared to Express. Both hapi and Express handle optional parameters the same way. Just like Express, to make a parameter optional in hapi, just include a `?` after the parameter: `path: '/hello/{user?}`. Accessing the parameters in hapi is very similar to Express. As you know, in Express, the parameters are populated in the `req.params` object. In hapi, the parameters are available via the `request.params` object. Here is an example of both: Express: app.get('/hello/:name', function (req, res) { const name = req.params.name res.send('Hello ' + name); }); hapi: server.route({ method: 'GET', path: '/hello/{name}', handler: function (request, h) { const name = request.params.name; return 'Hello ' + name } }); Query parameters are also similar in both frameworks. In Express, they are available via `req.query` and hapi they are available via `request.query`. ### Handler There are differences in the way Express and hapi structure their route handlers. Unlike Express, which has a handler with parameters of `req` and `res`, hapi has a handler with parameters of `request` and `h`. The second parameter, `h` is the response toolkit, which is an object with several methods used to respond to the request. Here is an example of route with a handler that redirects to another route in Express and hapi: Express: app.get('/home', function (req, res) { res.redirect('/'); }); hapi: server.route({ method: 'GET', path: '/home', handler: function (request, h) { return h.redirect('/'); } }); Both routes will redirect to the `'/'` route. Express uses the response method `res.redirect` whereas hapi uses `h.redirect` which is part of the response toolkit. There are Express response methods that hapi can accomplish by just using `return`. Some of these methods include `res.send` and `res.json`. Here is an example of how hapi will respond with JSON data: server.route({ method: 'GET', path: '/user', handler: function (request, h) { const user = { firstName: 'John', lastName: 'Doe', userName: 'JohnDoe', id: 123 } return user; } }); hapi has the functionality to respond with JSON data by default. The only thing you have to do is just return a valid JavaScript object and hapi will take care of the rest for you. ## Middleware vs Plugins and Extensions To extend its functionality, Express uses middleware. Middleware essentially is a sequence of functions using callbacks to execute the next function. The issue with this is as your application grows in size and complexity, the order at which middleware executes becomes more crucial and more difficult to maintain. Having a middleware execute before one it is dependant on will cause your application to fail. hapi fixes this issue with its robust plugin and extension system. Plugins allow you to break your application logic into isolated pieces of business logic, and reusable utilities. Each plugin comes with its own dependencies which are explicitly specified in the plugins themselves. This means you don't have to install dependencies yourself to make your plugins work. You can either add an existing hapi plugin, or write your own. For a more extensive tutorial on plugins, please see the [plugins](/tutorials/plugins/?lang=en_US) tutorial. Each request in hapi follows a predefined path, the request lifecycle. hapi has extension points that let you create custom functionality along the lifecycle. Extension points in hapi let you know the precise order at which your application will run. For more info, please see the hapi [request lifecycle](/api/#request-lifecycle). ### Extension Points hapi has 7 extension points along the request lifecycle. In order, they are `onRequest`, `onPreAuth`, `onCredentials`, `onPostAuth`, `onPreHandler`, `onPostHandler`, and `onPreResponse`. To add a function to an extension point, you call `server.ext()`. Lets look at an example: server.ext('onRequest', function (request, h) { request.setUrl('/test'); return h.continue; }); This function will run at `onRequest`, which is the first extension point. `onRequest` is run just after the server receives the request object, before the route lookup. What this function will do is reroute all requests to the `'/test'` route. ### Creating a Plugin As you know, you can write your own middleware in Express. The same is true with hapi plugins. A plugin is an object with required `name` and `register` properties. The `register` property is a function with the signature of `async function (server, option)`. Lets look at how to create a basic plugin: Express: const getDate = function (req, res, next) { req.getDate = function() { const date = new Date(); return date; }; next(); }; hapi: const getDate = { name: 'getDate', version: '1.0.0', register: async function (server, options) { const currentDate = function() { const date = new Date(); return date; }; server.decorate('toolkit', 'getDate', currentDate); } }; The hapi plugin will save the current date in `h.getDate()`. We can then use this in any of our route handlers. ### Loading a Plugin In Express, you load middleware by calling the `app.use()` method. In hapi, you call the `server.register()` method. Lets load the plugin we created in the previous section: Express: app.use(getDate); hapi: await server.register({ plugin: getDate }); You can also provide options to your plugin by setting the `options` property on `server.register()`. ### Options You can add options to Express middleware by exporting a function that accepts an options parameter, which then returns the middleware. In hapi, you set the options when you register the plugin. Lets have a look: Express: module.exports = function (options) { return function getDate(req, res, next) { req.getDate = function() { const date = 'Hello ' + options.name + ', the date is ' + new Date(); return date; }; next() }; }; hapi: const getDate = { name: 'getDate', version: '1.0.0', register: async function (server, options) { const currentDate = function() { const date = 'Hello ' + options.name + ', the date is ' + new Date(); return date; }; server.decorate('toolkit', 'getDate', currentDate); } }; To get access to the options in hapi, you simply refer to the `options` object when you create the plugin: Express: const getDate = require('./mw/getDate.js'); app.use(getDate({ name: 'Tom' })); hapi: server.register({ plugin: getDate, options: { name: 'Tom' } }) ## body-parser hapi has parsing abilities built into its core. Unlike Express, you do not need middleware to parse payload data. In fact, you may need to install up to four additional middlewares in Express depending on what kind of data you would like to parse. In hapi the payload data, whether its JSON or plain text, is readily available in the `request.payload` object. Here is a side by side comparison of parsing simple payload data: Express: var bodyParser = require('body-parser'); app.use(bodyParser.urlencoded({extend: true})); app.post('/hello', function (req, res) { var name = req.body.name res.send('Hello ' + name); }); hapi: server.route({ method: 'POST', path: '/hello', handler: function (request, h) { const name = request.payload.name; return `Hello ` + name; } }); To parse a JSON object in express, you have to specify it: app.use(bodyParser.json()); JSON parsing is built into hapi, so there are no further steps needed. ## cookie-parser Setting and parsing cookies in Express require you to install the `cookie-parser` middleware. hapi has cookie functionality built right into the core, so there is no need to install additional middleware. To use cookies in hapi, you first configure the cookie with `server.state()`. Lets have a look: const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 8000 }); server.state('data', { ttl: null, isSecure: true, isHttpOnly: true }); ### Setting a Cookie Once the cookie is configured, you can now set the cookie with `h.state()`. Here is an example: Express: var express = require('express'); var app = express(); var cookieParser = require('cookie-parser'); app.use(cookieParser()); app.get('/', function(req, res) { res.cookie('username', 'tom', { maxAge: null, secure: true, httpOnly: true }); res.send('Hello'); }); hapi: const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 8000 }); server.state('username', { ttl: null, isSecure: true, isHttpOnly: true }); server.route({ method: 'GET', path: '/', handler: function (request, h) { h.state('username', 'tom'); return h.response('Hello'); } }); In express, you configure cookie with the `options` object in `res.cookie`. In hapi, the cookie config is saved to the server object with `server.state`. You then use `h.state()` to attach data to the cookie. ### Getting a Cookie Value To get a cookie value in hapi, you call `request.state`. Lets have look: Express: var express = require('express'); var app = express(); var cookieParser = require('cookie-parser); app.use(cookieParser()); app.get('/', (req, res) => { res.cookie('username', 'tom', { maxAge: null, secure: true, httpOnly: true }) res.send(req.cookies.username); }); hapi: const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 8000 }); server.state('username', { ttl: null, isSecure: true, isHttpOnly: true }); server.route({ method: 'GET', path: '/', handler: async (request, h) => { h.state('username', 'tom'); return h.response(request.state.username); } }); ## Passport -> bell In Express, third party authentication is handled with Passport. In hapi, you use the [bell](/module/bell) module for third party authentication. `bell` has over 30 predefined configurations for OAuth providers including Twitter, Facebook, Google, GitHub, and more. It will also allow you to set up your own custom provider. For a complete list, please see the [bell providers documentation](https://github.com/hapijs/bell/blob/master/Providers.md). `bell` was developed and is maintained by the core hapi team, so you know stability and reliability won't be an issue. Lets look how to authenticate using your Twitter credentials: Express: npm install passport passport-twitter var passport = require('passport'); var TwitterStrategy = require('passport-twitter').Strategy passport.use(new TwitterStrategy({ consumerKey: TWITTER_CONSUMER_KEY, consumerSecret: TWITTER_CONSUMER_SECRET, callbackURL: '/auth/twitter/callback' }, function(token, tokenSecret, profile, cb) { User.findOrCreate({ twitterId: profile.id }, function (err, user) { return cb(err, user); } } )); passport.seralizeUser(function(user, cb) { cb(null, user); }) passport.deserializeUser(function(user, cb) { cb(null, obj); }) app.get('/auth/twitter', passport.authenticate('twitter')); app.get('/auth/twitter/callback', passport.authenticate('twitter', { failureRedirect: '/login'}), function(req, res) { res.redirect('/'); }); hapi: npm install '@hapi/bell' const Hapi = require('@hapi/hapi'); const Bell = require('@hapi/bell'); const server = Hapi.server({ port: 8000 }); await server.register(Bell); server.auth.strategy('twitter', 'bell', { provider: 'twitter', password: 'cookie_encryption_password_secure', clientId: TWITTER_CONSUMER_KEY, clientSecret: TWITTER_CONSUMER_SECRET, isSecure: false }); server.route({ method: '*', path: '/auth/twitter', // The callback endpoint registered with the provider handler: function (request, h) { if (!request.auth.isAuthenticated) { return `Authentication failed due to: ${request.auth.error.message}`; } // Perform any account lookup or registration, setup local session, // and redirect to the application. The third-party credentials are // stored in request.auth.credentials. Any query parameters from // the initial request are passed back via request.auth.credentials.query. return h.redirect('/home'); }, options: { auth: { strategy: 'twitter', mode: 'try' } } }); To use bell, simply register the plugin and configure the strategy with `server.auth.strategy`. `provider` is the name of the third-party provider. `password` is the cookie encryption password. `clientId` is the OAuth client identifier, which is available from the provider. `clientSecret` is the OAuth client secret, which is available from the provider. `isSecure` sets the cookie secure flag. For production, this should be set to `true`, which is the default value. ## express-validator -> joi To validate data in Express, you make use of the `express-validator` plugin. One of the biggest drawbacks to `express-validator` is that while you can validate a request, there is no clear way of validating a response. In hapi, you use the [joi](https://joi.dev) module, which can validate requests and responses with ease. Joi allows you to create your own validations with a simple and clean object syntax. For a more in-depth look at validation in hapi, please see the [validation](/tutorials/validation/?lang=en_US) tutorial. ### Input Validation Input validation allows you to validate any input data coming into the server, whether its parameters, payload, etc. Here is a look at how to validate a blog post entry in Express and hapi: Express: npm install express-validator const bodyParser = require('body-parser'); const expressValidator = require('express-validator'); app.use(bodyParser.json()); app.use(bodyParser.urlencoded({ extended: true })); app.use(expressValidator()) app.post('/post', function (req, res) { req.check('post', 'Post too long').isLength({ max: 140 }); let errors = req.validationErrors(); if (errors) { res.status(400).send(errors); } else { res.send('Blog post added!') } }); hapi: npm install joi const Joi = require('joi') server.route({ method: 'POST', path: '/post', handler: (request, h) => { return 'Blog post added!'; }, options: { validate: { payload: Joi.object({ post: Joi.string().max(140) }) } } }); First you install `joi`, then require it in your project. To validate the input data, you specify what data type you are expecting, then set rules on that data. In this case, `post` will be a `string` with a maximum number of characters of 140. In `joi` you can string rules together like: Joi.string().min(1).max(140). ### Output Validation As stated above, there is no clear way of doing response validation with `express-validator`. With `joi`, response validation is fast and simple. Lets have a look: hapi: const bookSchema = Joi.object({ title: Joi.string().required(), author: Joi.string().required(), isbn: Joi.string().length(10), pageCount: Joi.number(), datePublished: Joi.date().iso() }); server.route({ method: 'GET', path: '/books', handler: async function (request, h) { return await getBooks(); }, options: { response: { schema: Joi.array().items(bookSchema), failAction: 'log' } } }); This route will return a list of books. In the `options` route property, we can specify what rules the list of books should follow. By setting the `failAction` to `log`, if there is an error, the server will log the error. ## app.set('view engine') -> vision hapi has extensive support for template rendering, including the ability to load and leverage multiple templating engines, partials, helpers (functions used in templates to manipulate data), and layouts. Express enables views capabilities by using `app.set('view engine')`, where hapi's capabilities are provided by the [vision](/module/vision) plugin. For a more extensive tutorial on views in hapi, please see the [views](/tutorials/views/?lang=en_US) tutorial. ### Setting the View Engine Setting the views engine in express looks like the following: app.set('view engine', 'pug'); To set the views engine in hapi, you first must register the vision plugin, then configure `server.views`: await server.register(require('@hapi/vision')); server.views({ engines: { pug: require('pug') }, relativeTo: __dirname, path: 'views' }); By default, Express will look for views or templates in the `views` folder. In hapi, you specify where the views are located using the `relativeTo` and `path` properties. Like Express, hapi supports a wide variety of templating engines, such as pug, ejs, handlebars, etc. hapi has many more configurable options in `server.views`. To see the full list of capabilities, please go to the [views](/tutorials/views/?lang=en_US) tutorial. ### Rendering a View To render a view in Express, you would call `res.render()`. hapi, by way of vision, has two methods for rendering views, `h.view` and the view handler. Lets look at how to do both. First, rendering a view in Express: app.get('/', function (req, res) { res.render('index', { title: 'Homepage', message: 'Welcome' }); }); Using `h.view` in hapi: server.route({ method: 'GET', path: '/', handler: function (request, h) { return h.view('index', { title: 'Homepage', message: 'Welcome' }); } }); And using the view handler in hapi: server.route({ method: 'GET', path: '/', handler: { view: { template: 'index', context: { title: 'Homepage', message: 'Welcome' } } } }); To pass context in `h.view`, you pass an object as the second parameter. To pass context in the view handler, you use the `context` key. ## express.static() -> inert hapi gets its ability to serve static content from a plugin called [inert](/module/inert). inert provides new handler methods for serving static files and directories, as well as adding a `h.file()` method to the response toolkit. For a more in-depth tutorial of server static files in hapi, please see the [serving static files](/tutorials/servingfiles/?lang=en_US) tutorial. ### Serving Single Files In Express, you would use the `res.sendFile` method to return a single file. In hapi, you can either use the `h.file()` method or the file handler, which is available via [inert](/module/inert). Once you register the inert plugin, you will be able to serve your static files: Express: app.get('/image', function (req, res) { res.sendFile('image.jpg', {root: './public'}); }); hapi with `h.file()`: const server = new Hapi.Server({ port: 3000, routes: { files: { relativeTo: Path.join(__dirname, 'public') } } }); await server.register(require('@hapi/inert')); server.route({ method: 'GET', path: '/image', handler: function (request, h) { return h.file('image.jpg'); } }); hapi with file handler: const server = new Hapi.Server({ port: 3000, routes: { files: { relativeTo: Path.join(__dirname, 'public') } } }); await server.register(require('@hapi/inert')); server.route({ method: 'GET', path: '/image', handler: { file: 'image.jpg' } }); To serve static files in hapi, you first must tell hapi where the static files are located. You do this by configuring the `server.options.routes` object. You set the `relativeTo` to the folder where the files are located, much like you do in the options object of the `res.sendFile` in Express. Next, you need to register the inert plugin. This will give you access to the methods that allows you to serve static files. Now in your route handler, you can use the `h.file()` method or the file handler to server your static file. ### Static File Server To set up a static file server in Express, you would use the `express.static()` middleware. In hapi, you use the file handler made available by the [inert](/module/inert) plugin. You would setup the server in the same way as you did to serve a single static file, by telling where the files are located. You then would setup a route to catch all of the requests and return the correct files. Lets have a look: Express: app.use(express.static('/public')); hapi: const server = new Hapi.Server({ port: 3000, routes: { files: { relativeTo: Path.join(__dirname, 'public') } } }); await server.register(require('@hapi/inert')); server.route({ method: 'GET', path: '/{param*}', handler: { directory: { path: '.' } } }); Now, you can access any static files by going to `localhost:3000/filename`. [inert](/module/inert) has many other options and capabilities. To see what all it can do, please see the [serving static files](/tutorials/servingfiles/?lang=en_US) tutorial. ## Error Handling -> boom hapi uses the [boom](/module/boom) module to handle errors. By default, boom will return the errors in JSON format. Express on the other hand will return a text response by default, which is suboptimal with a JSON API. Lets look a 404 error response with the default settings by submitting a `GET` request to `'/hello'`, which does not exists: Express: Cannot GET /hello hapi: { "statusCode": 404, "error": "Not Found", "message": "Not Found" } ### Custom Messages `boom` allows you to easily change the error message for any status code. Lets take the 404 error above and return a new message: Express: res.status(400).send({status: 404, error: "Page not found"}); hapi: throw Boom.notFound('Page not found'); In Express, you set the status code, then send the error message body. In this case we return a JSON object with the status code and the error message. In `boom`, there is no need to return a JSON object with the status code, it does this by default. In the example above, you throw `Boom.notFound()` to set the error message. `boom` has a long list of 4xx and 5xx errors, such as `Boom.unauthorized()`, `Boom.badRequest()`, `Boom.badImplementation()`, etc. For a complete list, please see the [boom](/module/boom) documentation. ![clipboard](/img/clipboardCheck.png) --- # hapi Documentation # Source: https://hapi.dev/tutorials/gettingstarted/?lang=en_US Tutorials Languages: en-US pt-BR ko-KR tr-TR zh-CN * [Getting Started](/tutorials/gettingstarted/?lang=en_US) * * * * [Express Migration](/tutorials/expresstohapi/?lang=en_US) * * * * [Authentication](/tutorials/auth/?lang=en_US) * * * * [Caching](/tutorials/caching/?lang=en_US) * * * * [Cookies](/tutorials/cookies/?lang=en_US) * * * * [Logging](/tutorials/logging/?lang=en_US) * * * * [Plugins](/tutorials/plugins/?lang=en_US) * * * * [Routing](/tutorials/routing/?lang=en_US) * * * * [Server Methods](/tutorials/servermethods/?lang=en_US) * * * * [Serving Static Files](/tutorials/servingfiles/?lang=en_US) * * * * [Testing](/tutorials/testing/?lang=en_US) * * * * [Validation](/tutorials/validation/?lang=en_US) * * * * [Views](/tutorials/views/?lang=en_US) * * * * [Community Tutorials](/tutorials/community/?lang=en_US) # Getting Started _This tutorial is compatible with hapi v17 and newer_ ## Overview This tutorial will show how to set up a basic hapi server that displays "Hello World!" in your browser. ## Installing hapi Create a new directory `myproject`, and from there: * Run: `cd myproject`, this goes into the created project folder. * Run: `npm init` and follow the prompts. This will generate a package.json file for you. * Run: `npm install @hapi/hapi`, this will install the latest version of hapi as a dependency in your package.json. ## Creating a Server A very basic hapi server looks like the following: 'use strict'; const Hapi = require('@hapi/hapi'); const init = async () => { const server = Hapi.server({ port: 3000, host: 'localhost' }); await server.start(); console.log('Server running on %s', server.info.uri); }; process.on('unhandledRejection', (err) => { console.log(err); process.exit(1); }); init(); First, you require hapi. Then you initialize a new `Hapi.server()` with connection details containing a port number to listen on and the host information. After that you start the server and log that it's running. When creating a server, you can provide a hostname, IP address, a Unix socket file, or Windows named pipe to bind the server to. For more details, see the API reference. The `host` property set to `localhost` is likely the safest choice. In a docker container, however, the localhost may not be accessible outside of the container and using `host: '0.0.0.0'` may be needed. ## Adding Routes After you get the server up and running, its time to add a route that will display "Hello World!" in your browser. 'use strict'; const Hapi = require('@hapi/hapi'); const init = async () => { const server = Hapi.server({ port: 3000, host: 'localhost' }); server.route({ method: 'GET', path: '/', handler: (request, h) => { return 'Hello World!'; } }); await server.start(); console.log('Server running on %s', server.info.uri); }; process.on('unhandledRejection', (err) => { console.log(err); process.exit(1); }); init(); Save the above as `index.js` and start the server with the command `node index.js`. Now you'll find that if you visit `http://localhost:3000` in your browser, you'll see the text 'Hello, World!'. The `method` property can be any valid HTTP method, array of HTTP methods, or an asterisk to allow any method. The `path` property defines the path including parameters. It can contain optional parameters, numbered parameters, and even wildcards. For more details, see the routing tutorial. The `handler` function performs the main business logic of the route and sets the response. The `handler` must return a value, a promise, or throw an error. ## Everything Else hapi has many, many other capabilities and only a select few are documented in tutorials here. This tutorial was intentionally minimal, we highly recommend you to check out the plugins tutorial. It will give some more knowledge to better organize your hapi project. We also have other tutorials of interest, please use the list to your left to check them out. Everything else is documented in the [API reference](/api) and, as always, feel free to ask questions on [github](https://github.com/hapijs/hapi/issues) or just visit us on [slack](https://join.slack.com/t/hapihour/shared_invite/zt-g5ortpsk-ErlnRA2rUcPIWES21oXBOg). ![clipboard](/img/clipboardCheck.png) --- # hapi Documentation # Source: https://hapi.dev/tutorials/logging/?lang=en_US Tutorials Languages: en-US pt-BR ko-KR tr-TR zh-CN * [Getting Started](/tutorials/gettingstarted/?lang=en_US) * * * * [Express Migration](/tutorials/expresstohapi/?lang=en_US) * * * * [Authentication](/tutorials/auth/?lang=en_US) * * * * [Caching](/tutorials/caching/?lang=en_US) * * * * [Cookies](/tutorials/cookies/?lang=en_US) * * * * [Logging](/tutorials/logging/?lang=en_US) * * * * [Plugins](/tutorials/plugins/?lang=en_US) * * * * [Routing](/tutorials/routing/?lang=en_US) * * * * [Server Methods](/tutorials/servermethods/?lang=en_US) * * * * [Serving Static Files](/tutorials/servingfiles/?lang=en_US) * * * * [Testing](/tutorials/testing/?lang=en_US) * * * * [Validation](/tutorials/validation/?lang=en_US) * * * * [Views](/tutorials/views/?lang=en_US) * * * * [Community Tutorials](/tutorials/community/?lang=en_US) # Logging _This tutorial is compatible with hapi v17 and newer_ ## Overview As with any server software, logging is very important. hapi has some built in logging methods, as well as some basic capabilities for displaying these logs. ## Built-in Methods There are two nearly identical logging methods, `server.log(tags, [data, [timestamp]])`, and `request.log(tags, [data])`, which are to be called whenever you want to log an event in your application. ### request.log() You want to call `request.log()` whenever you want to log something in the context of a request, such as a route handler, request lifecycle extension, or authentication scheme. The method takes two argument: `tags`: a string or an array of strings (e.g. `['error', 'database', 'read']`) used to identify the event. Tags are used instead of log levels and provide a much more expressive mechanism for describing and filtering events. `data`: (optional) a message string or object with the application data being logged. If data is a function, the function signature is `function()` and it called once to generate (return value) the actual data emitted to the listeners. For example: server.route({ method: 'GET', path: '/', handler: function (request, h) { request.log('error', 'Event error'); return 'Hello World'; } }); In this example, if there is a request-specific event with a tag of `error`, the event will get logged. You also send a `data` parameter of `Event error`. This can be anything you want, such as an error message or any other details. ### server.log() `server.log()` is used when you have no specific request in scope, for instance, just after your server has started or inside a plugin's `register()` method. `server.log()` takes three parameters, `(tags, data, timestamp)`. The `tags` and `data` parameters are exactly the same as in `request.logs()`. The `timestamp` parameter defaults to `Date.now()` and should only be passed in if you need to override the default for some reason. const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 80 }); server.log(['test', 'error'], 'Test event'); In this example, you'll see that server will log an event with `tags` `'test'` and `'error'`. Since there is no specific request in scope in this example, you use `server.log()`. ## Retrieving and Displaying Logs The hapi server object emits events for each log event. You can use the standard EventEmitter API to listen for such events and display them however you wish. server.events.on('log', (event, tags) => { if (tags.error) { console.log(`Server error: ${event.error ? event.error.message : 'unknown'}`); } }); In this example, you call `server.events.on()` to listen for any `log` event, in this case anything logged with `server.log()`. Events logged with `server.log()` will emit a `log` event and events logged with `request.log()` will emit a `request` event. You can retrieve all logs for a particular request at once via `request.logs`. This will be an array containing all the logged request events. You must first set the `log.collect` option to `true` on the route, otherwise this array will be empty. server.route({ method: 'GET', path: '/', options: { log: { collect: true } }, handler: function (request, h) { return 'hello'; } }); ## Debug Mode (development only) hapi has a debug mode, which is a pain-free way to have your log events printed to the console, without configuring additional plugins or writing logging code yourself. By default, the only errors debug mode will print to console are uncaught errors in user code, and runtime errors from incorrect implementation of hapi's API. You can configure your server to print request events based on tag, however. For example, if you wanted to print any error in a request you would configure your server as follows: `const server = Hapi.server({ debug: { request: ['error'] } });` You can find more information on debug mode in the [API documentation](/api#server.options.debug). ## Logging Plugins The built-in methods provided by hapi for retrieving and printing logs are fairly minimal. For a more feature-rich logging experience, you can look into using a plugin like [hapi-pino](https://www.npmjs.com/package/hapi-pino), [New Relic](https://newrelic.com/instant-observability/hapi/2124da5b-0174-457a-be5a-e0068673b2b5) or any of the other [hapi logging plugins](/plugins#logging). ![clipboard](/img/clipboardCheck.png) --- # hapi Documentation # Source: https://hapi.dev/tutorials/plugins/?lang=en_US Tutorials Languages: en-US pt-BR ko-KR tr-TR zh-CN * [Getting Started](/tutorials/gettingstarted/?lang=en_US) * * * * [Express Migration](/tutorials/expresstohapi/?lang=en_US) * * * * [Authentication](/tutorials/auth/?lang=en_US) * * * * [Caching](/tutorials/caching/?lang=en_US) * * * * [Cookies](/tutorials/cookies/?lang=en_US) * * * * [Logging](/tutorials/logging/?lang=en_US) * * * * [Plugins](/tutorials/plugins/?lang=en_US) * * * * [Routing](/tutorials/routing/?lang=en_US) * * * * [Server Methods](/tutorials/servermethods/?lang=en_US) * * * * [Serving Static Files](/tutorials/servingfiles/?lang=en_US) * * * * [Testing](/tutorials/testing/?lang=en_US) * * * * [Validation](/tutorials/validation/?lang=en_US) * * * * [Views](/tutorials/views/?lang=en_US) * * * * [Community Tutorials](/tutorials/community/?lang=en_US) # Plugins _This tutorial is compatible with hapi v17 and newer_ ## Overview hapi has an extensive and powerful plugin system that allows you to very easily break your application up into isolated pieces of business logic, and reusable utilities. You can either add an existing plugin to your application, or create your own. ## Creating a plugin Plugins are very simple to write. At their core they are an object with a `register` property, that is a function with the signature `async function (server, options)`. Additionally the plugin object has a required `name` property and several optional properties including `version`. A very simple plugin looks like: 'use strict'; const myPlugin = { name: 'myPlugin', version: '1.0.0', register: async function (server, options) { // Create a route for example server.route({ method: 'GET', path: '/test', handler: function (request, h) { return 'hello, world'; } }); // etc ... await someAsyncMethods(); } }; Once this plugin is registered, the server will display `'hello, world'` when the user goes to route `/test`. To write a plugin as an external module, you can specify a `pkg` property: 'use strict'; exports.plugin = { pkg: require('./package.json'), register: async function (server, options) { // Create a route for example server.route({ method: 'GET', path: '/test', handler: function (request, h) { return 'hello, world'; } }); // etc... await someAsyncMethods(); } }; Note that in the first example, we set the `name` and `version` properties explicitly, however in the second we set a `pkg` parameter with the contents of package.json as its value. Either method is acceptable. When written as a module, a plugin can either be top-level module export i.e `module.exports = { register, name, version }` or if you want your module to export more than a hapi plugin, it can be exported as `exports.plugin = { register, name, version }`. Additionally, the plugin object may contain the property `multiple` that when set to `true` tells hapi that it is safe to register your plugin more than once in the same server. Another available property is `once`. When set to `true` will mean hapi ignores subsequent registers of the same plugin without throwing an error. ### The register method As we've seen above, the `register` method accepts two parameters, `server` and `options`. `register` should be an async function that returns once your plugin has completed whatever steps are necessary for it to be registered. Alternatively your register plugin should throw an error if an error occurred while registering your plugin. The `server` object is a reference to the `server` your plugin is being loaded in. The `options` parameter is simply whatever options the user passes to your plugin when calling `server.register(plugins, [options])`. No changes are made and the object is passed directly to your `register` method. Here is an example: 'use strict'; exports.plugin = { pkg: require('./package.json'), register: async function (server, options) { // Create a route for example server.route({ method: 'GET', path: '/test', handler: function (request, h) { const name = options.name; return `Hello ${name}`; } }); // etc... await someAsyncMethods(); } }; Here, you grab a name from the `options` object via `options.name`. You then use that name to return a message to the user. Lets see how you pass that name to the plugin: const start = async function () { await server.register({ plugin: require('myplugin'), options: { name: 'Bob' } }); }; When you register the plugin, you can pass whatever options to it with `server.register(plugins, [options])`. Here you are passing `{ name: "Bob" }` to your plugin, which as you see above, can be accessed with the `options` object when you create the plugin. ## Loading a plugin Plugins can be loaded one at a time, or as a group in an array, by the `server.register(plugins, [options])` method, for example: const start = async function () { const server = Hapi.server(); // load one plugin await server.register(require('myplugin')); // load multiple plugins await server.register([require('myplugin'), require('yourplugin')]); }; To pass options to your plugin, we instead pass an object with `plugin` and `options` keys, such as: const start = async function () { const server = Hapi.server(); await server.register({ plugin: require('myplugin'), options: { message: 'hello' } }); }; These objects can also be passed in an array: const start = async function () { const server = Hapi.server(); await server.register([{ plugin: require('plugin1'), options: {} }, { plugin: require('plugin2'), options: {} }]); }; ### Registration options You may also pass a second optional parameter to `server.register()`. Documentation for this object can be found in the [API reference](/api#server.register\(\)). The options object is used by hapi and is _not_ passed to the plugin(s) being loaded. It allows you to apply `vhost` or `prefix` modifiers to any routes that your plugins register. For example, let's say we have a plugin that looks like this: 'use strict'; exports.plugin = { pkg: require('./package.json'), register: async function (server, options) { server.route({ method: 'GET', path: '/test', handler: function (request, h) { return 'test passed'; } }); // etc... await someAsyncMethods(); } }; Normally, when this plugin is loaded it will create a `GET` route at `/test`. This can be changed by using the `prefix` setting in the options, which will prepend a string to all routes created in the plugin: const start = async function () { const server = Hapi.server(); await server.register(require('myplugin'), { routes: { prefix: '/plugins' } }); }; Now when the plugin is loaded, because of the `prefix` option the `GET` route will be created at `/plugins/test`. Similarly the `options.routes.vhost` property will assign a default `vhost` configuration to any routes created by the plugins being loaded. More detail about the `vhost` configuration can be found in the [API reference](/api#server.route\(\)). ![clipboard](/img/clipboardCheck.png) --- # hapi Documentation # Source: https://hapi.dev/tutorials/routing/?lang=en_US Tutorials Languages: en-US pt-BR ko-KR tr-TR zh-CN * [Getting Started](/tutorials/gettingstarted/?lang=en_US) * * * * [Express Migration](/tutorials/expresstohapi/?lang=en_US) * * * * [Authentication](/tutorials/auth/?lang=en_US) * * * * [Caching](/tutorials/caching/?lang=en_US) * * * * [Cookies](/tutorials/cookies/?lang=en_US) * * * * [Logging](/tutorials/logging/?lang=en_US) * * * * [Plugins](/tutorials/plugins/?lang=en_US) * * * * [Routing](/tutorials/routing/?lang=en_US) * * * * [Server Methods](/tutorials/servermethods/?lang=en_US) * * * * [Serving Static Files](/tutorials/servingfiles/?lang=en_US) * * * * [Testing](/tutorials/testing/?lang=en_US) * * * * [Validation](/tutorials/validation/?lang=en_US) * * * * [Views](/tutorials/views/?lang=en_US) * * * * [Community Tutorials](/tutorials/community/?lang=en_US) # Routing _This tutorial is compatible with hapi v17 and newer_ ## Overview When defining a route in hapi, you need three basic elements: the path, the method, and a handler. These are passed to your server as an object, and can be as simple as the following: server.route({ method: 'GET', path: '/', handler: function (request, h) { return 'Hello World!'; } }); ## Methods The route above responds to a `GET` request to `/` with the string `Hello World!`. The method option can be any valid HTTP method, or an array of methods. Let's say you want the same response when your user sends either a `PUT` or a `POST` request, you could do that with the following: server.route({ method: ['PUT', 'POST'], path: '/', handler: function (request, h) { return 'I did something!'; } }); ## Path The path option must be a string, though it can contain named parameters. To name a parameter in a path, simply wrap it with `{}`. For example: server.route({ method: 'GET', path: '/hello/{user}', handler: function (request, h) { return `Hello ${request.params.user}!`; } }); Note: It is best practice to always return escaped and validated user inputs such as query/path parameters. This is done to prevent echo or XSS attacks. One way to do this is to use [Hoek](/module/hoek) `escapeHtml()` method. With escaping in place, the above example would look like the following: return `Hello ${Hoek.escapeHtml(request.params.user)}!` As you can see above, you have the string `{user}` in your path, which means you're asking for that segment of the path to be assigned to a named parameter. These parameters are stored in the object `request.params` within the handler. Since you named your parameter user, you are able to access the value with the property `request.params.user`, after URI encoding it so as to prevent content injection attacks. For example, going to `/hello/ferris` in your browser, you will see `Hello ferris!`. ## Optional Parameters In the above example, the user parameter is required: a request to `/hello/bob` or `/hello/susan` will work, but a request to `/hello` will not. In order to make a parameter optional, put a question mark at the end of the parameter's name. Here is the same route, but updated to make the `user` parameter optional: server.route({ method: 'GET', path: '/hello/{user?}', handler: function (request, h) { const user = request.params.user ? request.params.user : 'stranger'; return `Hello ${user}!`; } }); Now a request to `/hello/sloan` will reply with `Hello sloan!` and a request to just `/hello` will reply with `Hello stranger!`. It is important to be aware that only the last named parameter in a path can be optional. That means that `/{one?}/{two}/` is an invalid path, since in this case there is another parameter after the optional one. You may also have a named parameter covering only part of a segment of the path for instance `/{filename}.jpg` is valid. You may also have multiple parameters per segment provided there is non-parameter separator between them, meaning `/{filename}.{ext}` is valid whereas `/{filename}{ext}` is not. ## Multi-Segment Parameters Along with optional path parameters, you can also allow parameters that match multiple segments. In order to do this, you use an asterisk and a number. For example: server.route({ method: 'GET', path: '/hello/{user*2}', handler: function (request, h) { const userParts = request.params.user.split('/'); return `Hello ${userParts[0]} ${userParts[1]}!`; } }); With this configuration, a request to `/hello/john/doe` will reply with the string `Hello john doe!`. The important thing to note here is that the parameter is actually the string `"john/doe"`. That's why you did a split on that character to get the two separate parts. The number after the asterisk represents how many path segments should be assigned to the parameter. You can also omit the number entirely, and the parameter will match any number of segments available. Like the optional parameters, a wildcard parameter (for example `/{files*}`) may only appear as the last parameter in your path. When determining what handler to use for a particular request, hapi searches paths in order from most specific to least specific. That means if you have two routes, one with the path `/filename.jpg` and a second route `/filename.{ext}` a request to `/filename.jpg` will match the first route, and not the second. This also means that a route with the path `/{files*}` will be the last route tested, and will only match if all other routes fail. ## Query Parameters Query parameters are common way of sending data to the server. Query parameters are sent via the URL in a `key=value` format. For example: `localhost:3000?name=ferris&location=chicago` There are two query parameters here, `name=ferris` and `location=chicago`. In hapi, you can access query parameters by the `request.query` object. server.route({ method: 'GET', path: '/', handler: function (request, h) { return `Hello ${request.query.name}!`; } }); Here, you simply access the `name` query parameter and return it in the handler, which would read `Hello ferris!`. For more complex query structures, you may opt to use the `qs` module. Consider the following: server.route({ method: 'GET', path: '/', handler: function (request, h) { return request.query; } }); If you sent the request `localhost:3000?foo[bar]=baz`, hapi, by default would return `{ "foo[bar]": "baz" }`. With the [qs](https://github.com/ljharb/qs) module, you can parse the query string out. An example: const Hapi = require('@hapi/hapi'); const Qs = require('qs'); const server = Hapi.server({ port: 3000, host: 'localhost', query: { parser: (query) => Qs.parse(query) } }); server.route({ method: 'GET', path: '/', handler: function (request, h) { return request.query; } }); const init = async () => { await server.start(); console.log('Server running on %s', server.info.uri); }; process.on('unhandledRejection', (err) => { console.log(err); process.exit(1); }); init(); Here, you first require the [qs](https://github.com/ljharb/qs) module. Second, you set the query parameters parser method by setting the `server.options.query.parser` value. In this case, you use the `Qs.parse()` method where `query` is an object containing the incoming `request.query` parameters. Now, anything coming into `request.query` will be parsed with `Qs.parse()`. Lastly, you returned the parsed query string, which would now be: { "foo": { "bar": "baz" } } Note: In the above example, you used the [qs](https://github.com/ljharb/qs) module to handle our parsing, but any parser will do, be it from `npm` or even custom. Just be aware that the method must return an object where each key is a parameter and matching value is the parameter value. ## Request Payload Anytime you send request data to your API, you will be able to access this data in the route handler with `request.payload`. See the following: server.route({ method: 'POST', path: '/signup', handler: function (request, h) { const payload = request.payload; return `Welcome ${payload.username}!`; } }); In the above example, the handler receives data via `request.payload`. In this case, the `request.payload` contains an object that stores user sign up data: `{ username: 'ferris', password: 'password' }` Note: It's always best practice to validate the incoming payload, as it may contain unsafe data. See validation tutorial for more info. ## Handler The handler option is a function that accepts two parameters, `request`, and `h`. The `request` parameter is an object with details about the end user's request, such as path [parameters](#parameters), an [associated payload](#requestpayload), [query parameters](#query), authentication information, headers, etc. Full documentation on what the `request` object contains can be found in the [API reference](/api#request-properties). The second parameter, `h`, is the response toolkit, an object with several methods used to respond to the request. As you've seen in the previous examples, if you wish to respond to a request with some value, you simply return it from the handler. The payload may be a string, a buffer, a JSON serializable object, a stream or a promise. Alternatively you may pass the same value to `h.response(value)` and return that from the handler. The result of this call is a response object, that can be chained with additional methods to alter the response before it is sent. For example `h.response('created').code(201)` will send a payload of created with an HTTP status code of 201. You may also set headers, content type, content length, send a redirection response, and many other things that are documented in the [API reference](/api#response-toolkit). The `handler` option must return a value, a promise, or throw an error. Note: handlers using a fat arrow style function cannot be bound to any `server.bind()` property. Instead, the bound context is available under [`h.context`](/api#h.context). ## Options Aside from these three basic elements, you may also specify an `options` parameter for each route. This is where you configure things like validation, authentication, prerequisites, payload processing, and caching options. More details can be found in the linked tutorials, as well as the [API reference](/api#route-options). Here we will look at some options of validating with Joi. server.route({ method: 'POST', path: '/signup', handler: function (request, h) { const payload = request.payload; return `Welcome ${payload.username}!`; }, options: { auth: false, validate: { payload: { username: Joi.string().min(1).max(20), password: Joi.string().min(7) } } } }); The first property under `options` is `auth`. `auth` will set the authentication configuration for the route. Since this route is for a new user signing up, you will disable authentication. The second property is `validate`. This allows you to set validation rules for various request components, such as `headers`, `params`, `payload`, and `failAction`. You use the [joi](https://joi.dev) package to validate the `request.payload`. For more info, please check the validation tutorial. ## 404 Handling 404 errors will happen whenever your server can't find what was the resource that was requested. It is best practice to handle these errors the proper way. This is easy to do in hapi, by just employing a route that will catch everything your other routes will not. The following example shows how to setup a route to return a custom `404` response. 'use strict'; const Hapi = require('@hapi/hapi'); const internals = {}; const init = async () => { const server = Hapi.server({ port: 3000, host: 'localhost' }); server.route({ method: '*', path: '/{any*}', handler: function (request, h) { return h.response('404 Error! Page Not Found!').code(404); } }); await server.start(); console.log('Server running on %s', server.info.uri); }; init(); First, you configure our server. Next, you setup your route that return your custom 404 response. You use a wildcard, `*`, for the method, so it covers all available methods. Then, you use a very broad, generic path, `'/{any*}`. This will catch any route that our other routes do not. hapi routes will go the the most specific path first, then get broader, till it finds a match. For example, `localhost:3000/login` will go to the `/login` route and not the `/{any*}` route. Lastly, you return a custom 404 response in your handler, letting your users know that the resource they are asking for could not be found. ![clipboard](/img/clipboardCheck.png) --- # hapi Documentation # Source: https://hapi.dev/tutorials/servermethods/?lang=en_US Tutorials Languages: en-US pt-BR ko-KR tr-TR zh-CN * [Getting Started](/tutorials/gettingstarted/?lang=en_US) * * * * [Express Migration](/tutorials/expresstohapi/?lang=en_US) * * * * [Authentication](/tutorials/auth/?lang=en_US) * * * * [Caching](/tutorials/caching/?lang=en_US) * * * * [Cookies](/tutorials/cookies/?lang=en_US) * * * * [Logging](/tutorials/logging/?lang=en_US) * * * * [Plugins](/tutorials/plugins/?lang=en_US) * * * * [Routing](/tutorials/routing/?lang=en_US) * * * * [Server Methods](/tutorials/servermethods/?lang=en_US) * * * * [Serving Static Files](/tutorials/servingfiles/?lang=en_US) * * * * [Testing](/tutorials/testing/?lang=en_US) * * * * [Validation](/tutorials/validation/?lang=en_US) * * * * [Views](/tutorials/views/?lang=en_US) * * * * [Community Tutorials](/tutorials/community/?lang=en_US) # Server Methods _This tutorial is compatible with hapi v17 and newer_ ## Overview Server methods are a useful way of sharing functions by attaching them to your server object rather than requiring a common module everywhere it is needed. Server methods are also used heavily for caching purposes. Since server methods leverage hapi's native caching, they can help reduce your boilerplate to a minimum. See the caching tutorial for more. To register a server method, you call [`server.method()`](/api#server.method\(\)). There are two different ways to call this function. You can call it with the signature `server.method(name, method, [options])`, or you can call it with the signature `server.method(method)`, where `method` is an object with `name`, `method`, and `options` parameters (note that you may also pass an array of these objects). ## server.method() The first way to call `server.method()` is with the signature `server.method(name, method, [options])`: const add = function (x, y) { return x + y; }; server.method('add', add, {}); Here, you create a function called `add`, which takes two parameters and adds them together. Then you call `server.method()` with the name of the method being `add`, the method you are using, the one we just created called `add`, and no options. The second way to call `server.method()` is with the signature `server.method(method)`: const add = function (x, y) { return x + y; }; server.method({ name: 'add', method: add, options: {} }); You create the same function again, called `add`. When you register it this time, configure the `method` object. This case, `name` is the name of the method, `method` is the method you are using, and `options` is an object to configure various options. ### Name The `name` parameter is a string used to retrieve the method from the server later, via [`server.methods[name]`](#server.methods). Note that if you specify a `name` with a `.` character, it is registered as a nested object rather than the literal string. As in: server.method('math.add', add); This server method can then be called via `server.methods.math.add()`. ### Method The `method` parameter is the actual function to call when the method is invoked. It can take any number of arguments. It can be an `async` function, for example: const add = async function (x, y) { const result = await someLongRunningFunction(x, y); return result; }; server.method('add', add, {}); Your server method function should return a valid result or throw an error if one occurs. ## Options When registering `server.method()`, you can configure three `options`: `cache`, `generateKey`, and `bind`. ### Cache A major advantage of server methods is that they may leverage hapi's native caching. The default is to not cache, however if a valid configuration is passed when registering the method, the return value will be cached and served from the cache instead of re-running your method every time it is called. The configuration looks like the following: server.method('add', add, { cache: { expiresIn: 60000, expiresAt: '20:30', staleIn: 30000, staleTimeout: 10000, generateTimeout: 100 } }); The parameters mean: * `expiresIn`: relative expiration expressed in the number of milliseconds since the item was saved in the cache. Cannot be used together with `expiresAt`. * `expiresAt`: time of day expressed in 24h notation using the 'HH:MM' format, at which point all cache records for the route expire. Uses local time. Cannot be used together with `expiresIn`. * `staleIn`: number of milliseconds to mark an item stored in cache as stale and attempt to regenerate it. Must be less than `expiresIn`. * `staleTimeout`: number of milliseconds to wait before returning a stale value while generateFunc is generating a fresh value. * `generateTimeout`: number of milliseconds to wait before returning a timeout error when it takes too long to return a value. When the value is eventually returned, it is stored in the cache for future requests. * `segment`: an optional segment name used to isolate cache items. * `cache`: an optional string with the name of the cache connection configured on your server to use More information on the caching options can be found in the [API Reference](/api#server.methods) as well as the documentation for [catbox](/module/catbox#policy). You can override the `ttl` (time-to-live) of a server method result per-invocation by setting the `ttl` flag. Let's see how this works with the earlier example: const add = async function (x, y, flags) { const result = await someLongRunningFunction(x, y); flags.ttl = 5 * 60 * 1000; // 5 mins return result; }; server.method('add', add, { cache: { expiresIn: 2000, generateTimeout: 100 } }); Here you defined your server method function to have one more parameter than you're expecting to pass to it, the additional `flags` parameter is passed by hapi. You then simply set the `ttl` flag to however long you want the result to be cached for (in milliseconds); if it is set to `0` then the value will never be cached. If you set no flag then the `ttl` will be taken from the cache configuration. ### Generate a Custom Key In addition to the above options, you may also define a custom function used to generate a cache key based on the parameters passed to your method. If your method only accepts some combination of string, number, and boolean values hapi will generate a sane key for you. However, if your method accepts an object parameter, you should specify a function that will generate a cache key similar to the following: const sum = function (array) { let total = 0; array.forEach((item) => { total += item; }); return total; }; server.method('sum', sum, { generateKey: (array) => array.join(',') }); Any arguments that you pass to your method are available to the `generateKey` method. ### Bind The last option available to server methods is `bind`. The `bind` option changes the `this` context within the method. It defaults to the current active context when the method is added. This can be useful for passing in a database client without needing to pass it as a parameter and requiring a custom `generateKey` function, as in: const lookup = async function (id) { // calls myDB.getOne return await this.getOne({ id }); }; server.method('lookup', lookup, { bind: myDB }); ## server.methods To call the server methods we registered above, you would use `server.methods()`. Consider our add function: const add = function (x, y) { return x + y; }; server.method({ name: 'add', method: add, options: {} }); To use this method, simply call `server.methods()` server.methods.add(1, 2); // 3 ![clipboard](/img/clipboardCheck.png) --- # hapi Documentation # Source: https://hapi.dev/tutorials/servingfiles/?lang=en_US Tutorials Languages: en-US pt-BR ko-KR tr-TR zh-CN * [Getting Started](/tutorials/gettingstarted/?lang=en_US) * * * * [Express Migration](/tutorials/expresstohapi/?lang=en_US) * * * * [Authentication](/tutorials/auth/?lang=en_US) * * * * [Caching](/tutorials/caching/?lang=en_US) * * * * [Cookies](/tutorials/cookies/?lang=en_US) * * * * [Logging](/tutorials/logging/?lang=en_US) * * * * [Plugins](/tutorials/plugins/?lang=en_US) * * * * [Routing](/tutorials/routing/?lang=en_US) * * * * [Server Methods](/tutorials/servermethods/?lang=en_US) * * * * [Serving Static Files](/tutorials/servingfiles/?lang=en_US) * * * * [Testing](/tutorials/testing/?lang=en_US) * * * * [Validation](/tutorials/validation/?lang=en_US) * * * * [Views](/tutorials/views/?lang=en_US) * * * * [Community Tutorials](/tutorials/community/?lang=en_US) # Serving Static Content _This tutorial is compatible with hapi v17 and newer_ ## Overview Inevitably while building any web application, the need arises to serve a simple file from disk. There is a hapi plugin called [inert](/module/inert) that adds this functionality to hapi through the use of additional handlers. First you need to install and add `inert` as a dependency to your project: `npm install @hapi/inert` ## Inert The `inert` plugin provides new handler methods for serving static files and directories, as well as adding a `h.file()` method to the toolkit, which can respond with file based resources. ## Relative paths To simplify things, especially if you have multiple routes that respond with files, you can configure a base path in your server and only pass relative paths to `h.file()`: 'use strict'; const Hapi = require('@hapi/hapi'); const Path = require('path'); const start = async () => { const server = Hapi.server({ routes: { files: { relativeTo: Path.join(__dirname, 'public') } } }); await server.register(require('@hapi/inert')); server.route({ method: 'GET', path: '/picture.jpg', handler: function (request, h) { return h.file('picture.jpg'); } }); await server.start(); console.log('Server running at:', server.info.uri); }; start(); When you set an option under `server.options.routes`, such as above, it will apply to _all_ routes. You can also set these options, including the `relativeTo` option on a per-route level. ## `h.file(path, [options])` Now, let's see how to use the [`h.file()`](/module/inert/api#hfilepath-options) method: const start = async () => { const server = Hapi.server(); await server.register(require('@hapi/inert')); server.route({ method: 'GET', path: '/picture.jpg', handler: function (request, h) { return h.file('/path/to/picture.jpg'); } }); await server.start(); console.log('Server running at:', server.info.uri); }; start(); By requiring the `inert` plugin, you get access `h.file()` method. Here, you tell `h.file()` the path of the image you want to return. In this case, `'/path/to/picture.jpg'`. ## File handler An alternative to using the `h.file()` method would be to use the `file` handler: server.route({ method: 'GET', path: '/picture.jpg', handler: { file: 'picture.jpg' } }); ### File handler options You can also specify the parameter as a function that accepts the `request` object and returns a string representing the file's path (absolute or relative): server.route({ method: 'GET', path: '/{filename}', handler: { file: function (request) { return request.params.filename; } } }); It can also be an object with a `path` property. When using the object form of the handler, you can do a few additional things, like setting the `Content-Disposition` header and allowing compressed files like so: server.route({ method: 'GET', path: '/script.js', handler: { file: { path: 'script.js', filename: 'client.js', // override the filename in the Content-Disposition header mode: 'attachment', // specify the Content-Disposition is an attachment lookupCompressed: true // allow looking for script.js.gz if the request allows it } } }); ## Directory handler In addition to the `file` handler, inert also adds a `directory` handler that allows you to specify one route to serve multiple files. In order to use it, you must specify a route path with a parameter. The name of the parameter does not matter, however. You can use the asterisk extension on the parameter to restrict file depth as well. The most basic usage of the directory handler looks like: server.route({ method: 'GET', path: '/{param*}', handler: { directory: { path: 'directory-path-here' } } }); ### Directory handler options The above route will respond to any request by looking for a matching filename in the `directory-path-here` directory. Note that a request to `/` in this configuration will reply with an HTTP `403` response. You can fix this by adding an index file. By default hapi will search in the directory for a file called `index.html`. You can disable serving an index file by setting the index option to `false`, or alternatively you can specify an array of files that inert should look for as index files: server.route({ method: 'GET', path: '/{param*}', handler: { directory: { path: 'directory-path-here', index: ['index.html', 'default.html'] } } }); A request to `/` will now first try to load `/index.html`, then `/default.html`. When there is no index file available, inert can display the contents of the directory as a listing page. You can enable that by setting the `listing` property to `true` like so: server.route({ method: 'GET', path: '/{param*}', handler: { directory: { path: 'directory-path-here', listing: true } } }); Now a request to `/` will reply with HTML showing the contents of the directory. When using the directory handler with listing enabled, by default hidden files will not be shown in the listing. That can be changed by setting the `showHidden` option to `true`. Like the file handler, the directory handler also has a `lookupCompressed` option to serve precompressed files when possible. You can also set a `defaultExtension` that will be appended to requests if the original path is not found. This means that a request for `/bacon` will also try the file `/bacon.html`. ## Static file server One common case for serving static content is setting up a file server. The following example shows how to setup a basic file serve in hapi: const Path = require('path'); const Hapi = require('@hapi/hapi'); const Inert = require('@hapi/inert'); const init = async () => { const server = new Hapi.Server({ port: 3000, routes: { files: { relativeTo: Path.join(__dirname, 'public') } } }); await server.register(Inert); server.route({ method: 'GET', path: '/{param*}', handler: { directory: { path: '.', redirectToSlash: true } } }); await server.start(); console.log('Server running at:', server.info.uri); }; init(); The first thing you do is require both `inert` and `path`. As you will see, you will need both of these to get our file server up and running. Next, you configure `server.options.routes`. You set the location the server will look for the static files by setting the `relativeTo` option. After your server is configured, you then register the `inert` plugin. This will allow you to have access to the `directory` handler, which will enable you to server your files. In the `directory` handler, you configure `path`, which is required, to look in the entire `public` directory which you specified in the `relativeTo` option. The second option is the `redirectToSlash` option. By setting this to `true`, you tell the server to redirect requests without trailing slashes to the same path with those with the trailing slash. ![clipboard](/img/clipboardCheck.png) --- # hapi Documentation # Source: https://hapi.dev/tutorials/testing/?lang=en_US Tutorials Languages: en-US pt-BR ko-KR tr-TR zh-CN * [Getting Started](/tutorials/gettingstarted/?lang=en_US) * * * * [Express Migration](/tutorials/expresstohapi/?lang=en_US) * * * * [Authentication](/tutorials/auth/?lang=en_US) * * * * [Caching](/tutorials/caching/?lang=en_US) * * * * [Cookies](/tutorials/cookies/?lang=en_US) * * * * [Logging](/tutorials/logging/?lang=en_US) * * * * [Plugins](/tutorials/plugins/?lang=en_US) * * * * [Routing](/tutorials/routing/?lang=en_US) * * * * [Server Methods](/tutorials/servermethods/?lang=en_US) * * * * [Serving Static Files](/tutorials/servingfiles/?lang=en_US) * * * * [Testing](/tutorials/testing/?lang=en_US) * * * * [Validation](/tutorials/validation/?lang=en_US) * * * * [Views](/tutorials/views/?lang=en_US) * * * * [Community Tutorials](/tutorials/community/?lang=en_US) # Testing _This tutorial is compatible with hapi v17 and newer_ ## Overview Hapi is designed for creating robust, testable applications. To this end, Hapi includes the ability to test routes without having to actually start a server, completely avoiding the time overheads and added complexity of the TCP protocol. This tutorial goes into a basic setup for testing routes, and outlines one possible setup for a testable application using [lab](/module/lab) and [code](/module/code). ## lab `lab` is a simple test utility for Node.js. Unlike other test utilities, lab uses only async/await features and includes everything you should expect from a modern Node.js test utility. `lab` works with any assertion library that throws an error when a condition isn't met. For this tutorial, you will be using the `code` assertion library. To install `lab`, type the following in your terminal: `npm install --save-dev @hapi/lab` ## code `code` is based on the `chai` assertions library. It was created to be a small, simple, and intuitive assertions library that could be run without plugins, extensions, and have low overhead. To install `code`, type the following in your terminal: `npm install --save-dev @hapi/code` ## Server Setup Taking the server example from the Getting Started tutorial, we make a minor modification to it, such that it doesn't automatically start when referenced from our tests. You might call this file `server.js` and place it in the `lib` directory of your project: 'use strict'; const Hapi = require('@hapi/hapi'); const server = Hapi.server({ port: 3000, host: 'localhost' }); server.route({ method: 'GET', path: '/', handler: function () { return 'Hello World!'; } }); exports.init = async () => { await server.initialize(); return server; }; exports.start = async () => { await server.start(); console.log(`Server running at: ${server.info.uri}`); return server; }; process.on('unhandledRejection', (err) => { console.log(err); process.exit(1); }); You now export, but do not call, `init()` and `start()`. This will allow you to initialize and start the server from different files. The `init()` function will initialize the server (starts the caches, finalizes plugin registration) but does not start the server. This is what you will use in your tests. The `start()` function will actually start the server. This is what you will use in our main entry-point for the server: `use strict`; const { start } = require('lib/server'); start(); What you've created here is a way of starting the server normally by calling its start function in our entry-point, and exposing a port for external HTTP traffic, but you've also got a module which doesn't do anything by default, which you can use in our tests. ## Writing a Route Test In this example you'll use [lab](/module/lab), but the same method can be used for any testing tool such as [Mocha](https://mochajs.org/), [Jest](https://jestjs.io/), [Tap](https://www.node-tap.org/), [Ava](https://github.com/avajs) etc. By default, `lab` loads all the '*.js' files inside the local `test` directory and executes the tests found. To use different directories or files, pass the file or directories as arguments: `$ lab unit.js` To get started, create a file called `example.test.js` in the `test` directory: 'use strict'; const Lab = require('@hapi/lab'); const { expect } = require('@hapi/code'); const { afterEach, beforeEach, describe, it } = exports.lab = Lab.script(); const { init } = require('../lib/server'); describe('GET /', () => { let server; beforeEach(async () => { server = await init(); }); afterEach(async () => { await server.stop(); }); it('responds with 200', async () => { const res = await server.inject({ method: 'get', url: '/' }); expect(res.statusCode).to.equal(200); }); }); Here you are testing whether or not our `'GET'` route will respond with a `200` status code. You first call `describe()` to provide the structure of your test. `describe()` takes two parameters, a description of the test, and the function that will setup the test. Note that you call `init` rather than `start` to set up the server, which means that the server starts, but does not listen on a socket. After each test you call `stop` to cleanup and stop the server. The `it()` function is what will run your test. `it()` takes two parameters, a description of a successful test, and a function to run the test. You will note the use of `inject` on the server. `inject` uses [Shot](/module/shot) to `inject` a request directly into hapi's route handler. This is the magic which allows us to test HTTP methods. To run the tests, you can modify the `package.json` of your project to run your test runner: "scripts": { "test": "lab -v **/*.test.js" } ![clipboard](/img/clipboardCheck.png) --- # hapi Documentation # Source: https://hapi.dev/tutorials/validation/?lang=en_US Tutorials Languages: en-US pt-BR ko-KR tr-TR zh-CN * [Getting Started](/tutorials/gettingstarted/?lang=en_US) * * * * [Express Migration](/tutorials/expresstohapi/?lang=en_US) * * * * [Authentication](/tutorials/auth/?lang=en_US) * * * * [Caching](/tutorials/caching/?lang=en_US) * * * * [Cookies](/tutorials/cookies/?lang=en_US) * * * * [Logging](/tutorials/logging/?lang=en_US) * * * * [Plugins](/tutorials/plugins/?lang=en_US) * * * * [Routing](/tutorials/routing/?lang=en_US) * * * * [Server Methods](/tutorials/servermethods/?lang=en_US) * * * * [Serving Static Files](/tutorials/servingfiles/?lang=en_US) * * * * [Testing](/tutorials/testing/?lang=en_US) * * * * [Validation](/tutorials/validation/?lang=en_US) * * * * [Views](/tutorials/views/?lang=en_US) * * * * [Community Tutorials](/tutorials/community/?lang=en_US) # Validation _This tutorial is compatible with hapi v17 and newer; and joi v16 and newer_ ## Overview Validating data can be very helpful in making sure that your application is stable and secure. hapi allows this functionality by using the module [Joi](https://joi.dev), which allows you to create your validations with a simple and clear object syntax. ## Joi [Joi](https://joi.dev) is an object schema description language and validator for JavaScript objects. Joi allows you to create blueprints or schemas for JavaScript objects to ensure validation of key information. To get started with joi, you must first install and add it as a dependency to your project: `npm install joi` Then, you must import it to your project: `const Joi = require('joi');` ## Input Validation The first type of validation hapi can perform is input validation. This is defined in the `options` object on a route, and is able to validate headers, path parameters, query parameters, and payload data. Note: In the below examples, you'll see that we give a JS object to `route.options.validate`. The `validate` option has a default value of: { headers: true, params: true, query: true, payload: true, state: true, failAction: 'error' } If a key has a value of `true`, there will be no validation. Keys can also be either a validation function using the signature `async function(value, options)` or a `joi` validation object for its properties. The latter allows you to set `joi` options for that particular schema. Here is a partial rewrite of the [Query Parameters](#queryparams) example: options: { validate: { query: Joi.object({ limit: Joi.number().integer().min(1).max(100).default(10) }).options({ stripUnknown: true }); } } Look [here](https://joi.dev) for details about such options. ### Path parameters The first input type that `joi` can validate is path parameters. Consider the following: server.route({ method: 'GET', path: '/hello/{name}', handler: function (request, h) { return `Hello ${request.params.name}!`; }, options: { validate: { params: Joi.object({ name: Joi.string().min(3).max(10) }) } } }); As you can see here, you've passed a `validate.params` option to the `options` object, this is how you tell hapi that the named parameter specified in the path should be validated. Joi's syntax is very simple and clear to read, the validator you passed here makes sure that the parameter is a string with a minimum length of 3 and a maximum length of 10. With this configuration, if you make a request to `/hello/jennifer` you will get the expected `Hello jennifer!` reply, however if you make a request to `/hello/a` you will get an HTTP `400` response that looks like the following: { "error": "Bad Request", "message": "Invalid request params input", "statusCode": 400 } Likewise, if you were to make a request to `/hello/thisnameiswaytoolong`, you'd also get the same error. ### Query parameters To validate query parameters, you simply specify a `validate.query` option in the route's options, and you will get similar effects. By default hapi will not validate anything. If you specify a validator for even one query parameter, that means you _must_ specify a validator for all possible query parameters that you would like to accept. For example, if you have a route that returns a list of blog posts and you would like the user to limit their result set by count, you could use the following configuration: server.route({ method: 'GET', path: '/posts', handler: function (request, h) { return posts.slice(0, request.query.limit); }, options: { validate: { query: Joi.object({ limit: Joi.number().integer().min(1).max(100).default(10) }) } } }); This makes sure that the `limit` query parameter is always an integer between 1 and 100, and if unspecified defaults to 10. However, if you make a request to `/posts?limit=15&offset=15` you get another HTTP `400` response and error. You get an error because the `offset` parameter is not allowed. That's because you didn't provide a validator for it, but you did provide one for the `limit` parameter. ### Payload parameters Also valid is the `validate.payload` option, which will validate payload data sent to a route by the user. It works exactly the same way as query parameters, in that if you validate one key, you must validate them all. Here is an example: server.route({ method: 'POST', path: '/post', handler: function (request, h) { return 'Blog post added'; }, options: { validate: { payload: Joi.object({ post: Joi.string().min(1).max(140), date: Joi.date().required() }) } } }); The above example is a very basic route that handles an incoming blog post. The user submits the blog post and date in the `request.payload` object. Typically, this would then be stored to a database. Before that can happen though, we must validate the payload. First, `joi` states that `post` must be a minimum of 1 character, and a maximum of 140 characters. It also states that `date` must be a valid date in the MM-DD-YYYY format and is required. If any of payload fails validation, the following error will be thrown: { "error": "Bad Request", "message": "Invalid request payload input", "statusCode": 400 } ### Headers You may validate incoming headers as well, with a `validate.headers` option. For example: server.route({ method: 'GET', path:'/hello/{name}', handler: (request, h) => { return `Hello ${request.params.name}!`; }, options: { validate: { headers: Joi.object({ cookie: Joi.string().required() }), options: { allowUnknown: true } } } }); Here, you are validating the cookie header as a string and making sure it is required. The `allowUnknown` option allows other incoming headers to be accepted without being validated. ## Output hapi can also validate responses before they are sent back to the client. This validation is defined in the `response` property of the route `options` object. If a response does not pass the response validation, the client will receive an Internal Server Error (500) response by default (see `response.failAction` below). Output validation is useful for ensuring that your API is serving data that is consistent with its documentation/contract. Additionally, plugins like [hapi-swagger](https://github.com/glennjones/hapi-swagger) can use the response-validation schemas to automatically document each endpoint's output format, thus ensuring that your documentation is always up to date. hapi supports quite a few options to fine-tune output validation. Here are a few of them: ### response.failAction You can choose what to do when response validation fails by setting `response.failAction` to one of the following: * `error`: send an Internal Server Error (500) response (default) * `log`: just log the offense and send the response as-is * `ignore`: take no action and continue processing the request * A lifecycle method with signature `async function(request, h, err)` where `request` is the request object, `h` is the response toolkit and `err` is the validation error. For example: const bookSchema = Joi.object({ title: Joi.string().required(), author: Joi.string().required(), isbn: Joi.string().length(10), pageCount: Joi.number(), datePublished: Joi.date().iso() }); server.route({ method: 'GET', path: '/books', handler: async function (request, h) { return await getBooks(); }, options: { response: { schema: Joi.array().items(bookSchema), failAction: 'log' } } }); This is a route that will return a list of books. We can see that since `failAction` is set to `log`, the server will just log the error and send the response as-is. ### response.sample If performance is a concern, hapi can be configured to validate only a percentage of response. This can be achieved with the `response.sample` property of the route `options`. It should be set to a number between `0`-`100`, representing the percentage of responses that should be validated. Consider the following: const bookSchema = Joi.object({ title: Joi.string().required(), author: Joi.string().required(), isbn: Joi.string().length(10), pageCount: Joi.number(), datePublished: Joi.date().iso() }); server.route({ method: 'GET', path: '/books', handler: async function (request, h) { return await getBooks(); }, options: { response: { sample: 50, schema: Joi.array().items(bookSchema) } } }); Looking at your book route again, you can see, the `sample` value is set to `50`. This means the server will validate one half of the responses. ### response.status Sometimes one endpoint can serve different response objects. For instance, a `POST` route may return one of the following: * `201` with the newly created resource if a new resource is created. * `202` with the old and new values if an existing resource was updated. hapi supports this by allowing you to specify a different validation schema for each response status code. `response.status` is an object with keys that are numeric status codes, and properties that are joi schemas: { response: { status: { 201: dataSchema, 202: Joi.object({ original: dataSchema, updated: dataSchema }) } } } ### response.options Options to pass to joi during validation. Useful to set global options such as `stripUnknown` or `abortEarly`. If a custom validation function is defined via `schema` or `status` then `options` can an arbitrary object that will be passed to this function as the second argument. ## Alternatives to Joi We suggest using Joi for your validation, however each of the validation options hapi provides also accepts a few different options. Most simply, you can specify a boolean for any of the options. By default, all available validators are set to `true` which means that no validation will be performed. If the validation parameter is set to `false` it signifies that no value is allowed for that parameter. You may also pass a custom function with the signature `async function (value, options)` where `value` is the data to be validated and `options` is the validation options as defined on the server object. If a value is returned, the value will replace the original object being validated. For example, if you're validating `request.headers`, the returned value will replace `request.headers` and the original value is stored in `request.orig.headers`. Otherwise, the headers are left unchanged. If an error is thrown, the error is handled according to `failAction`. ![clipboard](/img/clipboardCheck.png) --- # hapi Documentation # Source: https://hapi.dev/tutorials/views/?lang=en_US Tutorials Languages: en-US pt-BR ko-KR tr-TR zh-CN * [Getting Started](/tutorials/gettingstarted/?lang=en_US) * * * * [Express Migration](/tutorials/expresstohapi/?lang=en_US) * * * * [Authentication](/tutorials/auth/?lang=en_US) * * * * [Caching](/tutorials/caching/?lang=en_US) * * * * [Cookies](/tutorials/cookies/?lang=en_US) * * * * [Logging](/tutorials/logging/?lang=en_US) * * * * [Plugins](/tutorials/plugins/?lang=en_US) * * * * [Routing](/tutorials/routing/?lang=en_US) * * * * [Server Methods](/tutorials/servermethods/?lang=en_US) * * * * [Serving Static Files](/tutorials/servingfiles/?lang=en_US) * * * * [Testing](/tutorials/testing/?lang=en_US) * * * * [Validation](/tutorials/validation/?lang=en_US) * * * * [Views](/tutorials/views/?lang=en_US) * * * * [Community Tutorials](/tutorials/community/?lang=en_US) # Views _This tutorial is compatible with hapi v17 and newer_ ## Overview hapi has extensive support for template rendering, including the ability to load and leverage multiple templating engines, partials, helpers (functions used in templates to manipulate data), and layouts. These capabilities are provided by the [vision](/module/vision) plugin. ## Vision [Vision](/module/vision) is a templates rendering plugin for hapi.js. `Vision` decorates the `server`, `request`, and `h` response toolkit interfaces with additional methods for managing view engines that can be used to render templated responses. `Vision` also provides a built-in handler implementation for creating templated responses. `Vision` is compatible with most major templating engines out of the box, such as ejs, handlebars, pug, twig, etc. Engines that don't follow the normal API pattern can still be used by mapping their API to the [vision API](/module/vision). For more info, please see [here](/module/vision). ## Configuring the server To get started with views, first you have to configure at least one templating engine on the server. This is done by using the [`server.views()`](/module/vision/api#serverviewsoptions) method provided by `vision`: 'use strict'; const Path = require('path'); const Hapi = require('@hapi/hapi'); const Hoek = require('@hapi/hoek'); const start = async () => { const server = Hapi.server(); await server.register(require('@hapi/vision')); server.views({ engines: { html: require('handlebars') }, relativeTo: __dirname, path: 'templates' }); await server.start(); }; start(); You're doing several things here. First, you load the [vision](/module/vision) module as a plugin. It adds template rendering support to hapi. Secondly, you register the `handlebars` module as the engine responsible for rendering templates with an extension of `.html`. Next, you tell the server that your templates are located in the `templates` directory. You indicate that this directory should be taken relative to the current directory by providing a `relativeTo` option. By default, hapi will look for templates relative to the current working directory. ## server.views() Options There are many options available to the views engine in hapi. Full documentation can be found in the [vision API reference](/module/vision/api#serverviewsoptions), but we'll go over some of them here as well. Note that all options may be set either globally, which configures them for all registered engines, or local to one specific engine, for example: server.views({ engines: { html: { module: require('handlebars'), compileMode: 'sync' // engine specific } }, compileMode: 'async' // global setting }); ### Engines In order to use views in hapi, you must register at least one templating engine with the server. Templating engines may be either synchronous, or asynchronous, and should be an object with an export named `compile`. The signature of the `compile` method for synchronous engines is `function (template, options)` and that method should return a function with the signature `function (context, options)` which should either throw an error, or return the compiled html. Asynchronous template engines should have a `compile` method with the signature `function (template, options, callback)` which calls `callback` in standard error first format and returns a new method with the signature `function (context, options, callback)`. The returned method should also call `callback` in error first format, with the compiled html being the second parameter. By default, hapi assumes that template engines are synchronous (i.e. `compileMode` defaults to `sync`), to use an asynchronous engine you must set `compileMode` to `async`. Leveraging the `options` parameter in both the `compile` method, and the method it returns, is done via the `compileOptions` and `runtimeOptions` settings. Both of these options default to the empty object `{}`. `compileOptions` is the object passed as the second parameter to `compile`, while `runtimeOptions` is passed to the method that `compile` returns. If only one templating engine is registered, it automatically becomes the default allowing you to leave off the file extension when requesting a view. However, if more than one engine is registered, you must either append the file extension, or set the `defaultExtension` to the engine you use most frequently. For any views that do not use the default engine, you'll still need to specify a file extension. Another useful options is `isCached`. If set to `false`, hapi will not cache the result of templates and will instead read the template from file on each use. When developing your application, this can be very handy as it prevents you from having to restart your app while working on templates. It is recommended that you leave `isCached` to its default value of `true` in production, however. ### Paths Since views can have files in several different locations, hapi allows you to configure several paths to help find things. Those options are: * `path`: the directory that contains your main templates * `partialsPath`: the directory that contains your partials * `helpersPath`: the directory that contains your template helpers * `layoutPath`: the directory that contains layout templates * `relativeTo`: used as a prefix for other path types, if specified other paths can be relative to this directory Additionally, there are two settings that alter how hapi will allow you to use paths. By default, absolute paths and traversing outside of the `path` directory is not allowed. This behavior can be changed by setting the `allowAbsolutePaths` and `allowInsecureAccess` settings to true. For example, if you have a directory structure like: templates\ index.html layout\ layout.html helpers\ getUser.js fortune.js Your configuration might look like: server.views({ engines: { html: require('handlebars') }, relativeTo: __dirname, path: './templates', layoutPath: './templates/layout', helpersPath: './templates/helpers' }); ### Global context In the [rendering a view](#render) tutorial, you saw how to pass context directly into a view, but what if you have some default context that should _always_ be available on all templates? The simplest way to achieve this is by using the `context` option when calling `server.views()`: const context = { title: 'My personal site' }; server.views({ engines: { html: { module: require('handlebars'), compileMode: 'sync' // engine specific } }, context }); The default global context will be merged with any local context passed taking the lowest precedence and applied to your view. ### View helpers JavaScript modules located in the defined `helpersPath` are available in templates. For this example, you will create a view helper `fortune` which will pick and print out one element out of an array of strings, when used in a template. The following snippet is the complete helper function which you will store in a file called `fortune.js` in the `helpers` directory. module.exports = function () { const fortunes = [ 'Heisenberg may have slept here...', 'Wanna buy a duck?', 'Say no, then negotiate.', 'Time and tide wait for no man.', 'To teach is to learn.', 'Never ask the barber if you need a haircut.', 'You will forget that you ever knew me.', 'You will be run over by a beer truck.', 'Fortune favors the lucky.', 'Have a nice day!' ]; const x = Math.floor(Math.random() * fortunes.length); return fortunes[x]; }; Now you can use the view helper in your templates. Here's a code snippet that show's the helper function in `templates/index.html` using handlebars as a rendering engine:

Your fortune

{{fortune}}

Now when you start the server and point your browser to the route which uses your template (which uses your view helper), you should see a paragraph with a randomly selected fortune right below the header. For reference, here is a complete server script that uses the fortune view helper method in a template. 'use strict'; const Hapi = require('@hapi/hapi'); const start = async () => { const server = Hapi.server({ port: 8080 }); await server.register(require('@hapi/vision')); server.views({ engines: { html: require('handlebars') }, relativeTo: __dirname, path: 'templates', helpersPath: 'helpers' }); server.route({ method: 'GET', path: '/', handler: function (request, h) { return h.view('index'); } }); await server.start(); }; start(); ### Layouts `Vision` includes built-in support for view layouts. It comes disabled by default, because it may conflict with other layout systems that specific view engines may provide. We recommend choosing only one layout system. In order to use the built-in layout system, first setup the view engine: server.views({ // ... layout: true, layoutPath: 'templates/layout' }); This enables the built-in layouts and defines the default layout page to `templates/layout/layout.html` (or whatever other extension you're using). Setup a content area in your `layout.html`: {{{content}}} And your view should be just the content:
Content
When rendering the view, the `{{{content}}}` will be replaced by the view contents. If you want a different default layout, you can set the option globally: server.views({ // ... layout: 'another_default' }); You can also specify a different layout per view: return h.view('myview', null, { layout: 'another_layout' }); ## Rendering a view There are two options for rendering a view, you can use either the [`h.view()`](/module/vision/api#hviewtemplate-context-options) method, where `h` is the [response toolkit](/api#response-toolkit) or the view handler. ### h.view() The first method of rendering a view we'll look at is `h.view()`. Here's what a route using this method would look like: server.route({ method: 'GET', path: '/', handler: function (request, h) { return h.view('index'); } }); In order to pass context to `h.view()`, you pass an object as the second parameter, for example: return h.view('index', { title: 'My home page' }); ### View handler The second method of rendering a view, is using hapi's built in view handler. That route would look like: server.route({ method: 'GET', path: '/', handler: { view: 'index' } }); When using the view handler, context is passed in the key `context`, for example: handler: { view: { template: 'index', context: { title: 'My home page' } } } ![clipboard](/img/clipboardCheck.png)