@@ -546,8 +546,10 @@ And even though xref:servlet/authentication/architecture.adoc#servlet-authentica
546
546
To address that, you can configure Spring Security Java configuration to allow dispatcher types like `FORWARD` and `ERROR`, like so:
547
547
548
548
.Match by Dispatcher Type
549
- ====
550
- .Java
549
+ [tabs]
550
+ ======
551
+ Java::
552
+ +
551
553
[source,java,role="secondary"]
552
554
----
553
555
http
558
560
)
559
561
----
560
562
561
- .Kotlin
563
+ Kotlin::
564
+ +
562
565
[source,kotlin,role="secondary"]
563
566
----
564
567
http {
@@ -570,7 +573,7 @@ http {
570
573
}
571
574
}
572
575
----
573
- ====
576
+ ======
574
577
575
578
[[match-by-mvc]]
576
579
=== Using an MvcRequestMatcher
@@ -584,8 +587,10 @@ For example, if Spring MVC is mapped to `/spring-mvc` instead of `/` (the defaul
584
587
You need to use `MvcRequestMatcher` to split the servlet path and the controller path in your configuration like so:
585
588
586
589
.Match by MvcRequestMatcher
587
- ====
588
- .Java
590
+ [tabs]
591
+ ======
592
+ Java::
593
+ +
589
594
[source,java,role="primary"]
590
595
----
591
596
@Bean
@@ -605,7 +610,8 @@ SecurityFilterChain appEndpoints(HttpSecurity http, MvcRequestMatcher.Builder mv
605
610
}
606
611
----
607
612
608
- .Kotlin
613
+ Kotlin::
614
+ +
609
615
[source,kotlin,role="secondary"]
610
616
----
611
617
@Bean
@@ -622,15 +628,16 @@ fun appEndpoints(http: HttpSecurity, mvc: MvcRequestMatcher.Builder): SecurityFi
622
628
}
623
629
----
624
630
625
- .Xml
631
+ Xml::
632
+ +
626
633
[source,xml,role="secondary"]
627
634
----
628
635
<http>
629
636
<intercept-url servlet-path="/spring-mvc" pattern="/my/controller/**" access="hasAuthority('controller')"/>
630
637
<intercept-url pattern="/**" access="authenticated"/>
631
638
</http>
632
639
----
633
- ====
640
+ ======
634
641
635
642
This need can arise in at least two different ways:
636
643
@@ -646,8 +653,10 @@ This feature is not currently supported in XML
646
653
In Java configuration, you can create your own javadoc:org.springframework.security.web.util.matcher.RequestMatcher[] and supply it to the DSL like so:
647
654
648
655
.Authorize by Dispatcher Type
649
- ====
650
- .Java
656
+ [tabs]
657
+ ======
658
+ Java::
659
+ +
651
660
[source,java,role="secondary"]
652
661
----
653
662
RequestMatcher printview = (request) -> request.getParameter("print") != null;
658
667
)
659
668
----
660
669
661
- .Kotlin
670
+ Kotlin::
671
+ +
662
672
[source,kotlin,role="secondary"]
663
673
----
664
674
val printview: RequestMatcher = { (request) -> request.getParameter("print") != null }
@@ -669,7 +679,7 @@ http {
669
679
}
670
680
}
671
681
----
672
- ====
682
+ ======
673
683
674
684
[TIP]
675
685
Because javadoc:org.springframework.security.web.util.matcher.RequestMatcher[] is a functional interface, you can supply it as a lambda in the DSL.
@@ -889,8 +899,10 @@ When you have static resources it can be tempting to configure the filter chain
889
899
A more secure approach is to permit them using `permitAll` like so:
890
900
891
901
.Permit Static Resources
892
- ====
893
- .Java
902
+ [tabs]
903
+ ======
904
+ Java::
905
+ +
894
906
[source,java,role="secondary"]
895
907
----
896
908
http
900
912
)
901
913
----
902
914
903
- .Kotlin
915
+ Kotlin::
916
+ +
904
917
[source,kotlin,role="secondary"]
905
918
----
906
919
http {
@@ -910,7 +923,7 @@ http {
910
923
}
911
924
}
912
925
----
913
- ====
926
+ ======
914
927
915
928
It's more secure because even with static resources it's important to write secure headers, which Spring Security cannot do if the request is ignored.
916
929
0 commit comments