Why do you use DelegatingFilterProxy in springSecurity and what are the benefits of this design?












-2















What I don't understand is why this security framework USES proxy classes to invoke filters. What are the benefits of this design?










share|improve this question



























    -2















    What I don't understand is why this security framework USES proxy classes to invoke filters. What are the benefits of this design?










    share|improve this question

























      -2












      -2








      -2








      What I don't understand is why this security framework USES proxy classes to invoke filters. What are the benefits of this design?










      share|improve this question














      What I don't understand is why this security framework USES proxy classes to invoke filters. What are the benefits of this design?







      spring-security






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 22 '18 at 13:05









      mj.ghdmj.ghd

      525




      525
























          1 Answer
          1






          active

          oldest

          votes


















          0














          I think the documentation of DelegatingFilterProxy gives you quite pretty explanation:




          [...] All
          calls to the filter proxy will then be delegated to that bean in the
          Spring context, which is required to implement the standard Servlet
          Filter interface.



          This approach is particularly useful for Filter implementation with
          complex setup needs, allowing to apply the full Spring bean definition
          machinery to Filter instances. Alternatively, consider standard Filter
          setup in combination with looking up service beans from the Spring
          root application context.



          NOTE: The lifecycle methods defined by the Servlet Filter interface
          will by default not be delegated to the target bean, relying on the
          Spring application context to manage the lifecycle of that bean.
          Specifying the "targetFilterLifecycle" filter init-param as "true"
          will enforce invocation of the Filter.init and Filter.destroy
          lifecycle methods on the target bean, letting the servlet container
          manage the filter lifecycle.
          [...]







          share|improve this answer























            Your Answer






            StackExchange.ifUsing("editor", function () {
            StackExchange.using("externalEditor", function () {
            StackExchange.using("snippets", function () {
            StackExchange.snippets.init();
            });
            });
            }, "code-snippets");

            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "1"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53431690%2fwhy-do-you-use-delegatingfilterproxy-in-springsecurity-and-what-are-the-benefits%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            0














            I think the documentation of DelegatingFilterProxy gives you quite pretty explanation:




            [...] All
            calls to the filter proxy will then be delegated to that bean in the
            Spring context, which is required to implement the standard Servlet
            Filter interface.



            This approach is particularly useful for Filter implementation with
            complex setup needs, allowing to apply the full Spring bean definition
            machinery to Filter instances. Alternatively, consider standard Filter
            setup in combination with looking up service beans from the Spring
            root application context.



            NOTE: The lifecycle methods defined by the Servlet Filter interface
            will by default not be delegated to the target bean, relying on the
            Spring application context to manage the lifecycle of that bean.
            Specifying the "targetFilterLifecycle" filter init-param as "true"
            will enforce invocation of the Filter.init and Filter.destroy
            lifecycle methods on the target bean, letting the servlet container
            manage the filter lifecycle.
            [...]







            share|improve this answer




























              0














              I think the documentation of DelegatingFilterProxy gives you quite pretty explanation:




              [...] All
              calls to the filter proxy will then be delegated to that bean in the
              Spring context, which is required to implement the standard Servlet
              Filter interface.



              This approach is particularly useful for Filter implementation with
              complex setup needs, allowing to apply the full Spring bean definition
              machinery to Filter instances. Alternatively, consider standard Filter
              setup in combination with looking up service beans from the Spring
              root application context.



              NOTE: The lifecycle methods defined by the Servlet Filter interface
              will by default not be delegated to the target bean, relying on the
              Spring application context to manage the lifecycle of that bean.
              Specifying the "targetFilterLifecycle" filter init-param as "true"
              will enforce invocation of the Filter.init and Filter.destroy
              lifecycle methods on the target bean, letting the servlet container
              manage the filter lifecycle.
              [...]







              share|improve this answer


























                0












                0








                0







                I think the documentation of DelegatingFilterProxy gives you quite pretty explanation:




                [...] All
                calls to the filter proxy will then be delegated to that bean in the
                Spring context, which is required to implement the standard Servlet
                Filter interface.



                This approach is particularly useful for Filter implementation with
                complex setup needs, allowing to apply the full Spring bean definition
                machinery to Filter instances. Alternatively, consider standard Filter
                setup in combination with looking up service beans from the Spring
                root application context.



                NOTE: The lifecycle methods defined by the Servlet Filter interface
                will by default not be delegated to the target bean, relying on the
                Spring application context to manage the lifecycle of that bean.
                Specifying the "targetFilterLifecycle" filter init-param as "true"
                will enforce invocation of the Filter.init and Filter.destroy
                lifecycle methods on the target bean, letting the servlet container
                manage the filter lifecycle.
                [...]







                share|improve this answer













                I think the documentation of DelegatingFilterProxy gives you quite pretty explanation:




                [...] All
                calls to the filter proxy will then be delegated to that bean in the
                Spring context, which is required to implement the standard Servlet
                Filter interface.



                This approach is particularly useful for Filter implementation with
                complex setup needs, allowing to apply the full Spring bean definition
                machinery to Filter instances. Alternatively, consider standard Filter
                setup in combination with looking up service beans from the Spring
                root application context.



                NOTE: The lifecycle methods defined by the Servlet Filter interface
                will by default not be delegated to the target bean, relying on the
                Spring application context to manage the lifecycle of that bean.
                Specifying the "targetFilterLifecycle" filter init-param as "true"
                will enforce invocation of the Filter.init and Filter.destroy
                lifecycle methods on the target bean, letting the servlet container
                manage the filter lifecycle.
                [...]








                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Nov 22 '18 at 13:39









                Andrew SashaAndrew Sasha

                489213




                489213






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Stack Overflow!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53431690%2fwhy-do-you-use-delegatingfilterproxy-in-springsecurity-and-what-are-the-benefits%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Wiesbaden

                    Marschland

                    Dieringhausen