Re: Security Constraints With URL Rewrite filter
Thanks. That was the way I was doing it in the filter (getting the
dispatcher from the various contexts). I changed it. The good news is
that the routing now works as expected. The bad news is that it is still
bypassing the security stuff. I wasn't logged in, and it went straight to
the protected page anyway. Ideas?
Jerry
On Sun, Dec 25, 2011 at 6:58 PM, Konstantin Kolinko
wrote:
> 2011/12/26 Jerry Malcolm <2ndgenfi...@gmail.com>:
> > Konstantin,
> >
> > Thanks for the info. I think I'm getting close. As a test, I have
> created
> > a valve that just forces a redirect. It compiled fine. I registered it
> > under the 'host' tag next to the other valves in server.xml. When I
> send a
> > request in, my print statements write to System.out just as expected.
> >
> > The only problem is, the request forward goes nowhere. Just white screen
> > on the browser. The requestDispatcher returns without any exceptions.
> But
> > I can't find anything in the logs saying anything was wrong. The code is
> > simple:
> >
> > public void invoke(Request request, Response response) throws
> IOException,
> > ServletException {
> >System.out.println( "in Valve" );
> >try{
> > RequestDispatcher requestDispatcher = request.getRequestDispatcher(
> > "/cismanager/jsp/user/home.jsp" );
>
> In short,
> 1) dispatcher is always relative to Context.
> You must get Context first (from a Mapper?) and then get Dispatcher
> from there. (Dropping the "cismanager" part from the URL).
>
>
> If you were doing it from a Filter you would call
> ServletContext.getContext(String) followed by
> ServletContext.getRequestDispatcher().
>
> Note that ServletContext.getContext(String) returns null for better
> security, unless you explicitly set in
> the target web application.
>
> 2) using a RequestDispatcher you will get the same result as with
> using it from inside a Filter. That is it will be a usual "forward",
> and auth constraints wouldn't apply.
>
> Here are tips for debugging Tomcat:
> https://wiki.apache.org/tomcat/FAQ/Developing
>
>
> > System.out.println( "should get here" );
> > requestDispatcher.forward( request, response );
> > System.out.println( "return from forward");
> >}
> >catch( Throwable e){
> > e.printStackTrace( System.out );
> >}
> > //getNext().invoke(request, response);
> > }
> >
> > I figure it's something to do with the URL. I have never used a
> > RequestDispatcher obtained from the Request object outside of a webapp
> > context. From what you said, the valve is 'above' the contexts at the
> > 'host' level. So I assume the parsing of the context out of the URL has
> > yet to occur and therefore should happen in my 'forward'. Hence, I used
> > the entire URL (after the domain name) in the forward. In the example
> > above, I have the webapp mapped to "/cismanager".
> >
> > Am I close? Or is this totally wrong? Should I not use the
> > RequestDispatcher? Should I somehow wrapper the request object and set
> the
> > new URL in that?
> >
> > Thanks again for all the help.
> >
> > Jerry
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: Security Constraints With URL Rewrite filter
2011/12/26 Jerry Malcolm <2ndgenfi...@gmail.com>:
> Konstantin,
>
> Thanks for the info. I think I'm getting close. As a test, I have created
> a valve that just forces a redirect. It compiled fine. I registered it
> under the 'host' tag next to the other valves in server.xml. When I send a
> request in, my print statements write to System.out just as expected.
>
> The only problem is, the request forward goes nowhere. Just white screen
> on the browser. The requestDispatcher returns without any exceptions. But
> I can't find anything in the logs saying anything was wrong. The code is
> simple:
>
> public void invoke(Request request, Response response) throws IOException,
> ServletException {
> System.out.println( "in Valve" );
> try {
> RequestDispatcher requestDispatcher = request.getRequestDispatcher(
> "/cismanager/jsp/user/home.jsp" );
In short,
1) dispatcher is always relative to Context.
You must get Context first (from a Mapper?) and then get Dispatcher
from there. (Dropping the "cismanager" part from the URL).
If you were doing it from a Filter you would call
ServletContext.getContext(String) followed by
ServletContext.getRequestDispatcher().
Note that ServletContext.getContext(String) returns null for better
security, unless you explicitly set in
the target web application.
2) using a RequestDispatcher you will get the same result as with
using it from inside a Filter. That is it will be a usual "forward",
and auth constraints wouldn't apply.
Here are tips for debugging Tomcat:
https://wiki.apache.org/tomcat/FAQ/Developing
> System.out.println( "should get here" );
> requestDispatcher.forward( request, response );
> System.out.println( "return from forward");
> }
> catch( Throwable e) {
> e.printStackTrace( System.out );
> }
> // getNext().invoke(request, response);
> }
>
> I figure it's something to do with the URL. I have never used a
> RequestDispatcher obtained from the Request object outside of a webapp
> context. From what you said, the valve is 'above' the contexts at the
> 'host' level. So I assume the parsing of the context out of the URL has
> yet to occur and therefore should happen in my 'forward'. Hence, I used
> the entire URL (after the domain name) in the forward. In the example
> above, I have the webapp mapped to "/cismanager".
>
> Am I close? Or is this totally wrong? Should I not use the
> RequestDispatcher? Should I somehow wrapper the request object and set the
> new URL in that?
>
> Thanks again for all the help.
>
> Jerry
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Security Constraints With URL Rewrite filter
Konstantin,
Thanks for the info. I think I'm getting close. As a test, I have created
a valve that just forces a redirect. It compiled fine. I registered it
under the 'host' tag next to the other valves in server.xml. When I send a
request in, my print statements write to System.out just as expected.
The only problem is, the request forward goes nowhere. Just white screen
on the browser. The requestDispatcher returns without any exceptions. But
I can't find anything in the logs saying anything was wrong. The code is
simple:
public void invoke(Request request, Response response) throws IOException,
ServletException {
System.out.println( "in Valve" );
try{
RequestDispatcher requestDispatcher = request.getRequestDispatcher(
"/cismanager/jsp/user/home.jsp" );
System.out.println( "should get here" );
requestDispatcher.forward( request, response );
System.out.println( "return from forward");
}
catch( Throwable e){
e.printStackTrace( System.out );
}
//getNext().invoke(request, response);
}
I figure it's something to do with the URL. I have never used a
RequestDispatcher obtained from the Request object outside of a webapp
context. From what you said, the valve is 'above' the contexts at the
'host' level. So I assume the parsing of the context out of the URL has
yet to occur and therefore should happen in my 'forward'. Hence, I used
the entire URL (after the domain name) in the forward. In the example
above, I have the webapp mapped to "/cismanager".
Am I close? Or is this totally wrong? Should I not use the
RequestDispatcher? Should I somehow wrapper the request object and set the
new URL in that?
Thanks again for all the help.
Jerry
Re: response.isCommited() returns false after sendRedirect is called?
Thanks for the answer, Konstantin, Actually I was referring to the HttpServletResponse interface simply because org.apache.catalina.connector. Response implements it and I would expect that its isCommited() implementation complies with it just like ResponseFacade's one does. Thanks! Best Regards, Polina On Fri, Dec 23, 2011 at 10:55 AM, Konstantin Kolinko wrote: > 2011/12/23 Polina Genova : > > Hi, > > > > I accidentally noticed that in valves response.isCommitted() returns > false > > after sendRedirect() is called. > > According to the HttpServletResponse API (and Servlet Specification > v.2.5) > > after sendRedirect() is called the response should be considered > committed > > so I believe isCommitted() should return true in this case, shouldn't it? > > Reproducible on Tomcat 6.35. > > > > To reproduce this, you may use the attached test materials: > >- test dummy valve > >- simple test app with 2 jsps (test.jsp redirects to > index.jsp). > > > > The spec says about HttpServletResponse.isCommitted(), but your valve is > calling > org.apache.catalina.connector.Response.isCommitted(). > > Those are different methods. > > See o.a.c.connector.ResponseFacade#isCommitted() and > Response.isAppCommitted(). > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Security Constraints With URL Rewrite filter
2011/12/26 Jerry Malcolm <2ndgenfi...@gmail.com>: > Thanks for the input. This has turned into something really ugly. Let me > go back and summarize the situation: > > I have an established large application made up of about 10 separate > webapps (contexts) to keep it modular. Within each context there are 3-5 > user roles with varying authority. I organize the jsps in each webapp > based on roles and then set the security constraint to be, for example, > > -- for webapp ABC > -- 'ABCadmin' role for /jsp/admin/*.jsp, > --'ABCoperator' role for /jsp/operator/*.jsp in the ABC webapp. > > Likewise, for webapp XYZ > -- 'XYZadmin' role for /jsp/admin/*.jsp in the XYZ webapp, > -- etc, etc > > This has worked fine for years and I have sold this to the client as being > highly secure. No problems. > > Now, the client's SEO advisor has told them that they have to get rid of > the 'geeky stuff' like /ABC/jsp/guest/aa.jsp in the URLs and replace > them with SEO-friendly 1-word URLs. So that requirement has officially > flowed downstream to me > > So... I wrote a filter (implements javax.servlet.Filter) that takes > SEO-friendly words in the URL and map them to a particular context and path > to the appropriate JSP and uses a RequestDispatcher to forward the > request. I have the filter installed in a special webapp that is mapped to > "/" and therefore will receive all requests to the host. In the filter I > look up the mappings and then use cross-context functionality to route to > the appropriate context/path. No problems with the filter routing as far > as getting the request to the intended target. > > Example: /showPlasmaTVs = > /webAppContext1/jsp/user/products.jsp?productSearch=plasma > > I understand from this discussion that I now have zero security role > protection. I understand why. But that doesn't solve the problem. > > It appears that I have no really good options now: > > 1) make SEO happy and discard security > 2) make security happy and discard SEO requirements > 3) make everything a redirect which probably is the same as #2 since > URLs are now exposed > 4) write code myself to basically re-implement the entire functionality of > Tomcat's security system > > Let's start back from the top maybe I'm approaching the problem > completely incorrectly. I have a hard time believing I'm the first Tomcat > user ever that wants to completely hide ugly URLs and still utilize the > existing context security role structure. > > I'll start over with the question > > --- I want the user to see the URL: /showPlasmaTVs > > -- I want it to map internally to: > /webAppContext1/jsp/user/products.jsp?productSearch=plasma > > -- I would like for it to utilize the existing defined (and tested/proven) > security mappings that are based on the context/paths of the webapps. > > -- or if I have to write code to modify security handling, I don't want a > 3-month development project writing/testing a security module. > > How should I implement it? > > SURELY other Tomcat users have had this requirement...(?) > > Thx. > > Jerry > > > > On Thu, Dec 22, 2011 at 4:15 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: >> On 12/21/11 3:55 PM, Jerry Malcolm wrote: >> > The rewrite filter is correctly rewriting the URLs and forwarding >> > the requests. >> >> Any option to redirect? That would solve everything. >> 1) Do URL rewriting in front of Tomcat: e.g. at Apache HTTPD using mod_rewrite. I think that is the easiest. 2) Use client-side redirects, as Chris mentioned. The downside is that it exposes "internal" URLs to clients. 3) Write a Valve that has access to Tomcat internals. YMMV. I think that with a Valve there might be two ways, though I have not tried any of them. a) I think it can perform mapping and dispatch to a different Сontext as if the request came from the outside, so that its authentication constraints were applied. b) I think it can perform authentication checks using the constraints configured in web.xml of another web application. (See AuthenticatorBase). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Security Constraints With URL Rewrite filter
Thanks for the input. This has turned into something really ugly. Let me go back and summarize the situation: I have an established large application made up of about 10 separate webapps (contexts) to keep it modular. Within each context there are 3-5 user roles with varying authority. I organize the jsps in each webapp based on roles and then set the security constraint to be, for example, -- for webapp ABC -- 'ABCadmin' role for /jsp/admin/*.jsp, --'ABCoperator' role for /jsp/operator/*.jsp in the ABC webapp. Likewise, for webapp XYZ -- 'XYZadmin' role for /jsp/admin/*.jsp in the XYZ webapp, -- etc, etc This has worked fine for years and I have sold this to the client as being highly secure. No problems. Now, the client's SEO advisor has told them that they have to get rid of the 'geeky stuff' like /ABC/jsp/guest/aa.jsp in the URLs and replace them with SEO-friendly 1-word URLs. So that requirement has officially flowed downstream to me So... I wrote a filter (implements javax.servlet.Filter) that takes SEO-friendly words in the URL and map them to a particular context and path to the appropriate JSP and uses a RequestDispatcher to forward the request. I have the filter installed in a special webapp that is mapped to "/" and therefore will receive all requests to the host. In the filter I look up the mappings and then use cross-context functionality to route to the appropriate context/path. No problems with the filter routing as far as getting the request to the intended target. Example: /showPlasmaTVs = /webAppContext1/jsp/user/products.jsp?productSearch=plasma I understand from this discussion that I now have zero security role protection. I understand why. But that doesn't solve the problem. It appears that I have no really good options now: 1) make SEO happy and discard security 2) make security happy and discard SEO requirements 3) make everything a redirect which probably is the same as #2 since URLs are now exposed 4) write code myself to basically re-implement the entire functionality of Tomcat's security system Let's start back from the top maybe I'm approaching the problem completely incorrectly. I have a hard time believing I'm the first Tomcat user ever that wants to completely hide ugly URLs and still utilize the existing context security role structure. I'll start over with the question --- I want the user to see the URL: /showPlasmaTVs -- I want it to map internally to: /webAppContext1/jsp/user/products.jsp?productSearch=plasma -- I would like for it to utilize the existing defined (and tested/proven) security mappings that are based on the context/paths of the webapps. -- or if I have to write code to modify security handling, I don't want a 3-month development project writing/testing a security module. How should I implement it? SURELY other Tomcat users have had this requirement...(?) Thx. Jerry On Thu, Dec 22, 2011 at 4:15 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Jerry, > > On 12/21/11 3:55 PM, Jerry Malcolm wrote: > > The rewrite filter is correctly rewriting the URLs and forwarding > > the requests. > > Any option to redirect? That would solve everything. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk7zq/UACgkQ9CaO5/Lv0PAd/wCfX2zAQ0PMQqCeogRzEs7WBEmB > 3LcAniZ2m3TWCY7OczBa2zCDv85MzOdc > =j2sU > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: java.sql.SQLException: No suitable driver found for in tomcat 6.0.35, is the class loading changed?
2011/12/17 Frank Zhang : > Hi All: > Our code is using apache dbcp library and mysql-connector as > JDBC driver other than tomcat own tomcat-dbcp.jar. we always put > mysql-connector at CATALINA_HOME/lib while put commons-dbcp-1.4.jar > at CATALINA_HOME/webapps/client/WEB-INF/lib/. This worked fairly well in > tomcat 6.0.2x and even in 6.0.33. In 6.0.35 I encountered the error > "java.sql.SQLException: No suitable driver found for" during the booting time > which looks like mysql-connector not in classpath. Considering it's working > all right before, my suspect is 6.0.35 silently changed its class loading > way. Could somebody give me some hints? Thanks. > > Accidentally, I tried putting mysql-connector to > CATALINA_HOME/webapps/client/WEB-INF/lib/, but no better result. > > --- the error > > [java] java.sql.SQLException: No suitable driver found for > jdbc:mysql://localhost:3306/cloud?autoReconnect=true&prepStmtCacheSize=517&cachePrepStmts=true > [java] at java.sql.DriverManager.getConnection(DriverManager.java:640) > [java] at java.sql.DriverManager.getConnection(DriverManager.java:200) > [java] at > org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:75) > [java] at > org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:582) > [java] at > org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1181) > [java] at > org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106) > [java] at > com.cloud.utils.db.Transaction.getStandaloneConnectionWithException(Transaction.java:199) > [java] at > com.cloud.utils.db.Transaction.getStandaloneConnection(Transaction.java:208) > [java] at > com.cloud.utils.db.DbUtil.getConnectionForGlobalLocks(DbUtil.java:59) > [java] at com.cloud.utils.db.DbUtil.getGlobalLock(DbUtil.java:204) > [java] at com.cloud.utils.db.GlobalLock.lock(GlobalLock.java:153) > [java] at > com.cloud.upgrade.DatabaseIntegrityChecker.check(DatabaseIntegrityChecker.java:208) > [java] at > com.cloud.utils.component.ComponentLocator.runCheckers(ComponentLocator.java:240) > [java] at > com.cloud.utils.component.ComponentLocator.parse(ComponentLocator.java:211) > [java] at > com.cloud.utils.component.ComponentLocator.getLocatorInternal(ComponentLocator.java:795) > [java] at > com.cloud.utils.component.ComponentLocator.getLocator(ComponentLocator.java:833) > [java] at > com.cloud.utils.component.ComponentLocator.getComponent(ComponentLocator.java:383) > [java] at > com.cloud.utils.component.ComponentLocator.getComponent(ComponentLocator.java:376) > [java] at > com.cloud.servlet.CloudStartupServlet.init(CloudStartupServlet.java:46) > [java] at javax.servlet.GenericServlet.init(GenericServlet.java:212) > There was 51640: Improve the memory leak prevention for leaks triggered by java.sql.DriverManager. (markt/kkolinko) The same code is in 7.0.21+, so IIRC similar issues were already discussed once. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Odd NIO connector behavior
2011/12/25 Matthew Tyson :
> On Sat, Dec 24, 2011 at 10:33 AM, Matthew Tyson
> wrote:
>
>> On Sat, Dec 24, 2011 at 1:06 AM, Mark Thomas wrote:
>>
>>> On 23/12/2011 23:39, Matthew Tyson wrote:
>>> > Hello,
>>> >
>>> > We have been having quite a few problems with using long-polling
>>> > connections in Tomcat, via the NIO connector. Upgrading to Tomcat
>>> 7.0.23
>>> > definitely improved things, but we are still seeing major issues.
>>>
>>> Glad to hear things are getting better. No so glad to hear you are still
>>> having problems.
>>>
>>> > The problems only crop up after a couple minutes under some load (modest
>>> > load, around 2-3 connections per second).
>>>
>>> That's pretty low load.
>>>
>>
>> It is. We have just a small portion of connections routed to this server.
>>
>>
>>>
>>> > One very clear problem I am looking at right now is that the service
>>> method
>>> > on a servlet is continually being called, although there is no traffic
>>> > coming into tomcat from that remote IP (we verified this at the ethernet
>>> > device).
>>>
>>> Hmm. Very strange that the service method is being called. There needs
>>> to be a complete and valid set of HTTP headers for that to happen and
>>> the request/response gets recycled afterwards so the data shouldn't get
>>> processed twice.
>>>
>>>
>> It is very strange.
>>
>>
>>> > The logging statement at the beginning of the service method is being
>>> > executed every so often, like so:
>>>
>>> > logger.info("REQUEST: " + request.getRemoteAddr() + " " +
>>> > request.getMethod() + " " + request.getQueryString());
>>> >
>>> > INFO 2011-12-23 15:30:50,860 org.cometd.server.CometdServlet REQUEST:
>>> > 75.149.42.46 POST null
>>> > INFO 2011-12-23 15:31:02,484 org.cometd.server.CometdServlet REQUEST:
>>> > 75.149.42.46 GET
>>> >
>>> message=%5B%7B%22channel%22%3A%22%2Fmeta%2Fconnect%22%2C%22connectionType%22%3A%22callback-polling%22%2C%22advice%22%3A%7B%22timeout%22%3A0%7D%2C%22id%22%3A%22354%22%2C%22clientId%22%3A%222b611tiekwk6p2mfh5bye3bm6y7l%22%7D%5D&jsonp=dojo.io.script.jsonp_dojoIoScript135._jsonpCallback
>>> > INFO 2011-12-23 15:31:28,512 org.cometd.server.CometdServlet REQUEST:
>>> > 75.149.42.46 POST null
>>> > INFO 2011-12-23 15:31:36,571 org.cometd.server.CometdServlet REQUEST:
>>> > 75.149.42.46 POST null
>>>
>>> Odd. So there are at least two different requests being processed here.
>>>
>>> > But again, there is no traffic from that IP. I'm not sure if this is
>>> some
>>> > sort of loop, a very long delay, or other connections being mixed up.
>>>
>>> I'm not aware of any connection mix up issues that might explain this.
>>>
>>> > Probably the last, since I don't see any loop pattern, and it has
>>> > continued without any traffic for almost a half an hour now.
>>> >
>>> > Thoughts?
>>>
>>> We need more information :)
>>>
>>> If you can create a simple web application that reproduces this I'd be
>>> happy to take a look. I suspect that is non-trivial so I'll suggest a
>>> couple of other options.
>>>
>>> 1. The simple thing is to add a stack trace to that log message so we
>>> can see exactly what code path is triggered this.
>>>
>>>
>> Here is a couple stack traces from this when the problem is occurring:
>>
>> INFO 2011-12-24 10:25:35,578 COMET REQUEST: 75.149.42.46 POST null |
>> TRACE:
>> java.lang.Throwable
>> at org.cometd.server.CometdServlet.service(CometdServlet.java:149)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
>> at
>> com.company.util.filter.MonitoringFilter.doFilter(MonitoringFilter.java:47)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
>> at
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
>> at
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
>> at
>> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
>> at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
>> at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
>> at
>> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:928)
>> at
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
>> at
>> com.company.util.tomcat.SecureProxyValve.invoke(SecureProxyValve.java:57)
>> at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
>> at
>> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11P
