Chain several auth providers as if they were one. This is useful for cases where one want to authenticate across several providers, for example, database and fallback to passwd file.
Hashing Algorithm. A common interface to interact with any system provided algorithms.
Hashing Strategy manager.
This class will load system provided hashing strategies and algorithms.
Represents an authenticates User and contains operations to authorise the user.
Please consult the documentation for a detailed explanation.
A secure non blocking random number generator isolated to the current context. The PRNG is bound to the vert.x context and setup to close when the context shuts down.
When applicable, use of VertxContextPRNG rather than create new PRNG objects is helpful to keep the system entropy usage to the minimum avoiding potential blocking across the application.
The use of VertxContextPRNG is particularly appropriate when multiple handlers use random numbers.
Factory interface for creating @see \io\vertx\jphp\ext\auth\AuthProvider instances that use the Vert.x JDBC client.
By default the hashing strategy is SHA-512. If you're already running in production this is backwards compatible, however for new deployments or security upgrades it is recommended to use the PBKDF2 strategy as it is the current OWASP recommendation for password storage.
Factory interface for creating JWT based @see \io\vertx\jphp\ext\auth\AuthProvider instances.
Options related to creation of new tokens.
If any expiresInMinutes, audience, subject, issuer are not provided, there is no default. The jwt generated won't include those properties in the payload.
Generated JWTs will include an iat claim by default unless noTimestamp is specified.
Factory interface for creating OAuth2 based @see \io\vertx\jphp\ext\auth\AuthProvider instances.
Functional interface that allows users to implement custom RBAC verifiers for OAuth2/OpenId Connect.
Users are to implement the isAuthorized method to verify authorities. For provides that do not
export the permissions/roles in the token, this interface allows you to communicate with 3rd party services
such as graph APIs to collect the required data.
The contract is that once an authority is checked for a given user, it's value is cached during the execution of the request. If a user is stored to a persistent storage, or the token is introspected, the cache is cleared and a new call will be handled to the implementation.
Simplified factory to create an @see \io\vertx\jphp\ext\auth\oauth2\OAuth2Auth for Google.
Options used to perform blocking query that used to wait for a potential change using long polling.
Options used to placing a given service into "maintenance mode".
During maintenance mode, the service will be marked as unavailable and will not be present in DNS or API queries. Maintenance mode is persistent and will be automatically restored on agent restart.
Holds information describing which operations failed if the transaction was rolled back.
Watches are a way of specifying a view of data (e.g. list of nodes, KV pairs, health checks) which is monitored for updates. When an update is detected, an <code>Handler</code> with <code>AsyncResult</code> is invoked.
As an example, you could watch the status of health checks and notify when a check is critical.
A Vert.x Web handler on which you register health check procedure. It computes the outcome status (`UP` or `DOWN`)
. When the handler process a HTTP request, it computes the global outcome and build a HTTP response as follows:
SMTP mail client for Vert.x <p> A simple asynchronous API for sending mails from Vert.x applications
The shell server.<p/>
A shell server is associated with a collection of : the @see \io\vertx\jphp\ext\shell\ShellServer::registerTermServer method registers a term server. Term servers life cycle are managed by this server.
When a receives an incoming connection, a instance is created and associated with this connection.
The @see \io\vertx\jphp\ext\shell\ShellServer::createShell method can be used to create instance for testing purposes.
A Vert.x Shell command, it can be created from any language using the @see \io\vertx\jphp\ext\shell\command\CommandBuilder::command or from a Java class using @see \io\vertx\jphp\ext\shell\command\Command::create
The command process provides interaction with the process of the command provided by Vert.x Shell.
A job executed in a @see \io\vertx\jphp\ext\shell\system\JobController, grouping one or several process.<p/>
The job life cycle can be controlled with the @see \io\vertx\jphp\ext\shell\system\Job::run, @see \io\vertx\jphp\ext\shell\system\Job::resume and @see \io\vertx\jphp\ext\shell\system\Job::suspend and @see \io\vertx\jphp\ext\shell\system\Job::interrupt methods.
A pseudo terminal used for controlling a @see \io\vertx\jphp\ext\shell\term\Tty. This interface acts as a pseudo terminal master, @see \io\vertx\jphp\ext\shell\term\Pty::slave returns the assocated slave pseudo terminal.
Represents the results of a SQL query.
It contains a list for the column names of the results, and a list of JsonArray - one for each row of the
results.
A common asynchronous client interface for interacting with SQL compliant database
Represents the options one can use to customize the unwrapped connection/statement/resultset types
A ReadStream of Rows from the underlying RDBMS. This class follows the ReadStream semantics and will automatically close the underlying resources if all returned rows are returned. For cases where the results are ignored before the full processing of the returned rows is complete the close method **MUST** be called in order to release underlying resources.
The interface is minimal in order to support all SQL clients not just JDBC.
Structure passed to acknowledgement handler called when a <code>ACK</code> or <code>NACK</code> frame is received. The handler receives an instance of @see \io\vertx\jphp\ext\stomp\Acknowledgement with the subscription @see \io\vertx\jphp\ext\stomp\Frame and the impacted messages. The list of messages depends on the type of acknowledgment used by the subscription.
Subscriptions using the client mode receives all messages that were waiting for acknowledgment that were
sent before the acknowledged messages. The list also contains the acknowledged message. This is a cumulative
acknowledgement. Subscriptions using the client-individual mode receives a singleton list containing only
the acknowledged message.
Represents a STOMP destination.
Depending on the implementation, the message delivery is different. Queue are sending message to only one subscribers, while topics are broadcasting the message to all subscribers.
Implementations must be thread-safe.
Represents a STOMP frame. STOMP frames are structured as follows. It starts by a <code>command</code>, followed by a set of headers. Then the frame may have a body and is finished by a <code>0</code> byte. This class represents this structure and provide access to the different parts.
This class is NOT thread-safe.
Utility methods to build common @see \io\vertx\jphp\ext\stomp\Frames. It defines a non-STOMP frame (<code>PING</code>) that is used for heartbeats. When such frame is written on the wire it is just the <code>0</code> byte.
This class is thread-safe.
Structure passed to server handler when receiving a frame. It provides a reference on the received @see \io\vertx\jphp\ext\stomp\Frame but also on the @see \io\vertx\jphp\ext\stomp\StompServerConnection.
Once a connection to the STOMP server has been made, client receives a @see \io\vertx\jphp\ext\stomp\StompClientConnection, that let send and receive STOMP frames.
Options used to configure a STOMP client. As a STOMP client wraps a Net client, you can also configure the underlying NET client.
Defines a STOMP server. STOMP servers delegates to a @see \io\vertx\jphp\ext\stomp\StompServerHandler that let customize the behavior of the server. By default, it uses a handler compliant with the STOMP specification, but let you change anything.
Class representing a connection between a STOMP client a the server. It keeps a references on the client socket, so let write to this socket.
STOMP server handler implements the behavior of the STOMP server when a specific event occurs. For instance, if let customize the behavior when specific STOMP frames arrives or when a connection is closed. This class has been designed to let you customize the server behavior. The default implementation is compliant with the STOMP specification. In this default implementation, not acknowledge frames are dropped.
A completion object that emits completion notifications either <i>succeeded</i> or <i>failed</i>.
This object provides callback-ability for the end of a test suite, the completion <i>succeeds</i> when all tests pass otherwise it fails.
The test context is used for performing test assertions and manage the completion of the test. This context is provided by <i>vertx-unit</i> as argument of the test case.
Test execution options:
timeout in milliseconds, the default value is 2 minutes useEventLooptrue always runs with an event loopfalse never runs with an event loopnull uses an event loop if there is one (provided by @see \io\vertx\jphp\core\Vertx::currentContext)
otherwise run withoutreporters is an array of reporter configurationsA named suite of test cases that are executed altogether. The suite suite is created with the @see \io\vertx\jphp\ext\unit\TestSuite::create and the returned suite contains initially no tests.<p/>
The suite can declare a callback before the suite with @see \io\vertx\jphp\ext\unit\TestSuite::before or after the suite with @see \io\vertx\jphp\ext\unit\TestSuite::after.
The suite can declare a callback before each test with @see \io\vertx\jphp\ext\unit\TestSuite::beforeEach or after each test with @see \io\vertx\jphp\ext\unit\TestSuite::afterEach.
Each test case of the suite is declared by calling the @see \io\vertx\jphp\ext\unit\TestSuite::test method.
A failure provides the details of a failure that happened during the execution of a test case.<p/>
The failure can be:
Represents an HTTP Cookie.
All cookies must have a name and a value and can optionally have other fields set such as path, domain, etc.
(Derived from io.netty.handler.codec.http.Cookie)
A parsed language header.
Delivers a more direct access to the individual elements of the header it represents
A container with the request's headers that are meaningful enough to be parsed Contains: <ul> <li>Accept -> MIME header, parameters and sortable</li> <li>Accept-Charset -> Parameters and sortable</li> <li>Accept-Encoding -> Parameters and sortable</li> <li>Accept-Language -> Parameters and sortable</li> <li>Content-Type -> MIME header and parameters</li> </ul>
A route is a holder for a set of criteria which determine whether an HTTP request or failure should be routed to a handler.
A router receives request from an @see \io\vertx\jphp\core\http\HttpServer and routes it to the first matching
Represents the context for the handling of a request in Vert.x-Web.
A new instance is created for each HTTP request that is received in the of the router.
The same instance is passed to any matching request or failure handlers during the routing of the request or failure.
The context provides access to the and and allows you to maintain arbitrary data that lives for the lifetime of the context. Contexts are discarded once they have been routed to the handler for the request.
The context also provides access to the @see \io\vertx\jphp\ext\web\Session, cookies and body for the request, given the correct handlers in the application.
Represents a browser session.
Sessions persist between HTTP requests for a single browser session. They are deleted when the browser is closed, or they time-out. Session cookies are used to maintain sessions using a secure UUID.
Sessions can be used to maintain data for a browser session, e.g. a shopping basket.
The context must have first been routed to a @see \io\vertx\jphp\ext\web\handler\SessionHandler for sessions to be available.
Base interface for HTTP request validation with API specification
Interface for OpenAPI3RouterFactory. <br/> To add an handler, use @see \io\vertx\jphp\ext\web\api\contract\openapi3\OpenAPI3RouterFactory::addHandlerByOperationId<br/> Usage example: <pre> <code>OpenAPI3RouterFactory.create(vertx, "src/resources/spec.yaml", asyncResult -> { if (!asyncResult.succeeded()) { // IO failure or spec invalid</code> else { OpenAPI3RouterFactory routerFactory = asyncResult.result(); routerFactory.addHandlerByOperationId("operation_id", routingContext -> { // Do something }, routingContext -> { // Do something with failure handler }); Router router = routerFactory.getRouter(); } }); } </pre> <br/> Handlers are loaded in this order:<br/> <ol> <li>Body handler (Customizable with </li> <li>Custom global handlers configurable with </li> <li>Global security handlers defined in upper spec level</li> <li>Operation specific security handlers</li> <li>Generated validation handler</li> <li>User handlers or "Not implemented" handler</li> </ol>
Interface that define methods for deserialization of array and objects
This interface is used to add custom <b>synchronous</b> functions inside validation process. You can add it in
An interface for add HTTP Request validation. This class can validate parameters inside query, path, headers an body (watch below) <br/> You can assign multiple body type at the same time(for example a JSON schema together with a XML schema). This interface support: <ul> <li>application/x-www-form-urlencoded</li> <li>multipart/form-data</li> <li>application/xml</li> <li>application/json</li> </ul> Also you can add a form parameter for validation without care about content type of your request. For form parameters this interface support both "multipart/form-data" and "application/x-www-form-urlencoded" <br/> This interface allow extra parameters in the request, so it doesn't care if in a request there's a parameter without a specified validation rule <br/> If a parameter is flagged as an array, it will be validated also if the size of array is 1 element
Interface for declaration of method for validate a specific parameter type.<br/> If you want to implement your own type validator, you need only to implement
An HTTP response.
The usual HTTP response attributes are available:
The body of the response is returned by @see \io\vertx\jphp\ext\web\client\HttpResponse::body decoded as the format specified by the @see \io\vertx\jphp\ext\web\codec\BodyCodec that built the response.
Keep in mind that using this HttpResponse impose to fully buffer the response body and should be used for payload
that can fit in memory.
An asynchronous HTTP / HTTP/2 client called <code>WebClient</code>.
The web client makes easy to do HTTP request/response interactions with a web server, and provides advanced features like:
The web client does not deprecate the , it is actually based on it and therefore inherits
its configuration and great features like pooling. The HttpClient should be used when fine grained control over the HTTP
requests/response is necessary.
Converts a @see \io\vertx\jphp\ext\web\client\predicate\ResponsePredicateResult to a <code>Throwable</code> describing the error.
Base interface for auth handlers.
An auth handler allows your application to provide authentication/authorization support.
Auth handler requires a @see \io\vertx\jphp\ext\web\handler\SessionHandler to be on the routing chain before it.
A handler which gathers the entire request body and sets it on the .
It also handles HTTP file uploads and can be used to limit body sizes.
A handler which decodes cookies from the request, makes them available in the and writes them back in the response.
A handler which implements server side http://www.w3.org/TR/cors/[CORS] support for Vert.x-Web.
This handler adds a CSRF token to requests which mutate state. In order change the state a (XSRF-TOKEN) cookie is set with a unique token, that is expected to be sent back in a (X-XSRF-TOKEN) header.
The behavior is to check the request body header and cookie for validity.
This Handler requires session support, thus should be added somewhere below Session and Body handlers.
A handler that serves favicons.
If no file system path is specified it will attempt to serve a resource called `favicon.ico` from the classpath.
Handler that handles login from a form on a custom login page.
Used in conjunction with the @see \io\vertx\jphp\ext\web\handler\RedirectAuthHandler.
An auth handler that provides OAuth2 Authentication support. This handler is suitable for AuthCode flows.
An auth handler that's used to handle auth by redirecting user to a custom login page.
A handler which sets the response content type automatically according to the best <code>Accept</code> header match.
The header is set only if:
Handler which adds a header `x-response-time` in the response of matching requests containing the time taken in ms to process the request.
A handler that maintains a @see \io\vertx\jphp\ext\web\Session for each browser session.
It looks up the session for each request based on a session cookie which contains a session ID. It stores the session when the response is ended in the session store.
The session is available on the routing context with .
The session handler requires a @see \io\vertx\jphp\ext\web\handler\CookieHandler to be on the routing chain before it.
A handler which renders responses using a template engine and where the template name is selected from the URI path.
Handler that will timeout requests if the response has not been written after a certain time.
Timeout requests will be ended with an HTTP status code 503.
This handler should be used if you want to store the User object in the Session so it's available between different requests, without you having re-authenticate each time.
It requires that the session handler is already present on previous matching routes.
It requires an Auth provider so, if the user is deserialized from a clustered session it knows which Auth provider to associate the session with.
Represents an event that occurs on the event bus bridge.
Please consult the documentation for a full explanation.
A session store which stores sessions in a distributed map so they are available across the cluster.