Re: Tomcat shutdown port and security
Roshan, This assumes ... The user has access to log onto the machine. The user has access to read the server.xml file to find out what the shutdown command. assuming you havn't changed the shutdown command to something less predictable You may wish to set it to something else. Of course if you know a better way ? David NAIK,ROSHAN (HP-Cupertino,ex1To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] ) cc: [EMAIL PROTECTED]Subject: Tomcat shutdown port and security om 05/08/2003 02:14 Please respond to Tomcat Developers List Given that _anybody_ on the local machine could simply telnet to the port and issue a SHUTDOWN command. Isnt the current shutdown mechanism in Tomcat 4 a security issue ? -- Roshan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22096] - reload through manager webapp fails to redeploy classes/jars
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22096.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22096
reload through manager webapp fails to redeploy classes/jars
--- Additional Comments From [EMAIL PROTECTED] 2003-08-05 09:14 ---
Huh,
I look to StandardContext implementation and found to changes between 4.1.24
and 4.1.27
4.1.24
Line 1062
public ServletContext getServletContext() {
...
return (context) ;
}
4.1.27
Line 1062
public ServletContext getServletContext() {
...
return (context.getFacade()) ;
}
other change is at Line 3363:
4.1.27
public synchronized stop() ...
// add listenerStop
listenerStop
}
-- nothing to with current 4.1.x reloading.
I extract the 4.1.24 org.apache.catalina.core.StandardContext and copy to
4.1.27 server/classes.
Jiep, 4.1.27 reloading working as expected. Testet with a hello world directory
deployment.
The first change are a internal security fix, but has current a side effect...
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 4690] - sessions not scoped according to spec section 7.3
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4690. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4690 sessions not scoped according to spec section 7.3 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-08-05 13:26 --- This should now be fixed. The fix will be included in 5.0.7. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22149] New: - Reloading with manager causes application to break
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22149. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22149 Reloading with manager causes application to break Summary: Reloading with manager causes application to break Product: Tomcat 4 Version: 4.1.27 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Webapps:Manager AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Using the HTML Manager, Tomcat 4.1.27 on SuSE Linux (I haven't tested this on any other OS's). When Tomcat first starts up, all the webapps (including /examples, which I've been testing with) start up fine. When I click 'reload' to reload the /examples webapp, the manager claims it is not running (false). When I hit 'Start' I get: FAIL - Application at context path /examples could not be started FAIL - Encountered exception java.lang.IllegalStateException: standardHost.start /examples: LifecycleException: Container StandardContext[/examples] has already been started Which is quite obviously not true, since when I try to access /examples I get HTTP Status 503 - This application is not currently available The only way to bring /examples back is to shutdown.sh then startup.sh. I'm posting this under the manager, although I'm not sure whether the problem lies there or not; I tried moving the manager webapp from 4.1.24 (tomcat_home/server/webapps/manager) into 4.1.27 and had the same problem. Using Sun JDK 1.4.1_03. I've tried this on 3 systems (different versions of SuSE) and all three show the same problem. This problem doesn't exist in Tomcat 4.1.24. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19795] - Request crossing
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19795. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19795 Request crossing [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-08-05 20:58 --- AFAIK, there are no concurrency issues. Please double check that your webapp is threadsafe. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795 j_security_check isn't fed through filters --- Additional Comments From [EMAIL PROTECTED] 2003-08-05 14:50 --- And in which case I have no idea how to implement it, as the filter pipeline ends with a servlet, and there's no servlet matching that URL. Besides, it would make FORM behave differently than the other auth methods, which contradicts its design principles. For extending the machanism, a container extension feature should be used, such as: a custom realm, a custom authenticator, a custom valve inserted in the pipeline. Filters are located at the application level, and as such are not a magic bullet for everything (although they can meet maybe 90% of the needs). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15944] - Compiled JSP page includes default setContentType() Call when not specified in the JSP page.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15944. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15944 Compiled JSP page includes default setContentType() Call when not specified in the JSP page. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-08-05 21:07 --- Invalid per commetns below. (Spec limitation) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: tomcat-5.0.5 cannot access jar resources in WEB-INF/lib but o nly unzipped in WEB-INF/classes
Remy Maucherat wrote: Any update on this ? This is obviously a big problem if the issue is valid, so I'd really appreciate your help. Hi Remy, I set up a test case and it looks like it's a Tomcat-5 problem. The webapp works on Tomcat-4.1, on Tomcat-5.0 the resources within xsd.resources.jar cannot be reached. tested environment: Win2k Prof, SuSE Linux 8.2 Log Win2k: 05.08.2003 18:10:32 org.apache.catalina.core.StandardHostDeployer install INFO: Installing web application at context path /xsd-testcase from URL file://C:/Programs/eclipse/workspace/xsdTestCase/build Wrapped exception java.io.FileNotFoundException: C:\ApacheGroup\jakarta-tomcat-5.0.5\work\Catalina\localhost \xsd-testcase\loader\org\eclipse\xsd\cache\www.w3.org\2001\MagicXMLSchema.xs d (The system cannot find the path specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(Unknown Source) # Log SuSE Linux 8.2 Aug 5, 2003 5:52:47 PM org.apache.catalina.core.StandardHostDeployer install INFO: Installing web application at context path /xsdtestcase from URL file:/home/jan/eclipse/XSDTestcase/build Wrapped exception java.io.FileNotFoundException: /opt/jakarta-tomcat-5.0/work/Catalina/localhost /xsdtestcase/loader/org/eclipse/xsd/cache/www.w3.org/2001/MagicXMLSchema.xsd (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:103) The webapp is here: http://tamino.demozone.softwareag.com/xsdTestCaseWebApp.zip The JavaDoc for the relevant classes is here: Eclipse EMF: http://dev.eclipse.org/viewcvs/indextools.cgi/%7Echeckout%7E/emf-home/docs/j avadoc/index.html Eclipse XSD: http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/xsd-home/docs/javado c/index.html This is how the URI to the xsd resource in xsd.resources.jar is created (from XSDSchemaImpl.java): String baseURL = XSDPlugin.INSTANCE.getBaseURL().toString(); getGlobalResourceSet().getLoadOptions().put(XSD_MAGIC_XML_SCHEMA, XSDConstants.SCHEMA_FOR_SCHEMA_URI_2001); Resource magicSchemaForSchema2001Resource = getGlobalResourceSet().getResource (URI.createURI(baseURL + cache/www.w3.org/2001/MagicXMLSchema.xsd), true); Best regards, Jan
DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795 j_security_check isn't fed through filters --- Additional Comments From [EMAIL PROTECTED] 2003-08-05 14:38 --- FWIW - I also have a request to [EMAIL PROTECTED] for feedback on this. I also prefer to keep this bug as RESOLVED-INVALID unless the spec team decides that tomcat is behaving incorrectly in which case - we'll reopen the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14191] - Cannot acquire MBeanServer reference
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14191. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14191 Cannot acquire MBeanServer reference [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-08-05 20:53 --- Need more information for this to be considered valid. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22099] - out of memory
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22099. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22099 out of memory [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-08-05 21:03 --- please use tomcat-user mailing list to debug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795 j_security_check isn't fed through filters --- Additional Comments From [EMAIL PROTECTED] 2003-08-05 21:13 --- Container extension methods are not a valid way of extending the model because they are not standardardized but are container specific. What is needed is a means of extending security behaviour without being container specific. Filters could provide one means to do this. The standard itself is not clear on the point of whether filters should work with j_security_check. In the long run the real problem is with the standard. The j_security_check mechanism is awkward and does not adequately address a number of needs. Hopefully, someone will come up with something better soon. In the meantime I am hoping that the servlet committee decides that filters should work with j_security_check so that I can write code that will be portable across containers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22154] New: - occurs ClassNotFoundException when webapp reload
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22154. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22154 occurs ClassNotFoundException when webapp reload Summary: occurs ClassNotFoundException when webapp reload Product: Tomcat 4 Version: 4.1.27 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] when i reload (update classes in /WEB-INF/classes) webapp,tomcat throws a ClassNotFoundException so that this webapp cant reload. i discover that these classes that tomcat cant found are webapp's listener class. The same webapp can work fine at tomcat 4.1.24. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Re: Tomcat and LDAP Issues
in line ... Jeff Tulley wrote: With defect 20518 -- It does seem innocent, though if the primary LDAP server is down for an extended period of time, you would constantly be trying it first, then the alternate. But, I'm guessing the performance hit is not huge and the fix seems correct beyond that. (IE, to assume the primary is forever gone is a bad idea and it is better to take the potential performance hit). That was my thoughts too. You closed the bug regarding the userSubtree not working I see. I'm not sure but that there are still issues there, and I'm still investigating. I can get it to work if I add the [Public] object as a trustee to any subcontext that I want searched, but this is by no means a standard thing to do since it opens up your user containers to potential security exploits. Most of the exploits involve social engineering; with public access to the names of the users in the container, you can impersonate a user whose name you see and call up and ask a help desk technician to change their password for you. What I'm not sure about is if there is some other acceptable way to grant browse rights to some other object and then have Tomcat go in as that object. If so, then that would need to be documented if it is not already. If that is not possible, then the userSubtree feature is fairly useless since most directory administrators would not take the security risk to make it work. Also, there are other bugs with this feature like the fact that the first level is not searched for users, ONLY the sublevels are. From another user's comment, it looked like it was invalid and there didn't seem to be a rebuttal. But I had many windows open at the same time and may have gotten it confused with something else. I emailed marek about the CLIENT-CERT problem, still no response. I'm going to look into it and see what the gist of Mario's objections were, and if the patch is good. ok I know nothing about the iPlanet issue (except for what is in the bug report), so that will be great if you have a fix... When pulling the password back - it is SHA1 encrypted. When tomcats digests the browser provided password - it returns the SHA1 in an incompatible manner. (HEX vs BASE64 IIRC) So the solution here will probably be to add a flag on how to perform SHA1 password checks. (Or similar) -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Re: Tomcat and LDAP Issues
From another user's comment, it looked like it was invalid and there didn't seem to be a rebuttal. But I had many windows open at the same time and may have gotten it confused with something else. Yeah, somebody was nitpicking the snippet of server.xml that he had there, where the thing they were nitpicking was really just a typo in the bug report. I have indeed seen this issue and for a while was frustrated with the userSubtree functionality. Like I say, it is a rights issue, and it may have to still be dealt with in some way or another. It might result in a fundamentally different way of doing the search in JNDIRealm than the current code. I don't know, I'll investigate when I get some time. I know nothing about the iPlanet issue (except for what is in the bug report), so that will be great if you have a fix... When pulling the password back - it is SHA1 encrypted. When tomcats digests the browser provided password - it returns the SHA1 in an incompatible manner. (HEX vs BASE64 IIRC) So the solution here will probably be to add a flag on how to perform SHA1 password checks. (Or similar) Oh, I was confusing this with bug #11210, also dealing with Netscape. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: window close session invalidate
That is according to the spec, The session only lives for the time of the application,closing your browser window, means that you are ending your application Filip -Original Message- From: Paul Wallace [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 9:01 PM To: Tomcat Developers List Subject: window close session invalidate Dear all, May someone enlighten me on why my session is being invalidated when I close a browser window? I am doing this in one of two ways - the application close icon on the top right of the window, or a simple: a href=javascript:window.close();CLOSE/a Does anyone have any experience of this? The session is being killed and thus so is my app. I will submit this query to the user list, but thought it appropriate for this list as I am getting the same result from multiple instances of TC on different servers, implying it is not a configuration issue as first suspected. Thanks Paul. - 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]
