DO NOT REPLY [Bug 45051] New: Provide read only access for certain role in Administration webapp
https://issues.apache.org/bugzilla/show_bug.cgi?id=45051 Summary: Provide read only access for certain role in Administration webapp Product: Tomcat 5 Version: 5.5.26 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Webapps:Administration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The current Administration Tool webapp provides functionality to change settings. However, in many cases users are allowed to view Tomcat settings but are not allowed to change them. This tool is an excellent way of providing detailed information, but access is not granted for read only usage because it is not possible to easily configure this. Please allow an 'admin-read-only' kind of role to have access to the Administration Tool in a read only mode. Name of the role is to be decided by development community but 'audit' would cover it sufficiently. Buttons like "Commit Changes", "Save", "Reset", etc. should not appear when a user with this read only role is logged in. Also "* Actions" with the combo box in the upper right corner should not be shown and all the values in the forms should be presented by read only (disabled / unchangeable) 'input types' (preferred over plain text). Implementing this enhancement will lead to more satisfied use of Tomcat, especially in complex and overly protected environments where this read only mode (where normal admin mode is not allowed) enable better access into configuration settings. The same request has been made for the Manager webapp. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45052] New: Provide read only access for certain role in Manager webapp
https://issues.apache.org/bugzilla/show_bug.cgi?id=45052 Summary: Provide read only access for certain role in Manager webapp Product: Tomcat 5 Version: 5.5.26 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Webapps:Manager AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The current Manager webapp provides functionality to change settings. However, in many cases users are allowed to view Tomcat settings but are not allowed to change them. This tool is an excellent way of providing detailed information, but access is not granted for read only usage because it is not possible to easily configure this. Please allow an 'admin-read-only' kind of role to have access to the Manager in a read only mode. Name of the role is to be decided by development community but 'audit' would cover it sufficiently. Actions like "Start", "Stop", "Reload", "Undeploy should not appear when a user with this read only role is logged in. Also the deploy form should not be shown. Implementing this enhancement will lead to more satisfied use of Tomcat, especially in complex and overly protected environments where this read only mode (where normal admin mode is not allowed) enable better access into configuration settings. The same request has been made for the Administration Tool webapp. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Potential problem with COMET & sendfile
On Tue, 2008-05-20 at 15:40 -0700, Alex Barclay wrote: > This works fine in the small. Here's what I'm seeing inside the tomcat > code. I was clued into this by not being able to find my socket (being > kept alive) because all of the pollers were on a "wait" call, rather > than on a "poll" call. No need to write a novel to expose a simple problem. BTW, Comet + sendfile is not tested at all, so it is possible it won't work right. The issue you're seeing is that at the end of sendfile it does a processSocket(state.socket) rather than add back to the poller (which is the normal procedure at the end of processing many other requests). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r658292 - /tomcat/tc6.0.x/trunk/STATUS.txt
On Wed, 2008-05-21 at 00:16 +0100, Mark Thomas wrote: > [EMAIL PROTECTED] wrote: > > * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=42747 > >Use any META-INF/context.xml in a consistent manner and ensure it is > > used on > > @@ -95,4 +92,6 @@ > >-1: remm (would need convincing that this is really well tested, > > otherwise delay to next release) > >markt Exactly what would convince you that this was well tested > > above and > > beyond the local testing that I have done to convince myself > > that > > -this patch does what I want it to. > > \ No newline at end of file > > +this patch does what I want it to. > > + remm I am not sure this was fully tested. For example, the order of > > redeployResources is > > + likely significant, and it is changed in deployDirectory > > \ No newline at end of file > > You'd think the order mattered since someone went to the bother of > specifying a LinkedHashMap but I didn't see anything in checkResources() - > the only place the data is read - that depended on order. Do you see > something I don't? That someone who used a LinkedHashMap was me, and the order should be significant (after checking, some operations are done on the rest of the list, like: for (int j = i + 1; j < resources.length; j++)). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45055] New: Tomcat Application custom load order
https://issues.apache.org/bugzilla/show_bug.cgi?id=45055 Summary: Tomcat Application custom load order Product: Tomcat 5 Version: 5.5.22 Platform: PC OS/Version: Windows XP Status: NEW Severity: enhancement Priority: P3 Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, Tomcat loads all the apps in the webapps folder in ascending order. Currently it seems there is no way to change this load order(eg. desc order or custom order). The problem is, we have 5 applications of which one app exposes webservices. The rest 4 applications depends on the 5th application(which exposes webservice). When tomcat loads the applications, all 4 applications are listening/waiting for 5th app (app name starts with S) to startup. Hence there is a huge delay in starting the tomcat. It takes 15 to 20 minutes to start. If there is an option to change this load order, it will be very helpful for people facing these problems. Thanks, Palani -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r658638 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: remm
Date: Wed May 21 04:49:04 2008
New Revision: 658638
URL: http://svn.apache.org/viewvc?rev=658638&view=rev
Log:
- Votes.
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=658638&r1=658637&r2=658638&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Wed May 21 04:49:04 2008
@@ -52,6 +52,8 @@
so I would think keeping it for the next release would be better)
markt How about making it optional with a system property that can be
used
to restore the current behaviour is an app depends on it?
+ remm Ok with this addition, but I would only vote +0 for inclusion in
this release
+ (this still sounds like a very minor fix)
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=42750
Make parsing of request line more tolerant of multiple SP and/or HT
@@ -63,7 +65,7 @@
regarding tolerant applications. (ie allow multiple SP/HT between
method-url and url-httpVersion). However, it is optional so we
don't
have to support it.
- remm Apparently httpd does that, so I am changing my vote to "ignore
issue"
+ +0: remm Apparently httpd does that, so I am changing my vote to +0
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=42747
Use any META-INF/context.xml in a consistent manner and ensure it is used on
@@ -75,4 +77,27 @@
beyond the local testing that I have done to convince myself that
this patch does what I want it to.
remm I am not sure this was fully tested. For example, the order of
redeployResources is
- likely significant, and it is changed in deployDirectory
\ No newline at end of file
+ likely significant, and it is changed in deployDirectory
+
+* After being done with an asynchronous sendfile, the socket should go to the
poller (if assigned
+ to a worker, it will block).
+Index: java/org/apache/tomcat/util/net/AprEndpoint.java
+===
+--- java/org/apache/tomcat/util/net/AprEndpoint.java (revision 658292)
java/org/apache/tomcat/util/net/AprEndpoint.java (working copy)
+@@ -1787,11 +1787,9 @@
+ // Destroy file descriptor pool, which
should close the file
+ Pool.destroy(state.fdpool);
+ Socket.timeoutSet(state.socket, soTimeout
* 1000);
+-// If all done hand this socket off to a
worker for
++// If all done put the socket back in the
poller for
+ // processing of further requests
+-if (!processSocket(state.socket)) {
+-Socket.destroy(state.socket);
+-}
++getPoller().add(state.socket);
+ } else {
+ // Close the socket since this is
+ // the end of not keep-alive request.
+ +1: remm
+ -1:
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45059] New: http://www.servername.com/WEB-INF./web.xml
https://issues.apache.org/bugzilla/show_bug.cgi?id=45059 Summary: http://www.servername.com/WEB-INF./web.xml Product: Tomcat 5 Version: Unknown Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We are working over a problem in the embedded tomcat server which leading us to security compliance. The Resources defined in the deployment descriptor are been display in the following http://www.servername.com/WEB-INF./web.xml We tried to block the this request, but we are not able to restrict the request to display the xml content of web.xml. I hope someone might have seen similar vunerability to the web server. Please advice on this issues. we are using Apache Tomcat 5.5.9 & 5.5.20 also. We have tried on the context setting and other settings of the server. Thanks in Advance, Srinivas -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45059] http://www.servername.com/WEB-INF./web.xml
https://issues.apache.org/bugzilla/show_bug.cgi?id=45059 Tim Funk <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Tim Funk <[EMAIL PROTECTED]> 2008-05-21 10:00:24 PST --- This is a configuration issue. Please use the tomcat-user list to debug the issue. Odds are one of the following: - Case sensitivity is turned off - Apache httpd's jk directives are not setup correctly. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Potential problem with COMET & sendfile
Remy Maucherat wrote: On Tue, 2008-05-20 at 15:40 -0700, Alex Barclay wrote: This works fine in the small. Here's what I'm seeing inside the tomcat code. I was clued into this by not being able to find my socket (being kept alive) because all of the pollers were on a "wait" call, rather than on a "poll" call. No need to write a novel to expose a simple problem. BTW, Comet + sendfile is not tested at all, so it is possible it won't work right. The issue you're seeing is that at the end of sendfile it does a processSocket(state.socket) rather than add back to the poller (which is the normal procedure at the end of processing many other requests). It's getting tested now ;-) I've found a couple of bugs so far. I'll have patches by the end of the week. In our application we're using this for our main file server, sending files up to 10MB in length, so this is showing up lots of interesting behavior. Alex. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Potential problem with COMET & sendfile
I don't see any use case for Comet+sendfile make sense. but if you do it, you should ... set your sendfile stuff call CometEvent.close() . ie, the event shouldn't be cometized when doing sendfile, it makes zero sense since when the file is sent, the HTTP request is over. Filip Alex Barclay wrote: Remy Maucherat wrote: On Tue, 2008-05-20 at 15:40 -0700, Alex Barclay wrote: This works fine in the small. Here's what I'm seeing inside the tomcat code. I was clued into this by not being able to find my socket (being kept alive) because all of the pollers were on a "wait" call, rather than on a "poll" call. No need to write a novel to expose a simple problem. BTW, Comet + sendfile is not tested at all, so it is possible it won't work right. The issue you're seeing is that at the end of sendfile it does a processSocket(state.socket) rather than add back to the poller (which is the normal procedure at the end of processing many other requests). It's getting tested now ;-) I've found a couple of bugs so far. I'll have patches by the end of the week. In our application we're using this for our main file server, sending files up to 10MB in length, so this is showing up lots of interesting behavior. Alex. - 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: Potential problem with COMET & sendfile
Filip Hanik - Dev Lists wrote: I don't see any use case for Comet+sendfile make sense. but if you do it, you should ... set your sendfile stuff call CometEvent.close() . ie, the event shouldn't be cometized when doing sendfile, it makes zero sense since when the file is sent, the HTTP request is over. You're right. In this case because I'm dealing with the request in the begin event and doing a sendfile the request won't be cometized. The other case is where the verb is a put or a post at which point it will be cometized. Yes I am doing a close on the event, it breaks really horribly if you don't do this. Alex. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Potential problem with COMET & sendfile
Alex Barclay wrote: Filip Hanik - Dev Lists wrote: I don't see any use case for Comet+sendfile make sense. but if you do it, you should ... set your sendfile stuff call CometEvent.close() . ie, the event shouldn't be cometized when doing sendfile, it makes zero sense since when the file is sent, the HTTP request is over. You're right. In this case because I'm dealing with the request in the begin event and doing a sendfile the request won't be cometized. The other case is where the verb is a put or a post at which point it will be cometized. Yes I am doing a close on the event, it breaks really horribly if you don't do this. yes, even then you shouldn't do this using comet, just a regular servlet, there is no reason for doing sendfile using comet, it makes little sense, and I don't think it makes sense for us to support it either Filip Alex. - 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]
