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. 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? 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 .. > 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 >
