Connection.close() has already been called during login
Am running Tomcat 7 and see this in the logs: SEVERE: Exception performing authentication com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Connection.close() has already been called. Invalid operation in this state. at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at com.mysql.jdbc.Util.handleNewInstance(Util.java:406) at com.mysql.jdbc.Util.getInstance(Util.java:381) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:984) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:926) at com.mysql.jdbc.ConnectionImpl.getMutex(ConnectionImpl.java:3018) at com.mysql.jdbc.ConnectionImpl.commit(ConnectionImpl.java:1512) at org.apache.catalina.realm.JDBCRealm.getPassword(JDBCRealm.java:579) at org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:408) at org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:355) at pacific.tomcat.RootJDBCRealm.authenticate(SourceFile:71) at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:295) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:450) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539) at org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:1773) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) could the reason be ROOT/META-INF/context.xml which says That is, should I be using a datasource realm instead? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection.close() has already been called during login
Initially I thought that my RootJDBCRealm might be the problem, but how can that be? RootJDBCRealm extends Tomcat's own JDBCRealm. It overrides authenticate to call super.authenticate and if there are 3 failures (in that super.authenticate returns null), then it locks out the user. So could the user of RootJDBCRealm still be a problem? Thanks. --- On Mon, 1/23/12, Mark Thomas wrote: > From: Mark Thomas > Subject: Re: Connection.close() has already been called during login > To: "Tomcat Users List" > Date: Monday, January 23, 2012, 12:49 AM > On 23/01/2012 03:49, removeps-c...@yahoo.com > wrote: > > Am running Tomcat 7 and see this in the logs: > > > > SEVERE: Exception performing authentication > > > com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: > Connection.close() has already been called. Invalid > operation in this state. > > at > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > > at > java.lang.reflect.Constructor.newInstance(Constructor.java:513) > > at > com.mysql.jdbc.Util.handleNewInstance(Util.java:406) > > at > com.mysql.jdbc.Util.getInstance(Util.java:381) > > at > com.mysql.jdbc.SQLError.createSQLException(SQLError.java:984) > > at > com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956) > > at > com.mysql.jdbc.SQLError.createSQLException(SQLError.java:926) > > at > com.mysql.jdbc.ConnectionImpl.getMutex(ConnectionImpl.java:3018) > > at > com.mysql.jdbc.ConnectionImpl.commit(ConnectionImpl.java:1512) > > at > org.apache.catalina.realm.JDBCRealm.getPassword(JDBCRealm.java:579) > > at > org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:408) > > at > org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:355) > > at > pacific.tomcat.RootJDBCRealm.authenticate(SourceFile:71) > > The above line is key. You are not using Tomcat's > JDBCRealm. > > > at > org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:295) > > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:450) > > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) > > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) > > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) > > at > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987) > > at > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539) > > at > org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:1773) > > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > > at > java.lang.Thread.run(Thread.java:662) > > > > > > could the reason be ROOT/META-INF/context.xml which > says > > > > > > > > className="pacific.tomcat.RootJDBCRealm" > > > driverName="pacific.driver.PacificMysqlDriver" > > > connectionName="auth" connectionPassword="..." > > > connectionURL="pacific@jdbc:mysql://localhost:3306" > > userTable="user" > userNameCol="username" userCredCol="password" > > > userRoleTable="user_role" roleNameCol="rolename" > > digest="SHA1"/> > > > > That is, should I be using a datasource realm > instead? > > Yes. > > 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
Re: Connection.close() has already been called during login
--- On Mon, 1/23/12, Daniel Mikusa wrote: > From: Daniel Mikusa > Subject: Re: Connection.close() has already been called during login > To: "Tomcat Users List" > Date: Monday, January 23, 2012, 10:55 AM > On Mon, 2012-01-23 at 10:21 -0800, removeps-c...@yahoo.com > wrote: > > Initially I thought that my RootJDBCRealm might be the > problem, but how can that be? > > > RootJDBCRealm extends Tomcat's own JDBCRealm. It > overrides authenticate to call super.authenticate and if > there are 3 failures (in that super.authenticate returns > null), then it locks out the user. > > Sounds a lot like the LockOutRealm. > > https://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#LockOutRealm > > Any reason you opted not to use it? Sorry, I did not know about this class. Will this class work if you have many Tomcats on different machines (possibly load balancing) so regardless of which exact machine the user is directed to, lock realm will know the number of failed login attempts on other machines? > > Dan > > > So could the user of RootJDBCRealm > still be a problem? Thanks. > > > > --- On Mon, 1/23/12, Mark Thomas > wrote: > > > > > From: Mark Thomas > > > Subject: Re: Connection.close() has already been > called during login > > > To: "Tomcat Users List" > > > Date: Monday, January 23, 2012, 12:49 AM > > > On 23/01/2012 03:49, removeps-c...@yahoo.com > > > wrote: > > > > Am running Tomcat 7 and see this in the > logs: > > > > > > > > SEVERE: Exception performing authentication > > > > > > > > com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: > > > Connection.close() has already been called. > Invalid > > > operation in this state. > > > > at > > > > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > > > Method) > > > > at > > > > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > > > > at > > > > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > > > > at > > > > java.lang.reflect.Constructor.newInstance(Constructor.java:513) > > > > at > > > > com.mysql.jdbc.Util.handleNewInstance(Util.java:406) > > > > at > > > com.mysql.jdbc.Util.getInstance(Util.java:381) > > > > at > > > > com.mysql.jdbc.SQLError.createSQLException(SQLError.java:984) > > > > at > > > > com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956) > > > > at > > > > com.mysql.jdbc.SQLError.createSQLException(SQLError.java:926) > > > > at > > > > com.mysql.jdbc.ConnectionImpl.getMutex(ConnectionImpl.java:3018) > > > > at > > > > com.mysql.jdbc.ConnectionImpl.commit(ConnectionImpl.java:1512) > > > > at > > > > org.apache.catalina.realm.JDBCRealm.getPassword(JDBCRealm.java:579) > > > > at > > > > org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:408) > > > > at > > > > org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:355) > > > > at > > > > pacific.tomcat.RootJDBCRealm.authenticate(SourceFile:71) > > > > > > The above line is key. You are not using > Tomcat's > > > JDBCRealm. > > > > > > > at > > > > org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:295) > > > > at > > > > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:450) > > > > at > > > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) > > > > at > > > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) > > > > at > > > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > > > > at > > > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) > > > > at > > > > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987) > > > > at > > > > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539) > > > > at > > > > org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:1773) > > > > at > > > > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > > > > at > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > > > > at > > > java.lang.Thread.run(Thread.java:662) > > > > > > > > > > > > could the reason be > ROOT/META-INF/context.xml which > > > says > > > > > > > > > > > > > > > > > > className="pacific.tomcat.RootJDBCRealm" > > > > > > > driverName="pacific.driver.PacificMysqlDriver" > > > > > > > connectionName="auth" connectionPassword="..." > > > > > > > > connectionURL="pacific@jdbc:mysql://localhost:3306" > > > > > userTable="user" > > > userNameCol="username" userCredCol="password" > > > > > > > userRoleTable="user_role" roleNameCol="rolename" > > > > > digest="SHA1"/> > > > > > > > >
Re: Connection.close() has already been called during login
My code does not talk to another cluster as I have a single Tomcat only, but
just wondering how one would scale.
Maybe the strategy to handle clusters is to write information, such as the list
of the users to the number of times they have logged in in the last hour, into
a location shared by all machines. In my code below the code is stored in
failedAttempts which is a Map where
FailedAttempt represents the number of times the user has logged in in the last
hour or whatever. It is in-memory, which is fine for one Tomcat.
But we could move this Map into a file that is on a mounted drive available
from all Tomcat machines, or we could store it in the database. Either way we
have to synchronize writes to the file or database, and I think database does
this automatically, and maybe FileLock will do the job for the files. But
anyway, it sounds complicated.
As for my my authenticate it was as follows, although I don't see this should
cause the failure in the subject of this email -- "Connection.close() has
already been called during login":
public Principal authenticate(String username, String credentials)
{
threadUserLockedOut.remove();
long curTime = System.currentTimeMillis();
FailedAttempt failedAttempt = failedAttempts.get(username);
if (failedAttempt != null &&
failedAttempt.checkFailedAttemptsReached(curTime))
{
threadUserLockedOut.set(Boolean.TRUE);
return null;
}
Principal result = super.authenticate(username, credentials);
if (result == null)
{
if (failedAttempt != null)
{
failedAttempt.incNumFailedAttempts();
if (failedAttempt.maxFailedAttemptsReached())
{
failedAttempt.setFirstFailedTime(curTime);
logger.warn("User '" + username + "' is locked out after " +
MAX_FAILED_ATTEMPTS + " failed attempts");
threadUserLockedOut.set(Boolean.TRUE);
return null;
}
}
else
{
failedAttempt = new FailedAttempt(curTime);
failedAttempts.put(username, failedAttempt);
}
}
else
{
if (failedAttempt != null)
{
failedAttempts.remove(username);
}
}
return result;
}
--- On Mon, 1/23/12, Christopher Schultz wrote:
> From: Christopher Schultz
> Subject: Re: Connection.close() has already been called during login
> To: "Tomcat Users List"
> Date: Monday, January 23, 2012, 12:15 PM
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> To whom it may concern,
>
> On 1/23/12 2:54 PM, removeps-c...@yahoo.com
> wrote:
> > Sorry, I did not know about [LockOutRealm]. Will
> this class work
> > if you have many Tomcats on different machines
> (possibly load
> > balancing) so regardless of which exact machine the
> user is
> > directed to, lock realm will know the number of failed
> login
> > attempts on other machines?
>
> No, neither this nor any other Tomcat realms are
> cluster-aware.
>
> If you want to track authentication failures across a
> cluster, you
> could subclass LockOutRealm and override these methods:
>
> - - isLocked
> - - unlock
> - - registerAuthFailure
>
> This will allow you to handle the cluster-sync behavior
> separately
> from the authentication behavior which this class already
> handles.
>
> I'm interested in seeing what you come up with for
> communicating with
> the rest of the cluster.
>
> - -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/
>
> iEYEARECAAYFAk8dv+4ACgkQ9CaO5/Lv0PDRnwCgvZFJvYXbU8Gwec6y430aD/rz
> Kk4An2C5ZwXZf4NEaS31A5CWngqGxI9F
> =zDyr
> -END PGP SIGNATURE-
>
> -
> 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
Re: Connection.close() has already been called during login
--- On Mon, 1/23/12, Christopher Schultz wrote:
> From: Christopher Schultz
> Subject: Re: Connection.close() has already been called during login
> To: "Tomcat Users List"
> Date: Monday, January 23, 2012, 2:42 PM
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> To whom it may concern,
>
> On 1/23/12 4:20 PM, removeps-c...@yahoo.com
> wrote:
> > My code does not talk to another cluster as I have a
> single Tomcat
> > only, but just wondering how one would scale.
>
> Me too.
>
> > Maybe the strategy to handle clusters is to write
> information, such
> > as the list of the users to the number of times
> they have logged
> > in in the last hour, into a location shared by all
> machines.
>
> That sounds fairly straightforward.
>
> > In my code below the code is stored in failedAttempts
> which is a
> > Map where
> FailedAttempt
> > represents the number of times the user has logged in
> in the last
> > hour or whatever. It is in-memory, which is fine for
> one Tomcat.
>
> Right. This is how Tomcat does things in its own
> LockOutRealm. Take a
> look at the code. It works with all realm types (see the
> code for the
> different authenticate() methods it implements).
>
> > But we could move this Map into a file that is on a
> mounted drive
> > available from all Tomcat machines, or we could store
> it in the
> > database. Either way we have to synchronize writes to
> the file or
> > database, and I think database does this
> automatically, and maybe
> > FileLock will do the job for the files. But anyway, it
> sounds
> > complicated.
>
> memcached. Cassandra. Whatever.
>
> > As for my my authenticate it was as follows, although
> I don't see
> > this should cause the failure in the subject of this
> email --
> > "Connection.close() has already been called during
> login":
>
> Yup, it certainly doesn't look like your code does anything
> with the
> superclass's Connection.
>
> > public Principal authenticate(String username, String
> credentials)
> > { threadUserLockedOut.remove();
>
> Why in the world are you using a ThreadLocal in here?
The use of the ThreadLocal is unrelated to the connection timing out. It's
just a variable to indicate that in this thread the user is locked out. It is
used later by my RootFormAuthenticator which extends FormAuthenticator to print
out a message like "Your account has been locked out due to N failed attempts".
FYI
@Override
protected void forwardToErrorPage(Request request, HttpServletResponse
response, LoginConfig loginConfig) throws IOException
{
...
if (realm.isThreadUserLockedOut())
{
message.append("Your account has been locked out due
...
}
else
{
message.append("Sorry, the username or password you supplied is
invalid. Please try again.");
}
realm.clearThreadUserLockedOut();
request.setAttribute("loginErrorMessage", message);
super.forwardToErrorPage(request, response, loginConfig);
}
The actual error page, which is a jsp page, has on it the following HTML
> It makes me wonder what other odd things you are doing in
> your Realm
> (or anywhere else for that matter).
>
> - -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/
>
> iEYEARECAAYFAk8d4moACgkQ9CaO5/Lv0PDL2QCeOM9Q4e1FTa/oQv3IuUtBqzQJ
> 5G8AoJo9XrkNoz29zLAcNBeDir7QdYM9
> =Elm7
> -END PGP SIGNATURE-
>
> -
> 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
Re: Unable to access images stored in webapps//WEB-INF/images ?
Tomcat doesn't let you access anything in the META-INF or WEB-INF folders. These folders have config for your system, and may contain passwords (such as META-INF/context.xml which has passwords for the datasources). Besides, people can get into WEB-INF/lib and WEB-INF/classes and web.xml and see your implementation details. --- On Mon, 1/23/12, Alastair Baldwin wrote: > From: Alastair Baldwin > Subject: Unable to access images stored in webapps//WEB-INF/images ? > To: "users@tomcat.apache.org" > Date: Monday, January 23, 2012, 5:21 PM > Dear Users > > Why am I able to access images stored here: > > http://localhost:8080/imageUploader/1234.jpg > > > but not here: > > http://localhost:8080/imageUploader/WEB-INF/images/1234.jpg > > > File permissions are the same > > Any ideas? > > Thanks > > Alastair > > - > 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
not able to access URL in 2nd app in 7.0.23
In my webapps folder there are two folders: ROOT, myapp. ROOT is the default app. In myapp/WEB-INF/web.xml there is MyServlet package.MyServlet 1 MyServlet /folder/action.do When I go to http://host/myapp/folder/action.do in Tomcat 7.0.22 it invokes myapp, MyServlet. Even some versions of Tomcat 6.x did this. But in Tomcat 7.0.23 it generates 404 page not found. Any idea what I can do? I'm gonna check if it works in 7.0.25. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: not able to access URL in 2nd app in 7.0.23
Replies in place --- On Wed, 1/25/12, Pid wrote: > From: Pid > Subject: Re: not able to access URL in 2nd app in 7.0.23 > To: "Tomcat Users List" > Date: Wednesday, January 25, 2012, 12:55 AM > On 25/01/2012 02:49, removeps-c...@yahoo.com > wrote: > > In my webapps folder there are two folders: ROOT, > myapp. ROOT is the default app. > > > > In myapp/WEB-INF/web.xml there is > > > > > > > MyServlet > > > package.MyServlet > > > 1 > > > > > > > MyServlet > > > /folder/action.do > > > > > > When I go to http://host/myapp/folder/action.do in Tomcat 7.0.22 it > invokes myapp, MyServlet. Even some versions of Tomcat > 6.x did this. > > > > But in Tomcat 7.0.23 it generates 404 page not found. > > > > Any idea what I can do? > > What do the log files report, during application startup > and when you > try to access the page? During startup I see INFO: Deploying web application directory /home/myusername/jvm/apache-tomcat-7.0.23/domains/mydomain/myapp When going to the page, no logs are generated. However I put a System.out.println statement in the default servlet of myapp to print the getRequestURI() and find that the following URI is hit "/myapp/404.html". The myapp/WEB-INF/web.xml has 404 /404.html So this means that the myapp servlet is invoked, which is a good thing. But the URL I went to is https://mydomain/myapp/folder/action.do. The servlet that is supposed to handle /folder/action.do is not invoked. Nor should it be invoked. There is an https security constraint in myapp/WEB-INF/web.xml to direct the user to myapp/login.html. This page is generated by the default servlet as well. So I will try two things. First, remove the https to see if it works. Second, change the url-mapping from an exact match like "/myapps/folder/action.do" to "*.action.do" > > p > > > I'm gonna check if it works in 7.0.25. FYI, it does not work in 7.0.25 either. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: not able to access URL in 2nd app in 7.0.23
OK here's what I tried: I removed https. A request through Firefox to
http://localhost:6144/myapp/folder/action.do still gives 404. I overrode doGet
of the servlet class to print whether get/post and the request.getRequestURI
and it is
get /myapp/folder/action.do
This is the same as before. My servlet has code like this
if (uri.equals("/myapp/folder/action.do"))
in the doPost method so it would process this action.
So the problem has to do with https. I put the security-constraint stuff back
in but removed the auth-constraint, so everything is https but requires no
authentication. What gets printed when you go to
https://localhost:6143/myapp/folder/action.do is still
get /myapp/folder/action.do
So the issue is with the auth-constraint.
In my real code, my code makes a POST request to the given URL. I re-ran this
test:
So now it looks like the issue is this:
(a) In 7.0.22 and earlier versions my code made a POST request to
https://localhost:6143/myapp/folder/action.do.
(b) Tomcat made a POST request to the login page
https://localhost:6143/myapp/login.html
(c) My servlet got called, and the doPost method of the servlet got called.
But in 7.0.23 (b) Tomcat is making a GET request to
https://localhost:6143/myapp/login.html
Thus I must move/copy my code in doPost to build login.html into doGet.
This did work.
--- On Wed, 1/25/12, removeps-c...@yahoo.com wrote:
> From: removeps-c...@yahoo.com
> Subject: Re: not able to access URL in 2nd app in 7.0.23
> To: "Tomcat Users List"
> Date: Wednesday, January 25, 2012, 9:10 AM
> Replies in place
>
> --- On Wed, 1/25/12, Pid
> wrote:
>
> > From: Pid
> > Subject: Re: not able to access URL in 2nd app in
> 7.0.23
> > To: "Tomcat Users List"
> > Date: Wednesday, January 25, 2012, 12:55 AM
> > On 25/01/2012 02:49, removeps-c...@yahoo.com
> > wrote:
> > > In my webapps folder there are two folders:
> ROOT,
> > myapp. ROOT is the default app.
> > >
> > > In myapp/WEB-INF/web.xml there is
> > >
> > >
> > >
> >
> MyServlet
> > >
> >
> package.MyServlet
> > >
> >
> 1
> > >
> > >
> > >
> >
> MyServlet
> > >
> >
> /folder/action.do
> > >
> > >
> > > When I go to http://host/myapp/folder/action.do in Tomcat 7.0.22 it
> > invokes myapp, MyServlet. Even some versions of
> Tomcat
> > 6.x did this.
> > >
> > > But in Tomcat 7.0.23 it generates 404 page not
> found.
> > >
> > > Any idea what I can do?
> >
> > What do the log files report, during application
> startup
> > and when you
> > try to access the page?
>
> During startup I see
>
> INFO: Deploying web application directory
> /home/myusername/jvm/apache-tomcat-7.0.23/domains/mydomain/myapp
>
> When going to the page, no logs are generated.
> However I put a System.out.println statement in the default
> servlet of myapp to print the getRequestURI() and find that
> the following URI is hit "/myapp/404.html".
>
> The myapp/WEB-INF/web.xml has
>
>
> 404
> /404.html
>
>
> So this means that the myapp servlet is invoked, which is a
> good thing. But the URL I went to is https://mydomain/myapp/folder/action.do.
>
> The servlet that is supposed to handle /folder/action.do is
> not invoked.
>
> Nor should it be invoked. There is an https security
> constraint in myapp/WEB-INF/web.xml to direct the user to
> myapp/login.html. This page is generated by the
> default servlet as well.
>
> So I will try two things. First, remove the https to
> see if it works. Second, change the url-mapping from
> an exact match like "/myapps/folder/action.do" to
> "*.action.do"
>
> >
> > p
> >
> > > I'm gonna check if it works in 7.0.25.
>
> FYI, it does not work in 7.0.25 either.
>
> -
> 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
Re: not able to access URL in 2nd app in 7.0.23
Yep that was the reason, as I wrote in another email sent just now before I saw this. The reason is that in 7.0.22 Tomcat made a POST request to the login page and my doPost method handled it, but in 7.0.23 it makes a GET request. --- On Wed, 1/25/12, André Warnier wrote: > From: André Warnier > Subject: Re: not able to access URL in 2nd app in 7.0.23 > To: "Tomcat Users List" > Date: Wednesday, January 25, 2012, 9:18 AM > removeps-c...@yahoo.com > wrote: > ... > >>> > >> > /folder/action.do > >>> > >>> > ... > > > > > So I will try two things. First, remove the > https to see if it works. Second, change the > url-mapping from an exact match like > "/myapps/folder/action.do" to "*.action.do" > > > In any case, the URL against which you match should never > include the "webapp name" (or "context name"). It is correct > in the above, but not in your last > remark. > > Other than that, could it be that the login page to which > you re-direct is not being found, and that this is causing > the 404 ? > > > > - > 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
Re: not able to access URL in 2nd app in 7.0.23
> So, you're saying that the method value 'POST' is not
> preserved after
> successful authentication and appears to be converted to a
> 'GET'?
No, what I said is the my original request to https://mydomain/myapp/action.do
is a POST request, and the web.xml says to send me the the login-config page
and this request used to be POST in 7.0.22 and is GET in 7.0.23. After
successful authentication the user must resubmit the original POST request
because this does not happen automatically.
--- On Wed, 1/25/12, Pid wrote:
> From: Pid
> Subject: Re: not able to access URL in 2nd app in 7.0.23
> To: "Tomcat Users List"
> Date: Wednesday, January 25, 2012, 1:24 PM
> On 25/01/2012 18:35, removeps-c...@yahoo.com
> wrote:
> > OK here's what I tried: I removed https. A
> request through Firefox to http://localhost:6144/myapp/folder/action.do still
> gives 404. I overrode doGet of the servlet class to
> print whether get/post and the request.getRequestURI and it
> is
> >
> > get /myapp/folder/action.do
> >
> > This is the same as before. My servlet has code
> like this
> >
> > if
> (uri.equals("/myapp/folder/action.do"))
> >
> > in the doPost method so it would process this action.
> >
> > So the problem has to do with https. I put the
> security-constraint stuff back in but removed the
> auth-constraint, so everything is https but requires no
> authentication. What gets printed when you go to
> https://localhost:6143/myapp/folder/action.do is still
> >
> > get /myapp/folder/action.do
> >
> > So the issue is with the auth-constraint.
> >
> > In my real code, my code makes a POST request to the
> given URL. I re-ran this test:
> >
> > So now it looks like the issue is this:
> >
> > (a) In 7.0.22 and earlier versions my code made a POST
> request to https://localhost:6143/myapp/folder/action.do.
> > (b) Tomcat made a POST request to the login page
> > https://localhost:6143/myapp/login.html
> > (c) My servlet got called, and the doPost method of
> the servlet got called.
> >
> > But in 7.0.23 (b) Tomcat is making a GET request to
> > https://localhost:6143/myapp/login.html
> >
> > Thus I must move/copy my code in doPost to build
> login.html into doGet.
> >
> > This did work.
>
> So, you're saying that the method value 'POST' is not
> preserved after
> successful authentication and appears to be converted to a
> 'GET'?
>
>
> p
>
> > --- On Wed, 1/25/12, removeps-c...@yahoo.com
>
> wrote:
> >
> >> From: removeps-c...@yahoo.com
>
> >> Subject: Re: not able to access URL in 2nd app in
> 7.0.23
> >> To: "Tomcat Users List"
> >> Date: Wednesday, January 25, 2012, 9:10 AM
> >> Replies in place
> >>
> >> --- On Wed, 1/25/12, Pid
> >> wrote:
> >>
> >>> From: Pid
> >>> Subject: Re: not able to access URL in 2nd app
> in
> >> 7.0.23
> >>> To: "Tomcat Users List"
> >>> Date: Wednesday, January 25, 2012, 12:55 AM
> >>> On 25/01/2012 02:49, removeps-c...@yahoo.com
> >>> wrote:
> In my webapps folder there are two
> folders:
> >> ROOT,
> >>> myapp. ROOT is the default app.
>
> In myapp/WEB-INF/web.xml there is
>
>
>
> >>>
> >>
> MyServlet
>
> >>>
> >>
> package.MyServlet
>
> >>>
> >>
> 1
>
>
>
> >>>
> >>
> MyServlet
>
> >>>
> >>
> /folder/action.do
>
>
> When I go to http://host/myapp/folder/action.do in Tomcat 7.0.22 it
> >>> invokes myapp, MyServlet. Even some
> versions of
> >> Tomcat
> >>> 6.x did this.
>
> But in Tomcat 7.0.23 it generates 404 page
> not
> >> found.
>
> Any idea what I can do?
> >>>
> >>> What do the log files report, during
> application
> >> startup
> >>> and when you
> >>> try to access the page?
> >>
> >> During startup I see
> >>
> >> INFO: Deploying web application directory
> >>
> /home/myusername/jvm/apache-tomcat-7.0.23/domains/mydomain/myapp
> >>
> >> When going to the page, no logs are generated.
> >> However I put a System.out.println statement in
> the default
> >> servlet of myapp to print the getRequestURI() and
> find that
> >> the following URI is hit "/myapp/404.html".
> >>
> >> The myapp/WEB-INF/web.xml has
> >>
> >>
> >>
> 404
> >>
> /404.html
> >>
> >>
> >> So this means that the myapp servlet is invoked,
> which is a
> >> good thing. But the URL I went to is
> >> https://mydomain/myapp/folder/action.do.
> >>
> >> The servlet that is supposed to handle
> /folder/action.do is
> >> not invoked.
> >>
> >> Nor should it be invoked. There is an https
> security
> >> constraint in myapp/WEB-INF/web.xml to direct the
> user to
> >> myapp/login.html. This page is generated by
> the
> >> default servlet as well.
> >>
> >> So I will try two things. First, remove the
> https to
> >> see if it works. Second, change the
> url-mapping from
> >> an exact match like "/myapps/folder/action.do" to
> >> "*.action.do"
> >>
> >>>
> >>> p
> >>>
> I'm gonna check if it works in 7.0.25.
> >>
> >> FYI, it
Re: not able to access URL in 2nd app in 7.0.23
> When Tomcat receives an unauthenticated request for a
> protected resource
> it intercepts and saves that request, then forwards to the
> resource
> defined in the login config.
True. Also, I'm not making the request through Firefox. I did that below as
part of my debugging only.
I have a Java application. It calls
HttpsURLConnection.setFollowRedirects(false);
At some point it calls
HttpsURLConnection connection = (HttpsURLConnection) url.openConnection();
where url is "https://localhost:6143/myapp/folder/action.do";. Then there is a
call to
connection.setRequestMethod("POST");
along with the other usual methods for a post request.
T server intercepts this message and internally directs to /login.html. Either
a servlet should build this page or it should exist. However, in 7.0.22 a POST
request is made to this page, whereas in 7.0.23 a GET request is made. Is this
a bug in tomcat, a feature in tomcat, or required by the spec?
Then the login.html page is generated and sent back to the client.
The client will then read this message and verify it is the expected login
page. The client will then send a post request to
https://localhost:6143/myapp/j_security_check providing the username and
password.
At this point the server will authenticate, and if valid, will send 302
(redirect) with the URL as the page that was originally requested.
The Java client should now repeat the original post request.
Hope this is clear.
--- On Wed, 1/25/12, Pid wrote:
> From: Pid
> Subject: Re: not able to access URL in 2nd app in 7.0.23
> To: "Tomcat Users List"
> Date: Wednesday, January 25, 2012, 2:59 PM
> On 25/01/2012 22:03, removeps-c...@yahoo.com
> wrote:
> >> So, you're saying that the method value 'POST' is
> not
> >> preserved after
> >> successful authentication and appears to be
> converted to a
> >> 'GET'?
> >
> > No, what I said is the my original request to
> > https://mydomain/myapp/action.do is a POST request, and
> the web.xml says to send me the the login-config page and
> this request used to be POST in 7.0.22 and is GET in
> 7.0.23. After successful authentication the user must
> resubmit the original POST request because this does not
> happen automatically.
>
> I don't understand, what does "and this request used to be
> POST" mean then?
>
> The login form defines the method used to send the request,
> the browser
> sends it, not Tomcat.
>
> When Tomcat receives an unauthenticated request for a
> protected resource
> it intercepts and saves that request, then forwards to the
> resource
> defined in the login config.
>
> If the login form action is successful, the previous
> request is restored
> and executed. So I asked if the request is not being
> restored properly...
>
> So either you're telling us that there's a bug in Tomcat,
> or you're
> telling us something else and I don't know what that is.
>
> Can you reproduce the error using a clean & simple
> application config?
>
>
> p
>
>
> > --- On Wed, 1/25/12, Pid
> wrote:
> >
> >> From: Pid
> >> Subject: Re: not able to access URL in 2nd app in
> 7.0.23
> >> To: "Tomcat Users List"
> >> Date: Wednesday, January 25, 2012, 1:24 PM
> >> On 25/01/2012 18:35, removeps-c...@yahoo.com
> >> wrote:
> >>> OK here's what I tried: I removed
> https. A
> >> request through Firefox to http://localhost:6144/myapp/folder/action.do
> >> still
> >> gives 404. I overrode doGet of the servlet
> class to
> >> print whether get/post and the
> request.getRequestURI and it
> >> is
> >>>
> >>> get /myapp/folder/action.do
> >>>
> >>> This is the same as before. My servlet
> has code
> >> like this
> >>>
> >>> if
> >> (uri.equals("/myapp/folder/action.do"))
> >>>
> >>> in the doPost method so it would process this
> action.
> >>>
> >>> So the problem has to do with https. I
> put the
> >> security-constraint stuff back in but removed the
> >> auth-constraint, so everything is https but
> requires no
> >> authentication. What gets printed when you
> go to https://localhost:6143/myapp/folder/action.do is still
> >>>
> >>> get /myapp/folder/action.do
> >>>
> >>> So the issue is with the auth-constraint.
> >>>
> >>> In my real code, my code makes a POST request
> to the
> >> given URL. I re-ran this test:
> >>>
> >>> So now it looks like the issue is this:
> >>>
> >>> (a) In 7.0.22 and earlier versions my code
> made a POST
> >> request to https://localhost:6143/myapp/folder/action.do.
> >>> (b) Tomcat made a POST request to the login
> page https://localhost:6143/myapp/login.html
> >>> (c) My servlet got called, and the doPost
> method of
> >> the servlet got called.
> >>>
> >>> But in 7.0.23 (b) Tomcat is making a GET
> request to https://localhost:6143/myapp/login.html
> >>>
> >>> Thus I must move/copy my code in doPost to
> build
> >> login.html into doGet.
> >>>
> >>> This did work.
> >>
> >> So, you're saying that the method value 'POST' is
> not
> >> preserved after
> >> successful authentic
Re: ssl connection between two applications running on tomcat
If the 2nd application is secured by SSL, then the 1st application can send requests to it, just like like it would to any other application. If using self-signed certificates you might need to export the certificate if necessary, import it into a truststore, and use the javax.net.ssl.trustStore property. --- On Thu, 1/26/12, Hemanth Gundlapudi wrote: > From: Hemanth Gundlapudi > Subject: ssl connection between two applications running on tomcat > To: users@tomcat.apache.org > Date: Thursday, January 26, 2012, 6:03 AM > Hi, > > we have an application running on tomcat and that needs to > securely communicate with other application running on > tomcat. can someone please guide me through the steps how to > set up the ssl connections between these two application. > > from first application : > > 1. the request data will be sent through XML. > 2. clients are securely able to communicate with the first > application. > > thanks much in advance for the help. > > Thanks > Hemanth - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
