You said "The error page will be handled by the webapp or the ErrorReportingValve - both of whichh may get called before your Valve depending on how the Valve is configured." How do i ensure that my custom valve is called before the the ErrorReportingValve?Is there some settings i can set?
Thanks for your help. > From: yapk...@hotmail.com > To: users@tomcat.apache.org > Subject: RE: Tomcat valve JAAS : form error page displayed first before > response reaches back to Tomcat valve > Date: Mon, 18 May 2015 11:43:02 -0400 > > so who control the data flow? > Does the data flow has stages just like control flow? > Or is it just the http web server? As long as there are output stream going > out .. the http web server will server those output stream to the client's > browser? > Basically no control stages when comes to data flow? > > > > Date: Mon, 18 May 2015 14:54:24 +0100 > > From: ma...@apache.org > > To: users@tomcat.apache.org > > Subject: Re: Tomcat valve JAAS : form error page displayed first before > > response reaches back to Tomcat valve > > > > On 18/05/2015 13:57, Kim Ming Yap wrote: > > > Wow .. that really confuses me. > > > > > > I've studied the Java EE component and the basic understanding of flow is > > > as follows (if i do not flush the data) > > > > > > client request --> web container (encapsulate request/response) --> > > > filter (contain request/response object) --> Servlet (JSP) --> filter > > > (request / response object here can be modified here for eventual display > > > on browser) --> client browser > > > > > > On the way back the client browser, if i do a break point just > > > immediately after the dofilter() method and stop there, the JSP page is > > > not displayed. > > > > > > So if i get your right: > > > 1. If the above is done without flushing the data .. then yes. That JSP > > > page is not displayed since i stop at the breakpoint. > > > > Correct. The entire response is contained in the output buffer at that > > point. > > > > > 2. However if i do a flush before the break point, data will be send to > > > the client eventhough my code stops at the break point? > > > > Correct. On the first write to the client, the HTTP Response headers > > will be written. This is the point at which the response is considered > > to be committed. The first write may also include some/all of the > > response body. > > > > Flushing can be explicit (the application calls it) or implicit (the > > container calls flush because - for example - there is no more space in > > the output buffer). > > > > > I thought the data flow is part of the control flow .. > > > > > > Gee .. i got this wrong all the while > > > Think i'm seeing the light .. > > > > Happy to help. > > > > Mark > > > > > > > > > > > > >> Date: Mon, 18 May 2015 13:43:14 +0100 > > >> From: ma...@apache.org > > >> To: users@tomcat.apache.org > > >> Subject: Re: Tomcat valve JAAS : form error page displayed first before > > >> response reaches back to Tomcat valve > > >> > > >> On 18/05/2015 13:31, Kim Ming Yap wrote: > > >>> > > >>> Thanks Mark for your suggestion. > > >>> I'm still confused over the last part where you mentioned that 'i am > > >>> confusing myself between control and data'. > > >>> The response object contains output stream (data) to be displayed. > > >>> Always the case. > > >> > > >> No. > > >> > > >> The response contains a reference to the output stream. The output > > >> stream can be flushed to the client *at any point*. There is no > > >> guarantee that it will "contain the [data] to be displayed". > > >> > > >> The (incorrect) sequences you list below describe the control flow. The > > >> data flow (when the application reads the request body, when the > > >> application writes the request body and when the request body is written > > >> to the client) is completely separate. > > >> > > >>> If i enter valid credential .. you'll noticed the flow exactly as > > >>> indicated on my email (I've traced is using system.out.println) > > >>> > > >>> request --> valve --> JAAS --> filter --> JSP --> response --> filter > > >>> --> JAAS --> valve --> browser > > >> > > >> Again, no. JAAS does not call the filter. Your valve calls the > > >> Authenticator which calls JAAS and then (via some additional objects) > > >> the Authenticator calls the filter. > > >> > > >> Neither the request nor the response are part of the processing chain. > > >> They are objects that are passed up and down the chain. > > >> > > >> > > >>> If invalid credential .. > > >>> > > >>> request --> valve --> JAAS --> response --> valve (break point and stop > > >>> here) .. yet JSP error page displayed. > > >>> > > >>> So this is really confusing. > > >> > > >> Take a look at the updated diagrams here: > > >> https://bz.apache.org/bugzilla/show_bug.cgi?id=57282 > > >> > > >>> The response always contains data to be displayed on the client browser. > > >> > > >> No it does not. See comment above re control flow vs data flow. > > >> > > >>> How did the JSP error page displayed when on its way back to the client > > >>> browser .. i did a break point stop at the valve. > > >> > > >> See point above re control flow vs data flow. > > >> > > >> Mark > > >> > > >> > > >>> > > >>> Hm .. > > >>> > > >>> > > >>>> Date: Mon, 18 May 2015 11:14:19 +0100 > > >>>> From: ma...@apache.org > > >>>> To: users@tomcat.apache.org > > >>>> Subject: Re: Tomcat valve JAAS : form error page displayed first > > >>>> before response reaches back to Tomcat valve > > >>>> > > >>>> On 17/05/2015 23:44, Kim Ming Yap wrote: > > >>>>> Hi,I'm building a website using form based authentication integrating > > >>>>> with JAAS for user based authentication. I don't have issue when a > > >>>>> successful credential is authenticated. Rather I'm having difficulty > > >>>>> understanding the flow of JAAS back to the client should the form > > >>>>> based authentication failed. > > >>>>> SOFTWARE:1. Apache Tomee plus 1.7.12. Java 83. Tomcat JAAS Realm > > >>>>> OBJECTIVE:Custom error captured in JAAS login module to propagate to > > >>>>> error page > > >>>> > > >>>> You are unlikely to get much help from Tomcat with this since > > >>>> propagating back custom errors is considered poor security practise (an > > >>>> attacker should not be able to tell why authentication failed). > > >>>> > > >>>>> BASIC UNDERSTANDING: > > >>>>> The Tomcat JAAS layer is not integrated with the web container layer. > > >>>>> Hence the former does not have access to request, session etc. > > >>>> > > >>>> JAAS is integrated as a Realm - i.e. something that validates > > >>>> credentials provided by an Authenticator. The Authenticator has full > > >>>> access to the request and the response. You may want to consider a > > >>>> custom Authenticator. > > >>>> > > >>>>> SOLUTION: > > >>>>> Using ThreadLocal which capture the custom error message in JAAS > > >>>>> layer to be used when the flow reaches back to the custom valve on > > >>>>> the way back to the browser. > > >>>> > > >>>> You need to be careful you don't trigger memory leaks when using > > >>>> ThreadLocals. > > >>>> > > >>>>> PROBELM:Understanding of basic request/response flow involving Tomcat > > >>>>> and JAAS > > >>>>> a. request --> valve --> JAAS --> Filter --> Servlet/JSP b. > > >>>>> response <-- valve (**) <-- JAAS <-- Filter <-- Servlet/JSP > > >>>> > > >>>> I suspect that order is wrong. > > >>>> > > >>>> JAAS is called by the Authenticator (which is a valve). The > > >>>> Authenticator then calls the Filter (via a few other layers). > > >>>> > > >>>> You might want to check the ordering of your valve and the > > >>>> Authenticator. > > >>>> > > >>>>> (refer to above clause b)ThreadLocal in the JAAS layer managed to > > >>>>> capture the custom error message and it i managed to print it after > > >>>>> the getNext() method of the custom valve. Thought of adding this > > >>>>> custom error as an attribute in the session object. > > >>>>> However I noticed that the error page is already displayed before i > > >>>>> could add this cusom error (immediately after the getNext method). > > >>>> > > >>>> The error page will be handled by the webapp or the ErrorReportingValve > > >>>> - both of whichh may get called before your Valve depending on how the > > >>>> Valve is configured. > > >>>> > > >>>>> Due to that the ready custom error message cannot be used > > >>>>> SAMPLE CODES: > > >>>>> 1. web.xml > > >>>>> <login-config> <auth-method>FORM</auth-method> > > >>>>> <form-login-config> > > >>>>> <form-login-page>/login.jsp</form-login-page> > > >>>>> <form-error-page>/login-redirect-error.jsp?error=true</form-error-page> > > >>>>> </form-login-config> </login-config> > > >>>>> 2. Custom valve and defined in META-INF/context.xml > > >>>>> public class SecurityValve extends ValveBase { > > >>>>> public void invoke(Request request, Response response) throws > > >>>>> IOException, ServletException { getNext().invoke(request, > > >>>>> response); system.out.println("after getNext()"); --> break > > >>>>> point (BP) } > > >>>>> } > > >>>>> 1. Did a break point on SecurityValve (indicated at BP) 2. On > > >>>>> forms, i purposely enter wrong credential and submit 3. Break > > >>>>> point stops at BP 4. login-redirect-error.jsp displayed already > > >>>>> 5. Since it stop at break point BP in SecurityValve, the response > > >>>>> back to client flow has not reached the browser. Yet the > > >>>>> login-redirect-error.jsp is already displayed > > >>>>> QUESTIONS: How can the login-redirect-error.jsp be displayed on the > > >>>>> browser when the response flowing back to client stop at break point > > >>>>> BP? The flow back to the client is not fully done yet. > > >>>> > > >>>> You are confusing control and data. The data goes back to the client as > > >>>> soon as the output is flushed (which can happen in the Servlet/JSP). > > >>>> > > >>>>> I would really appreciate any help.Thanks. > > >>>> > > >>>> Set a break point in a JSP / Servlet and look at the stack trace to see > > >>>> which Valves the request/response flow through in which order. > > >>>> > > >>>> Mark > > >>>> > > >>>> > > >>>> --------------------------------------------------------------------- > > >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > >>>> For additional commands, e-mail: users-h...@tomcat.apache.org > > >>>> > > >>> > > >>> > > >> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > >> For additional commands, e-mail: users-h...@tomcat.apache.org > > >> > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > >
