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 >
