You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You will also need to setup handlers to serve your actual login page, and a handler to handle the actual login itself.
1283
1283
To handle the login we provide a prebuilt handler {@link io.vertx.ext.web.handler.FormLoginHandler} for the purpose.
1284
1284
1285
+
IMPORTANT: The {@link io.vertx.ext.web.handler.FormLoginHandler} requires a {@link io.vertx.ext.web.handler.BodyHandler} to read `POST` requests content.
1286
+
1285
1287
Here's an example of a simple app, using a redirect auth handler on the default redirect url `/loginpage`.
1286
1288
1287
1289
[source,$lang]
@@ -2241,12 +2243,11 @@ Please see the https://github.com/sockjs/sockjs-client[SockJS website] for more
2241
2243
2242
2244
=== SockJS handler
2243
2245
2244
-
Vert.x provides an out of the box handler called {@link io.vertx.ext.web.handler.sockjs.SockJSHandler} for
2245
-
using SockJS in your Vert.x-Web applications.
2246
+
Vert.x provides an out-of-the-box handler called {@link io.vertx.ext.web.handler.sockjs.SockJSHandler} for using SockJS in your Vert.x-Web applications.
2246
2247
2247
2248
You should create one handler per SockJS application using {@link io.vertx.ext.web.handler.sockjs.SockJSHandler#create}.
2248
-
You can also specify configuration options when creating the instance. The configuration options are described with
2249
-
an instance of {@link io.vertx.ext.web.handler.sockjs.SockJSHandlerOptions}.
2249
+
You can also specify configuration options when creating the instance.
2250
+
The configuration options are described with an instance of {@link io.vertx.ext.web.handler.sockjs.SockJSHandlerOptions}.
2250
2251
2251
2252
[source,$lang]
2252
2253
----
@@ -2267,13 +2268,16 @@ is loaded using {@link io.vertx.ext.web.handler.sockjs.SockJSSocket#routingConte
2267
2268
the users and sessions accessible through {@link io.vertx.ext.web.handler.sockjs.SockJSSocket#webSession()}
2268
2269
and {@link io.vertx.ext.web.handler.sockjs.SockJSSocket#webUser()}.
2269
2270
2270
-
Here's an example of a simple SockJS handler that simply echoes back any back any data that it reads:
2271
+
Here's an example of a simple SockJS handler that simply echoes back any data that it reads:
2271
2272
2272
2273
[source,$lang]
2273
2274
----
2274
2275
{@link examples.WebExamples#example44}
2275
2276
----
2276
2277
2278
+
IMPORTANT: The {@link io.vertx.ext.web.handler.sockjs.SockJSHandler} requires a {@link io.vertx.ext.web.handler.BodyHandler} to read `POST` requests content.
2279
+
This is useful when WebSockets are not available (disabled by intermediate proxies or by configuration).
2280
+
2277
2281
=== The client side
2278
2282
2279
2283
In client side JavaScript you use the SockJS client side library to make connections. For convenience the package is
@@ -2656,6 +2660,8 @@ CSRF or sometimes also known as XSRF is a technique by which an unauthorized sit
2656
2660
Vert.x-Web includes a handler {@link io.vertx.ext.web.handler.CSRFHandler} that you can use to prevent cross site
2657
2661
request forgery requests.
2658
2662
2663
+
IMPORTANT: The {@link io.vertx.ext.web.handler.CSRFHandler} requires a {@link io.vertx.ext.web.handler.BodyHandler} to read the content of requests having an unsafe method (`POST`, `PUT`, ...etc.)
2664
+
2659
2665
On each get request under this handler a cookie is added to the response with a unique token. Clients are then
2660
2666
expected to return this token back in a header. Since cookies are sent it is required that the cookie handler is also
2661
2667
present on the router.
@@ -2671,16 +2677,16 @@ header was present in the Form attributes under the same name as the header, e.g
2671
2677
</form>
2672
2678
----
2673
2679
2674
-
It is the responsibility of the user to fill in the right value for the form field. Users who prefer to use an HTML
2675
-
only solution can fill this value by fetching the the token value from the routing context under the key `X-XSRF-TOKEN`
2680
+
It is the responsibility of the user to fill in the right value for the form field. Users who prefer to use an HTML only solution can fill this value by fetching the token value from the routing context under the key `X-XSRF-TOKEN`
2676
2681
or the header name they have chosen during the instantiation of the `CSRFHandler` object.
2677
2682
2678
2683
[source,$lang]
2679
2684
----
2680
2685
{@link examples.WebExamples#example54}
2681
2686
----
2682
2687
2683
-
Note that this handler is session aware. If there is a session available the form parameter or header might be omited
2688
+
Note that this handler is session aware.
2689
+
If there is a session available the form parameter or header might be omitted
2684
2690
during the `POST` action as it will be read from the session. This also implies that tokens will only be regenerated
0 commit comments