RE: Problem with security?
From: Gagnon, Joseph M (US SSA) [mailto:[EMAIL PROTECTED] Subject: Problem with security? I have a situation where I want to be able to provide user access to an application by determining the identity of the requesting user, without them having to go through a login procedure. Those seem to be rather contradictory requirements. How do you expect to determine identity without some form of login? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with security?
From: Gagnon, Joseph M (US SSA) I have a situation where I want to be able to provide user access to an application by determining the identity of the requesting user, without them having to go through a login procedure. OK. So what identity can the browser present that you wish to discover? Are all your users on Windows, for example, and you wish to discover their Windows username? On UNIX? The way HTTP works is that your servlet has to refuse access to a resource before it can obtain any information at all about the user at the other end of the connection. So at the very least, you'll have to investigate creating a servlet that requires authentication. You can then have some control over the kinds of authentication you say you'll accept, and therefore whether the user's browser tries to satisfy the request behind the scenes or whether it pops up that ugly dialog box requesting a username and password. If you're on Windows and want the user's Windows authentication, take a look at the NTLM Authentication Filter - see http://jcifs.samba.org/src/docs/ntlmhttpauth.html for details. Note that I've never used this and can't help any further than these pointers. - Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with security?
Look into the ServletRequest interface. That interface, which is extended in HttpServletRequest. You can call the getRemoteAddr(), getRemoteHost(), etc. methods. You receive null in your getRemoteUser because the user hasn't been 'authenticated' yet. On 10 Jun 2005, Gagnon, Joseph M (US SSA) wrote: Hello, I'm new to JSP development (and to dynamic web development as a whole) so please bear with me. I'm investigating using JSP/Java for a project at my workplace. My system (test server, if you will) is a PC running Windows XP Pro and I am using Tomcat 5.5.9. I have a situation where I want to be able to provide user access to an application by determining the identity of the requesting user, without them having to go through a login procedure. Specifically, what I've been trying to do is call the request.getRemoteUser() method to ID the requesting user. When I do so, I keep getting null. After reading in the JSP and Java servlet specifications, I see that this call would return null if the user is not authenticated. Reading further, I get the impression that by default, no authentication is needed to access resources. If a security mechanism is specified in the deployment descriptor (which I take to be my webapps\ROOT\WEB-INF\web.xml file), then authentication would be required. Now, I'm not sure that I understand all the nuances of the terminology (not to mention the technology), but it seems that what I've been trying to do should have worked. The web.xml file indicated above contains only the following (and this is the way it came - I added nothing): ?xml version=3D1.0 encoding=3DISO-8859-1? !-- Copyright 2004 The Apache Software Foundation Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- web-app xmlns=3Dhttp://java.sun.com/xml/ns/j2ee; xmlns:xsi=3Dhttp://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=3Dhttp://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; version=3D2.4 display-nameWelcome to Tomcat/display-name description Welcome to Tomcat /description !-- JSPC servlet mappings start -- servlet servlet-nameorg.apache.jsp.index_jsp/servlet-name servlet-classorg.apache.jsp.index_jsp/servlet-class /servlet servlet-mapping servlet-nameorg.apache.jsp.index_jsp/servlet-name url-pattern/index.jsp/url-pattern /servlet-mapping !-- JSPC servlet mappings end -- /web-app Does anyone have any suggestions as to why this doesn't work -or- any suggestions for an alternate method? Also, in a more general sense, any information regarding good sources of information for learning how to do JSP/Servlet programming (web, books, etc.) would be appreciated. Please keep in mind that I am new at this, so examples of some obscure objective or expert level programming will probably be over my head. Thanks, Joe Gagnon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with security?
I believe I've covered that all in my original message. Read further. -Original Message- From: egan0019 [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 10:10 AM To: Tomcat Users List Subject: Re: Problem with security? Look into the ServletRequest interface. That interface, which is extended in HttpServletRequest. You can call the getRemoteAddr(), getRemoteHost(), etc. methods. You receive null in your getRemoteUser because the user hasn't been 'authenticated' yet. On 10 Jun 2005, Gagnon, Joseph M (US SSA) wrote: Hello, I'm new to JSP development (and to dynamic web development as a whole) so please bear with me. I'm investigating using JSP/Java for a project at my workplace. My system (test server, if you will) is a PC running Windows XP Pro and I am using Tomcat 5.5.9. I have a situation where I want to be able to provide user access to an application by determining the identity of the requesting user, without them having to go through a login procedure. Specifically, what I've been trying to do is call the request.getRemoteUser() method to ID the requesting user. When I do so, I keep getting null. After reading in the JSP and Java servlet specifications, I see that this call would return null if the user is not authenticated. Reading further, I get the impression that by default, no authentication is needed to access resources. If a security mechanism is specified in the deployment descriptor (which I take to be my webapps\ROOT\WEB-INF\web.xml file), then authentication would be required. Now, I'm not sure that I understand all the nuances of the terminology (not to mention the technology), but it seems that what I've been trying to do should have worked. The web.xml file indicated above contains only the following (and this is the way it came - I added nothing): ?xml version=3D1.0 encoding=3DISO-8859-1? !-- Copyright 2004 The Apache Software Foundation Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- web-app xmlns=3Dhttp://java.sun.com/xml/ns/j2ee; xmlns:xsi=3Dhttp://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=3Dhttp://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; version=3D2.4 display-nameWelcome to Tomcat/display-name description Welcome to Tomcat /description !-- JSPC servlet mappings start -- servlet servlet-nameorg.apache.jsp.index_jsp/servlet-name servlet-classorg.apache.jsp.index_jsp/servlet-class /servlet servlet-mapping servlet-nameorg.apache.jsp.index_jsp/servlet-name url-pattern/index.jsp/url-pattern /servlet-mapping !-- JSPC servlet mappings end -- /web-app Does anyone have any suggestions as to why this doesn't work -or- any suggestions for an alternate method? Also, in a more general sense, any information regarding good sources of information for learning how to do JSP/Servlet programming (web, books, etc.) would be appreciated. Please keep in mind that I am new at this, so examples of some obscure objective or expert level programming will probably be over my head. Thanks, Joe Gagnon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with security?
I think you have missed the point that you cannot get user information unless the user authenticates. You don't want to have a user authenticate but you want to get user information. These are mutually exclusive tasks. If the user does not authenticate, you can only get the external IP address of the requestor. In order to get user information, you must have the user authenticate. You might have your users sent to a page that gathers the user ID and then store it in a cookie. You cannot count on the browser sending user information because the logged in user may and often is not the actual user. I don't know how you can call it secure if you don't require a key to open the door. You may be encrypted in your transfer over SSL but if you don't have the user log in, you are not secure. Robert S. Harper Information Access Technology, Inc. -Original Message- From: Gagnon, Joseph M (US SSA) [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 8:43 AM To: Tomcat Users List Subject: RE: Problem with security? I believe I've covered that all in my original message. Read further. -Original Message- From: egan0019 [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 10:10 AM To: Tomcat Users List Subject: Re: Problem with security? Look into the ServletRequest interface. That interface, which is extended in HttpServletRequest. You can call the getRemoteAddr(), getRemoteHost(), etc. methods. You receive null in your getRemoteUser because the user hasn't been 'authenticated' yet. On 10 Jun 2005, Gagnon, Joseph M (US SSA) wrote: Hello, I'm new to JSP development (and to dynamic web development as a whole) so please bear with me. I'm investigating using JSP/Java for a project at my workplace. My system (test server, if you will) is a PC running Windows XP Pro and I am using Tomcat 5.5.9. I have a situation where I want to be able to provide user access to an application by determining the identity of the requesting user, without them having to go through a login procedure. Specifically, what I've been trying to do is call the request.getRemoteUser() method to ID the requesting user. When I do so, I keep getting null. After reading in the JSP and Java servlet specifications, I see that this call would return null if the user is not authenticated. Reading further, I get the impression that by default, no authentication is needed to access [Robert Harper] [snip] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with security?
Did I not say that I'm new to this? I made no mention to whether or not I was trying to make it secure. This is only meant to be used within my company's intranet and my intention was to take the user account and then compare it with a set of registered users in the application's DB. I am beginning to see that at the very least I need to create some kind of mechanism (although I don't understand yet how to go about that, or how many different ways it can be done) to perform user authentication. If anyone can provide information on how to do this (keep in mind I'm new at this), please let me know. -Original Message- From: Robert Harper [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 10:59 AM To: 'Tomcat Users List' Subject: RE: Problem with security? I think you have missed the point that you cannot get user information unless the user authenticates. You don't want to have a user authenticate but you want to get user information. These are mutually exclusive tasks. If the user does not authenticate, you can only get the external IP address of the requestor. In order to get user information, you must have the user authenticate. You might have your users sent to a page that gathers the user ID and then store it in a cookie. You cannot count on the browser sending user information because the logged in user may and often is not the actual user. I don't know how you can call it secure if you don't require a key to open the door. You may be encrypted in your transfer over SSL but if you don't have the user log in, you are not secure. Robert S. Harper Information Access Technology, Inc. -Original Message- From: Gagnon, Joseph M (US SSA) [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 8:43 AM To: Tomcat Users List Subject: RE: Problem with security? I believe I've covered that all in my original message. Read further. -Original Message- From: egan0019 [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 10:10 AM To: Tomcat Users List Subject: Re: Problem with security? Look into the ServletRequest interface. That interface, which is extended in HttpServletRequest. You can call the getRemoteAddr(), getRemoteHost(), etc. methods. You receive null in your getRemoteUser because the user hasn't been 'authenticated' yet. On 10 Jun 2005, Gagnon, Joseph M (US SSA) wrote: Hello, I'm new to JSP development (and to dynamic web development as a whole) so please bear with me. I'm investigating using JSP/Java for a project at my workplace. My system (test server, if you will) is a PC running Windows XP Pro and I am using Tomcat 5.5.9. I have a situation where I want to be able to provide user access to an application by determining the identity of the requesting user, without them having to go through a login procedure. Specifically, what I've been trying to do is call the request.getRemoteUser() method to ID the requesting user. When I do so, I keep getting null. After reading in the JSP and Java servlet specifications, I see that this call would return null if the user is not authenticated. Reading further, I get the impression that by default, no authentication is needed to access [Robert Harper] [snip] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with security?
Try basic authentication. The browser will cache the user name and password and it will only expire when the browse closes. Read in the documents on how to configure the authentication. You might require authentication for all protocols and use BASIC authentication. This will make it easier for the user with a single login and then they can go wherever you allow them and not have to login again until they close the browser. Robert S. Harper Information Access Technology, Inc. -Original Message- From: Gagnon, Joseph M (US SSA) [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 9:19 AM To: Tomcat Users List Subject: RE: Problem with security? Did I not say that I'm new to this? I made no mention to whether or not I was trying to make it secure. This is only meant to be used within my company's intranet and my intention was to take the user account and then compare it with a set of registered users in the application's DB. I am beginning to see that at the very least I need to create some kind of mechanism (although I don't understand yet how to go about that, or how many different ways it can be done) to perform user authentication. If anyone can provide information on how to do this (keep in mind I'm new at this), please let me know. -Original Message- From: Robert Harper [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 10:59 AM To: 'Tomcat Users List' Subject: RE: Problem with security? I think you have missed the point that you cannot get user information unless the user authenticates. You don't want to have a user authenticate but you want to get user information. These are mutually exclusive tasks. If the user does not authenticate, you can only get the external IP address of the requestor. In order to get user information, you must have the user authenticate. You might have your users sent to a page that gathers the user ID and then store it in a cookie. You cannot count on the browser sending user information because the logged in user may and often is not the actual user. I don't know how you can call it secure if you don't require a key to open the door. You may be encrypted in your transfer over SSL but if you don't have the user log in, you are not secure. Robert S. Harper Information Access Technology, Inc. -Original Message- From: Gagnon, Joseph M (US SSA) [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 8:43 AM To: Tomcat Users List Subject: RE: Problem with security? I believe I've covered that all in my original message. Read further. -Original Message- From: egan0019 [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 10:10 AM To: Tomcat Users List Subject: Re: Problem with security? Look into the ServletRequest interface. That interface, which is extended in HttpServletRequest. You can call the getRemoteAddr(), getRemoteHost(), etc. methods. You receive null in your getRemoteUser because the user hasn't been 'authenticated' yet. On 10 Jun 2005, Gagnon, Joseph M (US SSA) wrote: Hello, I'm new to JSP development (and to dynamic web development as a whole) so please bear with me. I'm investigating using JSP/Java for a project at my workplace. My system (test server, if you will) is a PC running Windows XP Pro and I am using Tomcat 5.5.9. I have a situation where I want to be able to provide user access to an application by determining the identity of the requesting user, without them having to go through a login procedure. Specifically, what I've been trying to do is call the request.getRemoteUser() method to ID the requesting user. When I do so, I keep getting null. After reading in the JSP and Java servlet specifications, I see that this call would return null if the user is not authenticated. Reading further, I get the impression that by default, no authentication is needed to access [Robert Harper] [snip] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with security?
Hi Joe, To summarize the point that all of these others folks were making; Tomcat by itself has no way of interrogating the operating system of the connecting machine or noticing through the information that it gets from then browser that the user is a particular person. Tomcat can only tell you for sure about the physical connection (IP, and possibly hostname... either of which may be useful to me, but I'll get there in a minute). I don't have the tomcat source in front of me right now, but I'm pretty sure that the getRemoteUser() method is a typical java 'getter' method; the part of tomcat that manages sessions looks at the incoming cookie and notices that this request is part of an existing, validated session and does essentially 'setRemoteUser()'... nothing automagical about it. So, back to what you *can* do. So, you know their IP/host; you could use this to query a windows domain controller, which would be able to report which real user is logged onto which machine -- I believe that's what Pete's suggestion was as well; seems like there's some potential there. You can just trust the IP address or hostname (if physical access to the computer is strong enough authentication for you... it really shouldn't be though, because names/IPs can be changed). So, bottom line, you're gonna have to put some work in. If you *do* find a solution that works, make sure to report it back to the list so that everyone can benefit. Cheers, Patrick On 6/10/05, Gagnon, Joseph M (US SSA) [EMAIL PROTECTED] wrote: Did I not say that I'm new to this? I made no mention to whether or not I was trying to make it secure. This is only meant to be used within my company's intranet and my intention was to take the user account and then compare it with a set of registered users in the application's DB. I am beginning to see that at the very least I need to create some kind of mechanism (although I don't understand yet how to go about that, or how many different ways it can be done) to perform user authentication. If anyone can provide information on how to do this (keep in mind I'm new at this), please let me know. -Original Message- From: Robert Harper [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 10:59 AM To: 'Tomcat Users List' Subject: RE: Problem with security? I think you have missed the point that you cannot get user information unless the user authenticates. You don't want to have a user authenticate but you want to get user information. These are mutually exclusive tasks. If the user does not authenticate, you can only get the external IP address of the requestor. In order to get user information, you must have the user authenticate. You might have your users sent to a page that gathers the user ID and then store it in a cookie. You cannot count on the browser sending user information because the logged in user may and often is not the actual user. I don't know how you can call it secure if you don't require a key to open the door. You may be encrypted in your transfer over SSL but if you don't have the user log in, you are not secure. Robert S. Harper Information Access Technology, Inc. -Original Message- From: Gagnon, Joseph M (US SSA) [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 8:43 AM To: Tomcat Users List Subject: RE: Problem with security? I believe I've covered that all in my original message. Read further. -Original Message- From: egan0019 [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 10:10 AM To: Tomcat Users List Subject: Re: Problem with security? Look into the ServletRequest interface. That interface, which is extended in HttpServletRequest. You can call the getRemoteAddr(), getRemoteHost(), etc. methods. You receive null in your getRemoteUser because the user hasn't been 'authenticated' yet. On 10 Jun 2005, Gagnon, Joseph M (US SSA) wrote: Hello, I'm new to JSP development (and to dynamic web development as a whole) so please bear with me. I'm investigating using JSP/Java for a project at my workplace. My system (test server, if you will) is a PC running Windows XP Pro and I am using Tomcat 5.5.9. I have a situation where I want to be able to provide user access to an application by determining the identity of the requesting user, without them having to go through a login procedure. Specifically, what I've been trying to do is call the request.getRemoteUser() method to ID the requesting user. When I do so, I keep getting null. After reading in the JSP and Java servlet specifications, I see that this call would return null if the user is not authenticated. Reading further, I get the impression that by default, no authentication is needed to access [Robert Harper] [snip] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
Re: Problem with security?
There are some pretty good resources for getting started on Servlet/JSP stuff; try the O'Reilly books, especially the latest version of their JSP book. I suggest that you need to think of what you are wanting to do in 2 phases: 1. Login 2. Authenticate (using values supplied by login). There are a couple of alternatives if you want to save your user's from having to type in passwords over and over; since I'm kind of bored, here's a brief list: 1. If you're users are on Windows desktops, then NTLM Auth can get the User information from the browser (either IE or Firefox) without the user having to login (see http://jcifs.samba.org/src/docs/ntlmhttpauth.html) 2. If you have then deployed, then you could use client-certificates to authenticate users. 3. You could use a 'remember-me' library (typically uses cookies so that user only has to login once). Gagnon, Joseph M (US SSA) wrote: Did I not say that I'm new to this? I made no mention to whether or not I was trying to make it secure. This is only meant to be used within my company's intranet and my intention was to take the user account and then compare it with a set of registered users in the application's DB. I am beginning to see that at the very least I need to create some kind of mechanism (although I don't understand yet how to go about that, or how many different ways it can be done) to perform user authentication. If anyone can provide information on how to do this (keep in mind I'm new at this), please let me know. -Original Message- From: Robert Harper [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 10:59 AM To: 'Tomcat Users List' Subject: RE: Problem with security? -- Robert r. Sanders Chief Technologist iPOV (334) 821-5412 www.ipov.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with security?
Not if you are using mutually authenticated SSL. On 6/10/05, Caldarale, Charles R [EMAIL PROTECTED] wrote: From: Gagnon, Joseph M (US SSA) [mailto:[EMAIL PROTECTED] Subject: Problem with security? I have a situation where I want to be able to provide user access to an application by determining the identity of the requesting user, without them having to go through a login procedure. Those seem to be rather contradictory requirements. How do you expect to determine identity without some form of login? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with security?
Gagnon, Joseph M (US SSA) wrote: Did I not say that I'm new to this? I made no mention to whether or not I was trying to make it secure. This is only meant to be used within my company's intranet and my intention was to take the user account and then compare it with a set of registered users in the application's DB. I am beginning to see that at the very least I need to create some kind of mechanism (although I don't understand yet how to go about that, or how many different ways it can be done) to perform user authentication. If anyone can provide information on how to do this (keep in mind I'm new at this), please let me know. HttpServletRequest interface gives you remoteUser() method to determine WHO requested the page. How server gets this is another story. Basically, some sort of authentication has to take place. Keep in mind that in production people usually place Apache as a front-end, which can have benefits in your case. There are several mechanisms available for authentication: - HTTP Basic (both TC and Apache can do this) unencrypted user/pass - HTTP Digest (both TC and Apache can do this) MD5 Digest hashing (secure) - HTTPS Client Certificate (both TC and Apache can do this) - HTTP Negotiate (TC cannot do this, Apache needs mod_krb_auth or similar module, IIS can do it) Basic is supported by all browsers, Digest is not so commonly supported (AFAIK), HTTPS is widely supported. Negotiate is intended for MS Active Directory, since it can go with Kerberos V. It requires advanced sys admin skills to setup, but it will give your users the ability to login to ADS and use those credentials for authentication to your application. Nix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem with security manager, plesk and mysql (catalina.policy ignored?)
I see now where my problem can be. If I extract the war file to
directory ${catalina.home}/psa-webapps/mydomain.com/myapplication/
and insert in the policy file
grant codeBase
file:${catalina.home}/psa-webapps/mydomain.com/myapplication/ {
permission java.net.SocketPermission localhost,resolve;
permission java.net.SocketPermission localhost:3306,connect,resolve;
};
I can then connect to the database, so I guess my problem is I'm not
using the proper syntax in the policy file for the .war
I will google for a while :-)
Alfonso.
El sáb, 30-10-2004 a las 00:21, Alfonso Alba García escribió:
Hi everybody,
I have problems when connecting to mysql. I'm getting the following
exception when trying to connect to a mysql database:
(SQLException): java.sql.SQLException: Unable to connect to any hosts
due to exception: java.security.AccessControlException: access denied
(java.net.SocketPermission localhost resolve)
I have read about similar problems in google and tried to modify the
catalina.policy without success.
I deploy applications via a Plesk web interface which loads my .war
file, sets it in /var/tomcat4/psa-wars/mydomain.com/ creates a symlink
to the war file in /var/tomcat4/psa-webapps/mydomain.com/ and makes the
application available via mydomain.com/myapplication.
It works fine except when an application tries to access a mysql
database. I´m getting the exception above, even though I tried the
following lines in catalina.policy without success (found similar
exeptions to this one in google):
grant codeBase
file:${catalina.home}/psa-webapps/mydomain.com/myapplication/- {
permission java.net.SocketPermission localhost,resolve;
permission java.net.SocketPermission
localhost:3306,connect,resolve;
};
grant codeBase
file:${catalina.home}/psa-webapps/mydomain.com/myapplication/WEB-INF/lib/mysql-connector-java-3.0.9-stable-bin.jar
{
permission java.net.SocketPermission localhost,resolve;
permission java.net.SocketPermission
localhost:3306,connect,resolve;
};
I tried both of them one at a time and I restarted tomcat after every
modification made to the catalina.policy
I´m using tomcat 4.1.24 on a redhat linux Enterprise server, with
/mysql-connector-java-3.0.9 and jre 1.4.2.
Tomcat and mysql are in the same server.
The way I´m trying to access the database in a jsp is
conexion =
DriverManager.getConnection(jdbc:mysql://localhost/DATABASE?user=USERpassword=PASSWORD);
I've checked that the database exists, I can connect to the database
from a console as user USER with password PASSWORD.
The application works perfectly well in another server (debian woody
with tomcat 4.0) where it was not necessary to modify the security
policy.
I talked to a friend of mine who also knows something about tomcat and
told me that to access a database in the same server where tomcat is, it
should not be necessary to modify the catalina.policy file.
I have some experience with tomcat but i run out of ideas and things to
try. Any help to open my eyes would be appreciated.
Thanks a lot in advance,
Alfonso
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
RE: problem with security-constraint with Tomcat 5
Hi, Could this be something that changed (or rather, was clarified) in the Servlet Spec between version 2.3 (which Tomcat 4.x implements) and 2.4 (which Tomcat 5.x implements)? ;) Yoav Shapira http://www.yoavshapira.com -Original Message- From: Mercado . Maria [mailto:[EMAIL PROTECTED] Sent: Monday, October 18, 2004 10:08 AM To: [EMAIL PROTECTED] Subject: problem with security-constraint with Tomcat 5 I'm looking into migrating our project from Tomcat 4.1.30 to Tomcat 5.0.28. We're also using Tiles and Struts 1.1. The problem is that Tomcat 5 seems to be confused with a url pattern that works with Tomcat 4. Here's the pertinent parts of web.xml (I get the same results with 2.3 or 2.4 version of web.xml): ... !-- Struts action servlet -- servlet servlet-namestrutsnav/servlet-name servlet-classorg.apache.struts.action.ActionServlet/servlet- class init-param param-nameconfig/param-name param-value/WEB-INF/conf/struts-config.xml/param-value /init-param init-param param-namevalidate/param-name param-valuetrue/param-value /init-param load-on-startup1/load-on-startup /servlet ... servlet-mapping servlet-namestrutsnav/servlet-name url-pattern*.do/url-pattern /servlet-mapping ... !-- JAAS Security Realm config -- security-constraint web-resource-collection web-resource-nameSecure Struts Actions/web-resource-name url-pattern*.sec.do/url-pattern /web-resource-collection auth-constraint role-nameGeneral User/role-name /auth-constraint /security-constraint login-config auth-methodFORM/auth-method form-login-config form-login-page/login.do/form-login-page form-error-page/logininvalid.do/form-error-page /form-login-config /login-config security-role role-nameGeneral User/role-name /security-role ... If I try to access a sec.do Struts action, I just get a blank space in the body of the Tiles layout - I don't get the login form. If I change the url-pattern in web-resource-collection to *.do, then I get the login page. It seems that Tomcat 5 doesn't like two dots in the url pattern. Is this a bug? I also tried to add the following, but it didn't help: servlet-mapping servlet-namestrutsnav/servlet-name url-pattern*.sec.do/url-pattern /servlet-mapping Thanks, Cecile Mercado - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: problem with security-constraint with Tomcat 5
Thanks for the suggestion, Yoav. I looked but I didn't see anything that stated that a url pattern with 2 dots is illegal. - Cecile Mercado -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Monday, October 18, 2004 9:12 AM To: Tomcat Users List Subject: RE: problem with security-constraint with Tomcat 5 Hi, Could this be something that changed (or rather, was clarified) in the Servlet Spec between version 2.3 (which Tomcat 4.x implements) and 2.4 (which Tomcat 5.x implements)? ;) Yoav Shapira http://www.yoavshapira.com -Original Message- From: Mercado . Maria [mailto:[EMAIL PROTECTED] Sent: Monday, October 18, 2004 10:08 AM To: [EMAIL PROTECTED] Subject: problem with security-constraint with Tomcat 5 I'm looking into migrating our project from Tomcat 4.1.30 to Tomcat 5.0.28. We're also using Tiles and Struts 1.1. The problem is that Tomcat 5 seems to be confused with a url pattern that works with Tomcat 4. Here's the pertinent parts of web.xml (I get the same results with 2.3 or 2.4 version of web.xml): ... !-- Struts action servlet -- servlet servlet-namestrutsnav/servlet-name servlet-classorg.apache.struts.action.ActionServlet/servlet- class init-param param-nameconfig/param-name param-value/WEB-INF/conf/struts-config.xml/param-value /init-param init-param param-namevalidate/param-name param-valuetrue/param-value /init-param load-on-startup1/load-on-startup /servlet ... servlet-mapping servlet-namestrutsnav/servlet-name url-pattern*.do/url-pattern /servlet-mapping ... !-- JAAS Security Realm config -- security-constraint web-resource-collection web-resource-nameSecure Struts Actions/web-resource-name url-pattern*.sec.do/url-pattern /web-resource-collection auth-constraint role-nameGeneral User/role-name /auth-constraint /security-constraint login-config auth-methodFORM/auth-method form-login-config form-login-page/login.do/form-login-page form-error-page/logininvalid.do/form-error-page /form-login-config /login-config security-role role-nameGeneral User/role-name /security-role ... If I try to access a sec.do Struts action, I just get a blank space in the body of the Tiles layout - I don't get the login form. If I change the url-pattern in web-resource-collection to *.do, then I get the login page. It seems that Tomcat 5 doesn't like two dots in the url pattern. Is this a bug? I also tried to add the following, but it didn't help: servlet-mapping servlet-namestrutsnav/servlet-name url-pattern*.sec.do/url-pattern /servlet-mapping Thanks, Cecile Mercado - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem with security-constraint with Tomcat 5
On Mon, 18 Oct 2004 10:45:23 -0400, Mercado . Maria [EMAIL PROTECTED] wrote: Thanks for the suggestion, Yoav. I looked but I didn't see anything that stated that a url pattern with 2 dots is illegal. Most systems I am aware of consider that the extension is the last dot. Otherwise, it starts adding complexity. Don't expect a fix (assuming this is indeed a valid issue, which I doubt). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem with security-constraint with Tomcat 5
You didn't look hard enough :) spec-quote version=2.4 section=11.1 An extension is defined as the part of the last segment after the last '.' character. /spec-quote - Original Message - From: Mercado . Maria [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Monday, October 18, 2004 7:45 AM Subject: RE: problem with security-constraint with Tomcat 5 Thanks for the suggestion, Yoav. I looked but I didn't see anything that stated that a url pattern with 2 dots is illegal. - Cecile Mercado -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Monday, October 18, 2004 9:12 AM To: Tomcat Users List Subject: RE: problem with security-constraint with Tomcat 5 Hi, Could this be something that changed (or rather, was clarified) in the Servlet Spec between version 2.3 (which Tomcat 4.x implements) and 2.4 (which Tomcat 5.x implements)? ;) Yoav Shapira http://www.yoavshapira.com -Original Message- From: Mercado . Maria [mailto:[EMAIL PROTECTED] Sent: Monday, October 18, 2004 10:08 AM To: [EMAIL PROTECTED] Subject: problem with security-constraint with Tomcat 5 I'm looking into migrating our project from Tomcat 4.1.30 to Tomcat 5.0.28. We're also using Tiles and Struts 1.1. The problem is that Tomcat 5 seems to be confused with a url pattern that works with Tomcat 4. Here's the pertinent parts of web.xml (I get the same results with 2.3 or 2.4 version of web.xml): ... !-- Struts action servlet -- servlet servlet-namestrutsnav/servlet-name servlet-classorg.apache.struts.action.ActionServlet/servlet- class init-param param-nameconfig/param-name param-value/WEB-INF/conf/struts-config.xml/param-value /init-param init-param param-namevalidate/param-name param-valuetrue/param-value /init-param load-on-startup1/load-on-startup /servlet ... servlet-mapping servlet-namestrutsnav/servlet-name url-pattern*.do/url-pattern /servlet-mapping ... !-- JAAS Security Realm config -- security-constraint web-resource-collection web-resource-nameSecure Struts Actions/web-resource-name url-pattern*.sec.do/url-pattern /web-resource-collection auth-constraint role-nameGeneral User/role-name /auth-constraint /security-constraint login-config auth-methodFORM/auth-method form-login-config form-login-page/login.do/form-login-page form-error-page/logininvalid.do/form-error-page /form-login-config /login-config security-role role-nameGeneral User/role-name /security-role ... If I try to access a sec.do Struts action, I just get a blank space in the body of the Tiles layout - I don't get the login form. If I change the url-pattern in web-resource-collection to *.do, then I get the login page. It seems that Tomcat 5 doesn't like two dots in the url pattern. Is this a bug? I also tried to add the following, but it didn't help: servlet-mapping servlet-namestrutsnav/servlet-name url-pattern*.sec.do/url-pattern /servlet-mapping Thanks, Cecile Mercado - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem with security manager and manager webapp
Jason Keltz wrote:
Hi.
I've been using the manager webapp, but after enabling the security
manager (-security on tomcat startup), the manager doesn't run any longer,
giving this error:
type Exception report
message
description The server encountered an internal error () that prevented it
from fulfilling this request.
exception
javax.servlet.ServletException: Wrapper cannot find servlet class
org.apache.catalina.manager.ManagerServlet or a class it depends on
And in the log file, I see that:
java.security.AccessControlException: access denied
(java.lang.RuntimePermission accessClassInPackage.org.apache.catalina)
That's abug bug on our side. I will take a look latter today. As a
workaround, you can do:
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina;
or remove that package in catalina.properties.
-- Jeanfrancois
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
at
java.security.AccessController.checkPermission(AccessController.java:401)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
at
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1491)
at java.lang.ClassLoader$1.run(ClassLoader.java:313)
at java.security.AccessController.doPrivileged(Native Method)
at java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:311)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:537)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at
org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1677)
at
org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:900)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1350)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1230)
at
org.apache.catalina.core.StandardWrapper$1.run(StandardWrapper.java:962)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:958)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:712)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:187)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:587)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:184)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
---
In the default Catalina.policy file, I see:
// libraries installed in the server directory
grant codeBase file:${catalina.home}/server/- {
permission java.security.AllPermission;
};
Why can I not get the manager app to work with the security manager
enabled?
Thanks,
Jason Keltz
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem with security manager and manager webapp
Hi Jeanfrancois,
I'm not sure now if it's a bug or not. I realized that the problem is
that the code in catalina.policy to allow access refers to
${catalina.home}:
// These permissions apply to the container's core code, plus any additional
// libraries installed in the server directory
grant codeBase file:${catalina.home}/server/- {
permission java.security.AllPermission;
};
I had copied the server directory to CATALINA_BASE to get the manager
app working a while ago. The default context for the manager app refers
to ../server, which, of course wouldn't otherwise exist in CATALINA_BASE
unless copied. When the conf directory along with
Catalina/localhost/manager.xml was copied to CATALINA_BASE, the manager
app couldn't be found.
I've tried these two things and they both work:
1) Change ${catalina.home}/server to ${catalina.base}/server
2) Get rid of the server directory in CATALINA_BASE, and change
the context descriptor for the manager app in the CATALINA_BASE
directory to refer to the full path to the manager in CATALINA_HOME. Now,
the existing security policy works.
Jason.
On Tue, 16 Mar 2004, Jeanfrancois Arcand wrote:
Jason Keltz wrote:
Hi.
I've been using the manager webapp, but after enabling the security
manager (-security on tomcat startup), the manager doesn't run any longer,
giving this error:
type Exception report
message
description The server encountered an internal error () that prevented it
from fulfilling this request.
exception
javax.servlet.ServletException: Wrapper cannot find servlet class
org.apache.catalina.manager.ManagerServlet or a class it depends on
And in the log file, I see that:
java.security.AccessControlException: access denied
(java.lang.RuntimePermission accessClassInPackage.org.apache.catalina)
That's abug bug on our side. I will take a look latter today. As a
workaround, you can do:
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina;
or remove that package in catalina.properties.
-- Jeanfrancois
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
at
java.security.AccessController.checkPermission(AccessController.java:401)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
at
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1491)
at java.lang.ClassLoader$1.run(ClassLoader.java:313)
at java.security.AccessController.doPrivileged(Native Method)
at java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:311)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:537)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at
org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1677)
at
org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:900)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1350)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1230)
at
org.apache.catalina.core.StandardWrapper$1.run(StandardWrapper.java:962)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:958)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:712)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:187)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:587)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:184)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
---
In the default Catalina.policy file, I see:
Re: problem with security manager and manager webapp
Jason Keltz wrote:
Hi Jeanfrancois,
I'm not sure now if it's a bug or not. I realized that the problem is
that the code in catalina.policy to allow access refers to
${catalina.home}:
// These permissions apply to the container's core code, plus any additional
// libraries installed in the server directory
grant codeBase file:${catalina.home}/server/- {
permission java.security.AllPermission;
};
I had copied the server directory to CATALINA_BASE to get the manager
app working a while ago. The default context for the manager app refers
to ../server, which, of course wouldn't otherwise exist in CATALINA_BASE
unless copied. When the conf directory along with
Catalina/localhost/manager.xml was copied to CATALINA_BASE, the manager
app couldn't be found.
I've tried these two things and they both work:
1) Change ${catalina.home}/server to ${catalina.base}/server
2) Get rid of the server directory in CATALINA_BASE, and change
the context descriptor for the manager app in the CATALINA_BASE
directory to refer to the full path to the manager in CATALINA_HOME. Now,
the existing security policy works.
Yes, except it is not supposed to work like that. I will try to fix it
tonigh or tomorrow.
Thanks
-- Jeanfrancois
Jason.
On Tue, 16 Mar 2004, Jeanfrancois Arcand wrote:
Jason Keltz wrote:
Hi.
I've been using the manager webapp, but after enabling the security
manager (-security on tomcat startup), the manager doesn't run any longer,
giving this error:
type Exception report
message
description The server encountered an internal error () that prevented it
from fulfilling this request.
exception
javax.servlet.ServletException: Wrapper cannot find servlet class
org.apache.catalina.manager.ManagerServlet or a class it depends on
And in the log file, I see that:
java.security.AccessControlException: access denied
(java.lang.RuntimePermission accessClassInPackage.org.apache.catalina)
That's abug bug on our side. I will take a look latter today. As a
workaround, you can do:
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina;
or remove that package in catalina.properties.
-- Jeanfrancois
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
at
java.security.AccessController.checkPermission(AccessController.java:401)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
at
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1491)
at java.lang.ClassLoader$1.run(ClassLoader.java:313)
at java.security.AccessController.doPrivileged(Native Method)
at java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:311)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:537)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at
org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1677)
at
org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:900)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1350)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1230)
at
org.apache.catalina.core.StandardWrapper$1.run(StandardWrapper.java:962)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:958)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:712)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:187)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:587)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:184)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
---
In the default Catalina.policy file,
