tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <vince.w...@thomsonreuters.com>
Subject RE: JDBCRealm - Works OK but logs errors
Date Wed, 19 Nov 2014 16:59:56 GMT
I ignored the errors logged by JDBCRealm 
and proceeded to create my custom Realm. 
I extended JDBCRealm overriding the authenticate method and 
using inherited JDBCRealm methods for authorization.

This new Realm works OK but JDBCRealm code was logging errors that 
look related to the ones logged by vanilla JDBCRealm.

16-Nov-2014 14:51:34.251 SEVERE [http-nio-8080-exec-15] 
org.apache.catalina.realm.JDBCRealm.getRoles Exception performing authentication
java.sql.SQLException: Closed Statement
at oracle.jdbc.driver.OracleClosedStatement.setString(OracleClosedStatement.java:731)
at oracle.jdbc.driver.OraclePreparedStatementWrapper.setString(OraclePreparedStatementWrapper.java:289)
at org.apache.catalina.realm.JDBCRealm.roles(JDBCRealm.java:691)
at org.apache.catalina.realm.JDBCRealm.getRoles(JDBCRealm.java:594)
at com.vincewebb.tomcat.realm.SafeRealm.authenticate(SafeRealm.java:141)

The production servers that will eventually run this 
are using Tomcat 7.0.54. With that in mind 
I switched to a different DEV server and 
downgraded it to Tomcat 7.0.54, 
the errors stopped happening.

All these instances are using the same 
Oracle 12.1 JDBC driver (ojdbc7.jar)

They are using different versions of Java, 
this is an additional variable for which I apologise.

The one that runs WITHOUT ERRORS is:

Tomcat 7.0.54
Linux
java version "1.7.0_67"
Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

The ones that work OK but WITH ERRORS are:

Tomcat 8.0.14
Linux
java version "1.7.0_65"
OpenJDK Runtime Environment (rhel-2.5.1.2.0.1.el6_5-x86_64 u65-b17)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)

Tomcat 8.0.14
Windows
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b20)
Java HotSpot(TM) Client VM (build 24.65-b04, mixed mode, sharing)

Regards, Vince


> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: 14 November 2014 02:35
> To: Tomcat Users List
> Subject: Re: JDBCRealm - Works OK but logs errors
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Vince,
> 
> On 11/10/14 11:02 AM, vince.webb@thomsonreuters.com wrote:
> > I have Tomcat 8.0.9 running under NetBeans. An application using
> > JDBCRealm is authenticating and authorising users OK but Tomcat is
> > logging errors.
> 
> I don't believe much has changed in the JDBCRealm area since 8.0.9, but
> could you try with 8.0.15 just to be sure?
> 
> > Errors get logged on Tomcat startup and another each time a user logs
> > in.
> >
> > Numerous occurrences of this Exception:
> >
> > 10-Nov-2014 15:18:48.108 SEVERE [http-nio-8080-exec-3]
> > org.apache.catalina.realm.JDBCRealm.getPassword Exception performing
> > authentication java.sql.SQLException: Closed Statement at
> > oracle.jdbc.driver.OracleClosedStatement.setString(OracleClosedStatement.java:731)
> > at oracle.jdbc.driver.OraclePreparedStatementWrapper.setString(OraclePreparedStatementWrapper.java:289)
> > at org.apache.catalina.realm.JDBCRealm.credentials(JDBCRealm.java:484)
> > at org.apache.catalina.realm.JDBCRealm.getPassword(JDBCRealm.java:525)
> > at org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:387)
> > at org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:334)
> > at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:111)
> > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:578)
> > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136)
> > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
> > at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610)
> > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
> > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:526)
> > at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)
> > at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:655)
> > at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222)
> > at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1566)
> > at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1523)
> > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> > at java.lang.Thread.run(Thread.java:745)
> >
> > And just one of this:
> >
> > 10-Nov-2014 15:18:49.249 FINE [http-nio-8080-exec-7]
> > org.apache.catalina.util.LifecycleBase.start The start() method was
> > called on component
> >
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/di]
> > ] after start() had already been called. The second call will be
> > ignored. org.apache.catalina.LifecycleException at
> > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:127)
> >
> >
> at
> org.apache.catalina.manager.ManagerServlet.start(ManagerServlet.java:12
> 70)
> > at
> >
> org.apache.catalina.manager.ManagerServlet.doGet(ManagerServlet.java:3
> > 57)
> >
> >
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:618)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
> 
> That is very weird... the Manager servlet is calling start()? Have you
> hacked the manager web application at all?
> 
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
> > cationFilterChain.java:291)
> >
> >
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFil
> terChain.java:206)
> > at
> >
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> >
> >
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applic
> ationFilterChain.java:239)
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
> > lterChain.java:206)
> >
> >
> at
> org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetChar
> acterEncodingFilter.java:108)
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
> > cationFilterChain.java:239)
> >
> >
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFil
> terChain.java:206)
> > at
> >
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVa
> > lve.java:219)
> >
> >
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextVal
> ve.java:106)
> > at
> >
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authenticat
> > orBase.java:615)
> >
> >
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.jav
> a:136)
> > at
> >
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.ja
> > va:79)
> >
> >
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccess
> LogValve.java:610)
> > at
> >
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValv
> > e.java:88)
> >
> >
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
> 526)
> > at
> >
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp1
> > 1Processor.java:1078)
> >
> >
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(Ab
> stractProtocol.java:655)
> > at
> >
> org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.pro
> > cess(Http11NioProtocol.java:222)
> >
> >
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoin
> t.java:1566)
> > at
> >
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint
> > .java:1523)
> >
> >
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.ja
> va:1145)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
> > java:615)
> >
> >
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThre
> ad.java:61)
> > at java.lang.Thread.run(Thread.java:745)
> >
> >
> > The Realm is defined in server.xml as follows:
> >
> > <Realm className="org.apache.catalina.realm.JDBCRealm"
> > connectionName="weblogin01" connectionPassword="xxxxxx"
> > type="javax.sql.DataSource" driverName="oracle.jdbc.OracleDriver"
> > connectionURL="jdbc:oracle:thin:@10.15.120.29:1522:DGSPC"
> > userTable="weblogin.t_user" userNameCol="username"
> > userCredCol="password" userRoleTable="weblogin.t_user_role"
> > roleNameCol="rolename"   />
> >
> >
> > The context.xml file is as follows:
> >
> > <?xml version="1.0" encoding="UTF-8"?> <Context antiJARLocking="true"
> > path="/di">
> 
> A context.xml file should not include the "path" attribute. Remove it
> and allow the name of the WAR (or directory, or [context].xml file base
> name) to determine the context path.
> 
> > <ResourceLink name="jdbc/sforum01" global="jdbc/sforum01"
> > type="javax.sql.DataSource"/>
> >
> > <ResourceLink name="jdbc/DonorImports" global="jdbc/DonorImports"
> > type="javax.sql.DataSource"/>
> >
> > </Context>
> 
> The <ResourceLink> is not relevant, as you aren't using a JNDI
> DataSource for your Realm. Some would argue (including me) that the
> JDBCRealm should not be used anymore because it's single-threaded and,
> evidently, possibly buggy. You'd be better off using DataSourceRealm
> instead.
> 
> There are those (I'm not among them) who think that you should not use
> your application's general DataSource for authentication. There are
> good arguments for separating them (DOS prevention, security, etc.) so
> you might consider creating a third JNDI DataSource for authentication
> and using that with your Realm.
> 
> If you don't need your <Realm> for other web applications, I'd
> configure it in your <Context> in META-INF/context.xml instead of in
> server.xml. It's cleaner and won't require a restart. Make sure to use
> localDataSource="true" if you declare your JNDI DataSource in META-
> INF/context.xml as well as your DataSourceRealm.

Chris
Thank you. Putting the Realm into context.xml sounds like 
a good idea but in this case it includes a key which is 
specified on a per environment basis, not per application.

> 
> > The Oracle driver I'm using is ojdbc7.jar which comes with Oracle
> > 12.1.0.1
> >
> > It is my intention to replace JDBCRealm with a custom realm but I
> > don't want to embark on writing that until I understand what is wrong
> > with my current setup.
> >
> > I welcome your thoughts.
> 
> If you are going to write a new Realm it might not be worth trying to
> figure out what's wrong with JDBCRealm. Also, before writing your own
> Realm (I've done it... it's not terribly fun), check out the new
> features available in 8.0.15 to allow you to specify a
> CredentialHandler, plus some updates to the old features. For example,
> you can now enable password salting, iterated hashing, etc. in the out-
> of-the-box Realm (really a new CredentialHandler). There is also a
> PBKDF-based CredentialHandler bundled with Tomcat, and it's trivial to
> write your own that uses bcrypt/scrypt, or your own home-made password-
> handling algorithm that you are free to make as insecure as you'd like.
> :)
> 
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> 
> iQIcBAEBCAAGBQJUZWphAAoJEBzwKT+lPKRYCd8P/j6DtT1SLCkg5A1lPiOjClNB
> P6yibr8xD+uOxIxWggwT0Y3cFLXMdDg+6K+bbGaMbIIkosZ2eSRkaokHGif3Xri6
> 0wMhJKStFJoiQQIs0bRAia4U870wrSZuHFVzN0SqmqCLec4ktEmYGxASpGo6TOYw
> unSvx1TQMJjwFPb8N4/Vx4v/Vkv4zKPS3wZh2dfWS0FASEovBLT5TqVA7XFLLJmf
> 0BzpF5Vat5UNm2ichErWcliQlTtaJj+3Wz9ZiGUqDFRgGh4eAVpMWFhRgGCx+9Tt
> aMIYACYltEO91IioQ+EPcrxkiXLXXXamkqTGCFnrR0v9KmZUPiAbBWOrolN8IuN4
> PHqPmPzP2wC5Br6XJ6+Y3kyQ+Ss9jsSL/g+eD5a6kX3V4HTrwPcR8rOYXWnWgAQH
> BivCfxUqwXw411UaEhLFL8rTRxHl801hN0xLc6HAGPD9agr+C1FhJQfcj/e4RAcv
> 2qPyZYg49kPL+8yQQPR/4ObcMtgDzjG6BTePNFegMOVDWWsWlmCdquMXlg5Kx37z
> QiWGT3AjHBHFVSt+fmei5r/opy8erLNeErXi7TrMyGYFY2yadVY0H8r1Sh//YFo9
> NeE0HYDoNT7A/O1vHndICHrpMPHxui4Zxu1DlglGGX/swrgAxFjhIf88Tk3HekMn
> SKe2ibxYkerYajNxzQZT
> =ctIc
> -----END PGP SIGNATURE-----
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org

Mime
View raw message