-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Ming Yap,
On 5/18/15 11:43 AM, Kim Ming Yap wrote: > so who control the data flow? The data is really just a data stream. Anyone dumping data into that stream "controls the flow". Any component with access to the OutputStream to the client can inject something into it. The method call flow doesn't place any restrictions on what each component is allowed to put into that OutputStream. > Does the data flow has stages just like control flow? It's the Wild West: any component can do anything it wants. > 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? Exactly. > Basically no control stages when comes to data flow? Correct. There are basically two stages: 1. Before the response has been "committed" 2. After the response has been "committed" The "committment" of the response occurs when either of the following things happen: a. The response buffer fills up (container flushes buffer) b. A component explicitly flushes the response buffer Before the response has been committed, you can add/modify/remove response headers, change the response status code (e.g. 200 OK), request the creation of an HttpSession, and a few other things. After the response has been committed, you can do none of those things: only sending bytes to the response stream will work after that. But again, the only things that triggers the "commit" of the response if the response buffer filling up (or an explicit flush() call). Any component can cause that event to occur, and no other components are notified that it's about to happen. You can check to see if the response has been committed, but you can't do anything effective to stop it. - -chris >> 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-erro r-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 >> > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVWkbJAAoJEBzwKT+lPKRYdQMQAJIgdQNJXAKoIgp1xFnZBtc6 ng2KtqSxQLltn2aos5R2hqaTN/mcDsWcQ7f+umFBrKYAtu13bP6qvlkkI2ruNQE8 6Gi1xa7ThUnYZ69Ih4D+5cl3uPDSM5nIV5jR+lUTyk0cPsioI92A8h9llXSQV/Ym qMknTJ1m35BIi7UI2Fqmf4yRXURCECskINe1tWaYiId66+26hYXIB+N2nBy7k0cv +/WAae6dYRRmq1sAvi5q6VY1+qJigtCyin6HPA6TccnRkfbSqzxRHCoKJg8QMYMZ EgKOlHew+dcpuE4ZiN+ced6vxEIv96DurwOS00z7tQyHNfrZZGkXGUQTEi/Q5F+J CJVXKj/H05tJ3+a017lfT51Nr0xVjJRAxuuFxjbfDa2P53Xk0+FO/Hw4e65cB+uc FcUx+BoyaBYJ4y2JYPlcFCU5tTibYkEbkXIeOmiXUuUPRa0vQvgelFQrhS4gltSk OXB89x5nWcmqukaw6GOAVLJo/feJwqC9oapfJSLcIXWloKqS8MjVse/GOAKr61b0 GXIUQmSGJPvFgnYt8FiPyGE+1Nh19UPtCJ0TBsaIUheDilr34BxEX1X6EqmYRCjA iNpedmlyMtqCX0w28QJa4l2e5rn6mIIxYEuytdNAih3tqxiuuneDzCwz5c7RKSsk KD5iQxwCKSr1D1CJyMKX =Z87j -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
