Re: Just say no to JSP Re: [Fwd: Tomcat may reveal scriptsource code by URL trickery]
Hi Brad!
Brad Cox wrote:
I should point out at the outset that this isn't to assign blame but
to point out a problem... namely, the complexity that developers must
deal with to get a working infrastructure in place. My application
uses Apache, JServ, Java, and the servlet engine from Tomcat. Period.
No taglibs, no JSP, no XML, nothing. Yet it took a whole week to get
even this on the air, even though I've been through the tomcat
configuration process dozens of time by now and had working config
files to start with.
I'm about to answer in Jon's favorite manner (hope you don't mind, Jon):
Ok, it seems to be a problem. Why don't you fix it?
Next problem was various JServ failures, none clearly explained by
the errors, and none explaining what what was wrong and how to
correct it in the config files. Then most of the week worrying about
why Tomcat wasn't recognizing my servlet context.
Would adding a 'try{} catch() {}' help solve your problem?
I've a bunch of ideas for partial solutions but I'll hold off on
those to see whether there's any agreement that there's a problem
here.
Then, turn those ideas into patches and send them along. No need for
agreement, just an itch to scratch.
I don't want to play the wise guy here, it's just that (at last) the
meaning of voluntary work has entered my stubborn head. As in those old
jokes about screwing a bulb: when there's 100 users complaining about a
problem, there's 10 people talking about how to correct it, and one that
actually does something. The volunteer is the 1 in 111 that screws the
bulb.
For me, Tomcat has worked perfectly (esp. v3.3), and so I cannot justify
my working on it. But, as a consequence, I don't either complain about
the product -- in fact, it's got my highest praises.
Un saludo,
Alex.
RE: [Fwd: Tomcat may reveal script source code by URL trickery]
I tried XSLT (... I really tried!!!) FreeMarker, WebMacro and Velocity. I stay with Velocity. (Life and templates sure can be simpler than XSLT.) Have fun, Paulo Gaspar -Original Message- From: Daniel Lopez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 04, 2001 19:05 You're right! That's another reason to use a model 2 based approach but, of course, JSP still allows you to shoot you on your foot if you are fool enough to do so. That's one of the reasons we chose a model 2 based approach with XML-XSLT for the interface creation, no JSP involved: no feet in danger ;). just my 2c, Dan Jon Stevens wrote: I know that these are just minor bugs in Tomcat (and other servlet containers as well), but man, this is getting ridiculous. This is clearly yet another reason to not use JSP. Especially when you have sites like this: http://www.devshed.com/Server_Side/Jserv/JSP5/page3.html Actually *encouraging* people to put their usernames and passwords into their JSP files. The term "Gross negligence" comes to mind. -jon ...snip for brevity's sake
RE: Just say no to JSP Re: [Fwd: Tomcat may reveal scriptsource code by URL trickery]
I sure had my "little" flames with Jon, but that is a very important thing I learned from him. I agree that the problem is there - not enough error info - and I had my share of such problems, but this is open source, so, you can fix it. OTOH, some developers can still learn a bit from this kind of feedback and pay a bit more of attention to providing good debug info. Have fun, Paulo Gaspar -Original Message- From: Alex Fernandez [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 05, 2001 10:03 Hi Brad! ... I'm about to answer in Jon's favorite manner (hope you don't mind, Jon): Ok, it seems to be a problem. Why don't you fix it? ... Un saludo, Alex.
mod_jk in a cluster
Hi, we want to use tomcat 3.2.1 in a cluster-environment. This is not a request that someone else should code something. I think I have a solution, but may be others are interested in it too. We have, lets say three cluster-computer (server) and one simple load-balancer. The load-balancer doesn't look in the Packets and doesn't know something about Sessions etc. The server are running with apache + tomcat. apache with mod_jk. The following things could happen: - a request arrives at a server without a session = it should be routed to tomcat on this server - a request with a session on another server arrives = should be routed to the other server - a request with a session on this server arrives = should be routed to this server - a request with a session on a server which is down arrives = use another server and send him the request. The session is not present there and our application handles this Is there a way to get this with existing modules? My solution plays around with mod_jk as follows: The easiest way is to switch off load-balancing and recovering with an additional property in the config. But I could understand if someone says this should be a new module. But it could work with mod_jk. For this I use the lb_worker which controls three ajp13-worker on every server. The ajp13-worker are connected to the three tomcats. Now I have two possibilities: - set the lb_value of the worker for the local tomcat to 1 and 1 for the other workers, then switch off load-balancing by setting lb_factor to 0.0. This should give an error because of the validate-function, but it could be fixed with a small patch. - setting the lb_value for the worker which is connected to tomcat on the same server to -1 and 1 for the others and the lb_factor to a negative value. Both solutions are incorrect if one of the tomcats goes down, because of the recovering. So I come to the first idea, to use an additional flag. If it works here, are there interests in a diff of mod_jk? Bernd -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED]
Re: Just say no to JSP Re: [Fwd: Tomcat may reveal script source code by URL trickery]
I do have all the latest jar files from SUNW, and jakarta-apache. So I don't know what the problems could be. My only complaints would be not enough debug tools around to be able to single step through new code when you are having problems, but I consider that minor at this point, given where the tomcat development cycle is. I've investigated a LOT of reported Tomcat "bugs" where I work that turned out to be garden-variety bugs in the application (apps not dealing correctly with bad data, apps exiting the JVM because something unexpected happened, etc.). The only issue we've found that didn't appear to be an application bug was one where CPU usage trended to 100% over the span of an hour or so. This was on Tomcat 3.2.1/Solaris ?/JDK 1.2.?. The problem vanished when we switched the environment to JDK 1.3. Given that, we never did take the time to figure out the exact problem. Anyhow, the jdb debugger that is included with jdk 1.3 works pretty well for debugging servlet/JSP code when nothing else is available. The command interface takes a few minutes to understand, but it does get the job done. And of course, to debug JSP code, you really have to go after the generated servlet. It's not pretty, but it does work. During development, a lot of people around here use JBuilder to develop/debug JSP and servlet code. It works well for us.
LXR view of tomcat src?
Is there anyone that maintain an LXR (or cvsweb) view of the tomcat development source, or current beta3 source somewhere? -- - Torgeir
jasper bug
org/apache/jasper/runtime/JspRuntimeLibrary.java
in the method: introspecthelper
This is a fix for the bug in handling jsp:setProperty for text fields (as posted in
previous bug reports such as http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1207)
where set method of property is not invoked for blank text fields.
The fix is simply to add another condition in the if statement that checks for a
null or blank value. The method should only return on a blank value if the type of
the property is something other than java.lang.String. That is, for a property of
type java.lang.String, the method should invoke the set method for that property
even if the value is blank.
Here is the unified diff, with the original version first:
diff -ubB /tmp/saved/JspRuntimeLibrary.java
/dev/main/jetty/src/org/apache/jasper/runtime/JspRuntimeLibrary.java
--- /tmp/saved/JspRuntimeLibrary.java Thu Apr 05 10:12:32 2001
+++ /dev/main/jetty/src/org/apache/jasper/runtime/JspRuntimeLibrary.javaThu
Apr 05 10:17:18 2001
@@ -194,7 +194,7 @@
createTypedArray (bean, method, values, t);
}
} else {
- if(value == null || (param != null value.equals(""))) return;
+ if(value == null || (param != null value.equals("")
!type.getName().equals( "java.lang.String" ))) return;
Object oval = convert(value, type);
if ( oval != null )
method.invoke(bean, new Object[] { oval });
RE: TC3.2.x and security problems
Here's an update. I've installed JDK1.3.0 and JDK1.3.1-beta and tested the following URLs. All the tests were run on Win2000 using Tomcat 3.2.2b2. The only difference between these runs was the value of the JAVA_HOME environment variable. The security problems I could duplicate *only* occurred when using JDK1.3.x. They *never* happened with JDK1.2.2. I was able to duplicate problems (directory listing and file contents) for URLs using sequences of /%252e%252e to 'escape' from the web application directory. None of the /%2e%2e attacks worked. I would appreciate it if others could try these URLs on other platforms to see if their results vary. I'm going to investigate the JDK1.3 issues on Win2000. GET /examples/jsp/num/numguess.jsp%00 JDK1.2.2 -- 404 JDK1.3.0 -- 404 JDK1.3.1 -- 404 GET /%252e%252e/%252e%252e/%00.jsp JDK1.2.2 -- 404 JDK1.3.0 -- Directory listing JDK1.3.1 -- Directory listing GET /examples/jsp/num/numguess.js%2570 JDK1.2.2 -- 404 JDK1.3.0 -- 404 JDK1.3.1 -- 404 GET /%2e%2e/%2e%2e/%00.jsp JDK1.2.2 -- 404 JDK1.3.0 -- 404 JDK1.3.1 -- 404 GET /%2e%2e/%2e%2e%5cLICENSE/%00.jsp JDK1.2.2 -- 404 JDK1.3.0 -- 404 JDK1.3.1 -- 404 GET /%252e%252e/%252e%252e%5cLICENSE/%00.jsp JDK1.2.2 -- 404 JDK1.3.0 -- File contents JDK1.3.1 -- File contents
[PATCH Suggestion] Tomcat 3.2.x adapter in load balancing using URL
Hi,
The load balancer worker fail to handle load balancing if the
application use sticky session managed by URL.
The load balancer look for a the parameter "jsessionid" in the URL, and
then can find the worker to contact for the request.
First, the JK_PATH_SESSION_IDENTIFIER in jk_global.h is set to
";jsessionid", but this should be set to "jsessionid".
In jk_lb_worker.c, the function "get_path_param" should return a the
parameter with a given name, but this function look in the URI
(jk_ws_service_t-req_uri), and not in the parameters
(jk_ws_service_t-query_string).
So this function always return NULL.
So here is a suggestion for the "get_path_param" function :
static char *get_path_param(jk_ws_service_t *s,
const char *name,
jk_logger_t *l)
{
char *id_start = NULL;
if(s-query_string) {
for(id_start = strstr(s-query_string, name) ;
id_start ;
id_start = strstr(id_start + 1, name)) {
if('=' == id_start[strlen(name)]) {
/*
* Session path-cookie was found, get
it's value
*/
id_start += (1 + strlen(name));
if(strlen(id_start)) {
char *id_end;
id_start =
jk_pool_strdup(s-pool, id_start);
/*
* The query string is not part
of req_uri, however
* to be on the safe side lets
remove the trailing query
* string if appended...
*/
if(id_end = strchr(id_start,
'?')) {
*id_end = '\0';
}
return id_start;
}
}
}
}
return NULL;
}
and the JK_PATH_SESSION_IDENTIFIER must be change to "jsessionid" in
jk_global.h.
With those two changes, it works fine. I test it on Windows 2000 with
iis and Tomcat 3.2.1.
regards
Benoit.
RE: jasper bug
Hi,
Thanks for the patch. But unfortunately, this would make jasper
non-spec compliant. The JSP 1.1 spec in section 2.13.2.1 states
that for the use of propertyName="*":
If a parameter has a value of "", the corresponding property
is not modified.
No exception is mentioned for properties set with type String.
I have also resolved bug 1207 as invalid for the same reason.
Cheers,
Larry
-Original Message-
From: Samuel Niles Peretz [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 05, 2001 10:22 AM
To: [EMAIL PROTECTED]
Subject: jasper bug
org/apache/jasper/runtime/JspRuntimeLibrary.java
in the method: introspecthelper
This is a fix for the bug in handling jsp:setProperty for
text fields (as posted in
previous bug reports such as
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1207)
where set method of property is not invoked for blank text fields.
The fix is simply to add another condition in the if
statement that checks for a
null or blank value. The method should only return on a
blank value if the type of
the property is something other than java.lang.String. That
is, for a property of
type java.lang.String, the method should invoke the set
method for that property
even if the value is blank.
Here is the unified diff, with the original version first:
diff -ubB /tmp/saved/JspRuntimeLibrary.java
/dev/main/jetty/src/org/apache/jasper/runtime/JspRuntimeLibrary.java
--- /tmp/saved/JspRuntimeLibrary.java Thu Apr 05 10:12:32 2001
+++
/dev/main/jetty/src/org/apache/jasper/runtime/JspRuntimeLibrar
y.javaThu
Apr 05 10:17:18 2001
@@ -194,7 +194,7 @@
createTypedArray (bean, method, values, t);
}
} else {
- if(value == null || (param != null
value.equals(""))) return;
+ if(value == null || (param != null
value.equals("")
!type.getName().equals( "java.lang.String" ))) return;
Object oval = convert(value, type);
if ( oval != null )
method.invoke(bean, new Object[] { oval });
one file at a time.
I am developing a web page, which will have the link to copyright protected reference materials. I will be using some web-builder tool such as front-page or dream-weaver. The problem faced is the implementation of access control over the refrence material, which is nothing but pdf files. the control should be such that when a user is aacessing, viewing or using a file no other user user should be able to view or access that file i.e. one user, one file at a time. I am in a fix, what to do? should i use the singlethreadmodel interface of servlet or jsp to develop this control, but i am afraid that i will end up in writing 300 servlet classes each crresponding to one pdf file. Any suggestions addressing this problem? Thanking you. Pushpendra Singh.
Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]
--- Nick Bauman [EMAIL PROTECTED] wrote: Read Jon's article about the problems of JSP. http://jakarta.apache.org/velocity/ymtd/ymtd.html I read it and it made me rethink a lot of assumptions I had made about JSP. Without getting into the larger debate - actually agree with many of the article's issues - the following paragraph, though, bothers me: --- There are some fundamental issues that are being dealt with in the generated .jsp template. The first one is the class name. What happens is that the engine needs to produce a name that is unique in order to work around class loader issues that might crop up. Therefore, each and every time one modifies a .jsp page, a new file is created on disk in the temporary directory. Unfortunately, this directory ends up growing in size until someone decides to clean it up. The engine could probably do this for you, except then it might make the mistake of actually removing the wrong file. [from http://jakarta.apache.org/velocity/ymtd/ymtd-generation.html ] The above paragraph describes a 'fundamental issue' that has absolutely nothing to do with the Java Server Pages specification and, rather, entirely to do with a particular implementation of the specification. As such, it has no legitimate argumentative value here and seems quite gratuitous. The statement 'The engine could probably do this for you, except then it might make the mistake of actually REMOVING THE WRONG FILE.' (emphasis mine) is a blatant appeal to fear. I highly doubt this was intentional on Jon's part, but that is what it is. Jon - you do not need to do this to support your arguments. Please retract this paragraph from the essay when convenient. Also, in your discussion on error handling, the fact that JSP's only catch Exceptions will be changed in JSP 1.2 spec to include all Throwables. And further, it could be argued that many of your complaints about poor compilation error messages are again, an artifact of implementation (maturity), rather than specification. However, I (were I to argue such) would have to concede that in that case the specification is possibly incomplete (failure to address standardizing the compile/debug part of the cycle). All-in-all, though, I won't argue with the basic point: Java Server Pages do NOT provide a tool-level separation between View and Control. And I wish others would stop pretending that it did. With my team, I try to stress that JSPs can (and actually should) be used to implement both View and Control aspects of MVC and to address this we have adopted (hopefully) strong standards for how we do JSP development. There is more to it, but basically we conceptually separate JSPs into four basic roles: presentation control, presentation content, request filtering and pure business. We then enforce naming conventions and required strategies to development of JSPs in these roles. I don't claim this is ideal, but it seems to work very well. I am interested in template solutions like Velocity, though and intend to look at it closely. Cheers, Dr. Mel Martinez [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]
--- Nick Bauman [EMAIL PROTECTED] wrote: Read Jon's article about the problems of JSP. http://jakarta.apache.org/velocity/ymtd/ymtd.html I read it and it made me rethink a lot of assumptions I had made about JSP. Without getting into the larger debate - actually agree with many of the article's issues - the following paragraph, though, bothers me: --- There are some fundamental issues that are being dealt with in the generated .jsp template. The first one is the class name. What happens is that the engine needs to produce a name that is unique in order to work around class loader issues that might crop up. Therefore, each and every time one modifies a .jsp page, a new file is created on disk in the temporary directory. Unfortunately, this directory ends up growing in size until someone decides to clean it up. The engine could probably do this for you, except then it might make the mistake of actually removing the wrong file. [from http://jakarta.apache.org/velocity/ymtd/ymtd-generation.html ] The above paragraph describes a 'fundamental issue' that has absolutely nothing to do with the Java Server Pages specification and, rather, entirely to do with a particular implementation of the specification. As such, it has no legitimate argumentative value here and seems quite gratuitous. The statement 'The engine could probably do this for you, except then it might make the mistake of actually REMOVING THE WRONG FILE.' (emphasis mine) is a blatant appeal to fear. I highly doubt this was intentional on Jon's part, but that is what it is. Jon - you do not need to do this to support your arguments. Please retract this paragraph from the essay when convenient. Also, in your discussion on error handling, the fact that JSP's only catch Exceptions will be changed in JSP 1.2 spec to include all Throwables. And further, it could be argued that many of your complaints about poor compilation error messages are again, an artifact of implementation (maturity), rather than specification. However, I (were I to argue such) would have to concede that in that case the specification is possibly incomplete (failure to address standardizing the compile/debug part of the cycle). All-in-all, though, I won't argue with the basic point: Java Server Pages do NOT provide a tool-level separation between View and Control. And I wish others would stop pretending that it did. With my team, I try to stress that JSPs can (and actually should) be used to implement both View and Control aspects of MVC and to address this we have adopted (hopefully) strong standards for how we do JSP development. There is more to it, but basically we conceptually separate JSPs into four basic roles: presentation control, presentation content, request filtering and pure business. We then enforce naming conventions and required strategies to development of JSPs in these roles. I don't claim this is ideal, but it seems to work very well. I am interested in template solutions like Velocity, though and intend to look at it closely. Cheers, Dr. Mel Martinez [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
RE: mod_jk in a cluster
With the exception of failover (case 4 below), I believe that the first three cases can be handled by having your load balancer be "sticky" by client address to any of the app servers (machines running Apache with Tomcat). Thus if your load balancer receives a request from client some.client.net and round robin assigns the request to server B, given servers A, B, and C, then all subsequest requests from some.client.net should be routed to server B. If B ever goes down the session information from some.client.net is lost and the client will have to retry their session. To implement a failover system is highly non-trivial and my understanding is that most application servers (even commercial ones) do not support this. In fact I'm told by several coworkers who worked formerly for BEA and know people there up to and including the B, the E, and the A that WebLogic only recently got failover with session replication right. To make this work you will need a somewhat complicated session replication mechanism between all app servers which is n(n-1) replications (in this case 6) if replication is done between all servers and at best n choose 2 (in this case 3, or an extra session "write through" per request if you prefer) replications if each app server has a single failover server. That can be a lot of network traffic and a lot of new code. If I'm wrong and there's a way to make this work in Tomcat then kudos to all involved and let me know how to do it:)! -Jamey -Original Message- From: bk [mailto:bk]On Behalf Of Bernd Koecke Sent: Thursday, April 05, 2001 4:19 AM To: tomcat-dev Subject: mod_jk in a cluster Hi, we want to use tomcat 3.2.1 in a cluster-environment. This is not a request that someone else should code something. I think I have a solution, but may be others are interested in it too. We have, lets say three cluster-computer (server) and one simple load-balancer. The load-balancer doesn't look in the Packets and doesn't know something about Sessions etc. The server are running with apache + tomcat. apache with mod_jk. The following things could happen: - a request arrives at a server without a session = it should be routed to tomcat on this server - a request with a session on another server arrives = should be routed to the other server - a request with a session on this server arrives = should be routed to this server - a request with a session on a server which is down arrives = use another server and send him the request. The session is not present there and our application handles this Is there a way to get this with existing modules? My solution plays around with mod_jk as follows: The easiest way is to switch off load-balancing and recovering with an additional property in the config. But I could understand if someone says this should be a new module. But it could work with mod_jk. For this I use the lb_worker which controls three ajp13-worker on every server. The ajp13-worker are connected to the three tomcats. Now I have two possibilities: - set the lb_value of the worker for the local tomcat to 1 and 1 for the other workers, then switch off load-balancing by setting lb_factor to 0.0. This should give an error because of the validate-function, but it could be fixed with a small patch. - setting the lb_value for the worker which is connected to tomcat on the same server to -1 and 1 for the others and the lb_factor to a negative value. Both solutions are incorrect if one of the tomcats goes down, because of the recovering. So I come to the first idea, to use an additional flag. If it works here, are there interests in a diff of mod_jk? Bernd -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]
On Thu, 5 Apr 2001, Mel Martinez wrote: The above paragraph describes a 'fundamental issue' that has absolutely nothing to do with the Java Server Pages specification and, rather, entirely to do with a particular implementation of the specification. As And most of the other arguments are in the same category - bad implementation of the spec. So we need to fix it :-) After all that's one of the diferences between the zillion templating systems and jsp - a spec with a wide variety of implementations that improve. I do agree with some of Jon's arguments - the spec is not perfect ( but I don't think HTTP spec is perfect either, or HTML or XSLT or even the servlet spec - and for many of those I could list more serious reasons for not using them and choosing a random alternative :-). Costin
Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal scriptsource code by URL trickery]
Mel, Please do not CC me directly as I'm already on the list. I have filed your changes away for when I do my next revision of the site (there are several other people's comments that I want to integrate as well). I hear you and you made good suggestions. Also, I do have to say that those two nits are fairly minor given that the scope of the entire article is quite large. In other words, there is plenty of other valid reasons there to not use JSP and that those two nits are really minor in the grand scope of things. :-) thanks, -jon
Re: Just say no to JSP Re: [Fwd: Tomcat may reveal scriptsource code by URL trickery]
on 4/4/01 3:55 PM, "Brad Cox" [EMAIL PROTECTED] wrote: Glad that change made it in. DDJ wanted "Just say no to HTML". Arggh. Yucky. I'm so happy to see that more and more people are waking up to the fact that JSP is bad. I'm also happy to see you worry about form validation issues. That is a problem that we are currently solving in Turbine right now. It is called "Intake". :-) I'll try to make some time to check that out. I find it funny that you decided to group Turbine and Velocity and Webmacro into this big statement about (Yet another language) yet you didn't even really check it out first. That is bad journalism IMHO. Sigh. Yet another typo. I really thought we'd caught them all. Those are just the spelling mistakes...there are plenty of other typo's in that article. #1. Confused "Turbine" with "add programming language features to HTML". #2. Confused "WebMacro" and thus Velocity with "add programming language features to HTML". If you spend time with the products, you would see that isn't the case and you might actually retract your statements. You've touched a nerve here. This is the amount of time that gets consumed installing web based infrastructures. What does that have to do with any of the above? In fact, if you really take the time looking at Velocity, you will see that we have included complete documentation (written by a professional tech writer), numerous working examples, demo Velocity applications bundled with both versions of Tomcat all ready to go, etc. Yes, Turbine needs more work on the examples and documentation front, but it isn't a released product yet (we plan on a JavaOne release) and will definitely have much improved documentation and examples before we release. We are also putting a huge amount of effort into creating a Turbine EE system that is a bundle of everything you need to get started. It is called the Turbine Developers Kit (TDK). [rant removed] I'd be grateful to hear them when you get a moment. I'd be grateful if you would take the time to investigate our solutions (ie: Velocity and Turbine) before you bash them or decide that they are not worthy. :-) Maybe your next article can be about how much you like Velocity and/or Turbine. :-) -jon
Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal scriptsource code by URL trickery]
on 4/5/01 10:13 AM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: So we need to fix it :-) After all that's one of the diferences between the zillion templating systems and jsp - a spec with a wide variety of implementations that improve. I do agree with some of Jon's arguments - the spec is not perfect ( but I don't think HTTP spec is perfect either, or HTML or XSLT or even the servlet spec - and for many of those I could list more serious reasons for not using them and choosing a random alternative :-). Costin I would like to hear what is wrong with Velocity's spec: http://jakarta.apache.org/velocity/vtl-reference-guide.html and http://jakarta.apache.org/velocity/user-guide.html http://jakarta.apache.org/velocity/developer-guide.html :-) -jon
Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]
--- Jon Stevens [EMAIL PROTECTED] wrote: Mel, Please do not CC me directly as I'm already on the list. Sorry - artifact of how I started the reply (from browsing the essay). Oops. I have filed your changes away for when I do my next revision of the site (there are several other people's comments that I want to integrate as well). I hear you and you made good suggestions. Also, I do have to say that those two nits are fairly minor given that the scope of the entire article is quite large. In other words, there is plenty of other valid reasons there to not use JSP and that those two nits are really minor in the grand scope of things. :-) Oh yes, I hope I made it clear that I don't think my two little nits in any way invalidate the larger points. I am simply offering them as constructive ways to improve the argument. Cheers, Dr. Mel Martinez [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]
I could be wrong given I don't know the full context, but the code from the article on this page: http://jakarta.apache.org/velocity/ymtd/ymtd-generation.html isn't thead safe, multiple requests coming in on different threads at the same time would cause init() to be called multiple times. -Matthew
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java
remm01/04/05 11:47:52
Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java
Log:
- Path /. wasn't normalized properly (but /./ was). It's treated as a special case.
Revision ChangesPath
1.34 +7 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
Index: DefaultServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- DefaultServlet.java 2001/04/02 21:14:19 1.33
+++ DefaultServlet.java 2001/04/05 18:47:50 1.34
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
1.33 2001/04/02 21:14:19 craigmcc Exp $
- * $Revision: 1.33 $
- * $Date: 2001/04/02 21:14:19 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
1.34 2001/04/05 18:47:50 remm Exp $
+ * $Revision: 1.34 $
+ * $Date: 2001/04/05 18:47:50 $
*
*
*
@@ -122,7 +122,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.33 $ $Date: 2001/04/02 21:14:19 $
+ * @version $Revision: 1.34 $ $Date: 2001/04/05 18:47:50 $
*/
public class DefaultServlet
@@ -877,6 +877,9 @@
if (normalized == null)
return (null);
+
+if (normalized.equals("/."))
+return "/";
// Normalize the slashes and add leading slash if necessary
if (normalized.indexOf('\\') = 0)
Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal scriptsource code by URL trickery]
on 4/5/01 5:35 AM, "Matthew Dornquast" [EMAIL PROTECTED] wrote: I could be wrong given I don't know the full context, but the code from the article on this page: http://jakarta.apache.org/velocity/ymtd/ymtd-generation.html isn't thead safe, multiple requests coming in on different threads at the same time would cause init() to be called multiple times. -Matthew Yup. I think it has already been fixed in Tomcat (along with some other problems...ie: the double locked checking as well), but that is the example that is published in Jason's Servlet book that is coming out soon so I wanted to use that because his book will be going out to hundreds of thousands of people... I'm more concerned with illustrating my point in the essay than pointing out bad generation of code because that is something that can be fairly easily fixed. -jon
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets WebdavServlet.java
remm01/04/05 12:03:09
Modified:catalina/src/share/org/apache/catalina/servlets
WebdavServlet.java
Log:
- Prevent COPY method from manipulating anything in /WEB-INF or /META-INF.
Note : That could only happen when a user had red/write access on the
context.
Revision ChangesPath
1.16 +18 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java
Index: WebdavServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- WebdavServlet.java2001/04/05 18:55:02 1.15
+++ WebdavServlet.java2001/04/05 19:03:08 1.16
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java,v
1.15 2001/04/05 18:55:02 remm Exp $
- * $Revision: 1.15 $
- * $Date: 2001/04/05 18:55:02 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java,v
1.16 2001/04/05 19:03:08 remm Exp $
+ * $Revision: 1.16 $
+ * $Date: 2001/04/05 19:03:08 $
*
*
*
@@ -125,7 +125,7 @@
* are handled by the DefaultServlet.
*
* @author Remy Maucherat
- * @version $Revision: 1.15 $ $Date: 2001/04/05 18:55:02 $
+ * @version $Revision: 1.16 $ $Date: 2001/04/05 19:03:08 $
*/
public class WebdavServlet
@@ -1481,10 +1481,24 @@
}
}
+destinationPath = normalize(destinationPath);
+
if (debug 0)
System.out.println("Dest path :" + destinationPath);
+if ((destinationPath.toUpperCase().startsWith("/WEB-INF")) ||
+(destinationPath.toUpperCase().startsWith("/META-INF"))) {
+resp.sendError(WebdavStatus.SC_FORBIDDEN);
+return false;
+}
+
String path = getRelativePath(req);
+
+if ((path.toUpperCase().startsWith("/WEB-INF")) ||
+(path.toUpperCase().startsWith("/META-INF"))) {
+resp.sendError(WebdavStatus.SC_FORBIDDEN);
+return false;
+}
if (destinationPath.equals(path)) {
resp.sendError(WebdavStatus.SC_FORBIDDEN);
LoadBalancer worker
Hello, I want to enable the load balancer worker on Apache/Tomcat. Even though I have configured the workers.properties file as - worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers=myajp12_1, myajp13_1, myajp12_2, myajp13_2 The load balancer worker is not invoked, for I do see the debug statements for lb worker in mod_jk.log. Could you tell me, what is it that I am doing. What additional configuration do I need to do to enable load balancer. Any help in this regard is appreaciated. -Vikas.
RE: LoadBalancer worker
Hello, I want to enable the load balancer worker on Apache/Tomcat. Even though I have configured the workers.properties file as - worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers=myajp12_1, myajp13_1, myajp12_2, myajp13_2 Don't forget to add loadbalancer to workers list ! The load balancer worker is not invoked, for I do see the debug statements for lb worker in mod_jk.log. Could you tell me, what is it that I am doing. What additional configuration do I need to do to enable load balancer. Any help in this regard is appreaciated. -Vikas.
cvs commit: jakarta-tomcat-4.0/webapps/examples/WEB-INF web.xml
craigmcc01/04/05 12:30:40 Modified:catalina/src/conf web_23.dtd catalina/src/share/org/apache/catalina Context.java catalina/src/share/org/apache/catalina/core StandardContext.java catalina/src/share/org/apache/catalina/startup ContextConfig.java jasper/src/share/org/apache/jasper/resources web_23.dtd webapps/examples/WEB-INF web.xml Added: catalina/src/share/org/apache/catalina/deploy ContextLocalEjb.java Log: Implement the following changes in the web application deployment descriptor DTD, per approval by the JSR-053 Expert Group: * The run-as element now has description and role-name subelements. * The new local-ejb-ref element describes an optional capability that allows a web application to reference a local EJB, if supported by the container. Revision ChangesPath 1.4 +50 -3 jakarta-tomcat-4.0/catalina/src/conf/web_23.dtd Index: web_23.dtd === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/web_23.dtd,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- web_23.dtd2001/03/22 17:19:37 1.3 +++ web_23.dtd2001/04/05 19:30:39 1.4 @@ -6,7 +6,7 @@ !ELEMENT web-app (icon?, display-name?, description?, distributable?, context-param*, filter*, filter-mapping*, listener*, servlet*, servlet-mapping*, session-config?, mime-mapping*, welcome-file-list?, error-page*, taglib*, resource-env-ref*, resource-ref*, security-constraint*, login-config?, security-role*, -env-entry*, ejb-ref*) +env-entry*, ejb-ref*, ejb-local-ref*) !-- Declares a filter in the web application. The filter is mapped to either a servlet or a URL pattern in the filter-mapping element, using the filter-name value to reference. Filters can access the initialization parameters declared in the deployment descriptor at runtime via the FilterConfig interface. @@ -574,11 +574,55 @@ !-- -The run-as element must contain the name of a security role defined for this web application. If the optional run-as element is used for a servlet definition, the security identity of a call to any EJBs from the servlet must be propogated as the security role with the same name. +The ejb-local-ref element is used for the declaration of a reference to +an enterprise bean's local home. The declaration consists of: + - an optional description + - the EJB reference name used in the code of the web component + that's referencing the enterprise bean + - the expected type of the referenced enterprise bean + - the expected local home and local interfaces of the referenced + enterprise bean + - optional ejb-link information, used to specify the referenced + enterprise bean + +Used by web-app +-- + +!ELEMENT ejb-local-ref (description?, ejb-ref-name, ejb-ref-type, + local-home, local, ejb-link?) + +!-- + +The local element contains the fully-qualified name of the +enterprise bean's local interface. + +Used by ejb-local-ref + +-- +!ELEMENT local (#PCDATA) + +!-- + +The local-home element contains the fully-qualified name of the +enterprise bean's local home interface. + +Used by ejb-local-ref +-- +!ELEMENT local-home (#PCDATA) + + + + +!-- +The run-as element, if defined for a servlet, overrides the security identity used to call an EJB +by that servlet in this web application. The role-name is one of the security roles already +defined for this web application. + +Used by: servlet -- +!ELEMENT run-as (description?, role-name) -!ELEMENT run-as (#PCDATA) !-- @@ -664,4 +708,7 @@ !ATTLIST home id ID #IMPLIED !ATTLIST remote id ID #IMPLIED !ATTLIST ejb-link id ID #IMPLIED +!ATTLIST ejb-local-ref id ID #IMPLIED +!ATTLIST local-home id ID #IMPLIED +!ATTLIST local id ID #IMPLIED !ATTLIST run-as id ID #IMPLIED 1.16 +37 -4 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Context.java Index: Context.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Context.java,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- Context.java 2001/02/26 03:49:23 1.15 +++ Context.java 2001/04/05 19:30:39 1.16 @@ -1,7 +1,7 @@ /* - * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Context.java,v 1.15 2001/02/26 03:49:23 glenn Exp $ - * $Revision: 1.15 $ - * $Date: 2001/02/26 03:49:23 $ + * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Context.java,v 1.16 2001/04/05
Re: LoadBalancer worker
Yes it is there. Sorry I did not mention it earlier- worker.list=myajp12_1, myajp12_2, myajp13_1, myajp13_2, loadbalancer GOMEZ Henri wrote: Hello, I want to enable the load balancer worker on Apache/Tomcat. Even though I have configured the workers.properties file as - worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers=myajp12_1, myajp13_1, myajp12_2, myajp13_2 Don't forget to add loadbalancer to workers list ! The load balancer worker is not invoked, for I do see the debug statements for lb worker in mod_jk.log. Could you tell me, what is it that I am doing. What additional configuration do I need to do to enable load balancer. Any help in this regard is appreaciated. -Vikas.
cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.0-B4.txt
craigmcc01/04/05 12:37:01 Added: .RELEASE-NOTES-4.0-B4.txt Log: Start release notes for the next round. Revision ChangesPath 1.1 jakarta-tomcat-4.0/RELEASE-NOTES-4.0-B4.txt Index: RELEASE-NOTES-4.0-B4.txt === Apache Tomcat Version 4.0 Beta 4 = Release Notes = $Id: RELEASE-NOTES-4.0-B4.txt,v 1.1 2001/04/05 19:37:01 craigmcc Exp $ INTRODUCTION: This document describes the changes that have been made in the current beta release of Apache Tomcat, relative to the previous release. Bug reports should be entered at the interim bug reporting system for Jakarta projects at: http://nagoya.apache.org/bugzilla/ Please use project codes "Catalina" and "Jasper" for servlet-related and JSP-related bug reports, respectively. NEW FEATURES: - Catalina New Features: - DTD Changes: Catalina now supports the most recent changes to the web application deployment descriptor approved by the JSR-053 expert group: * The run-as element now has description and role-name subelements. * The new local-ejb-ref element (and associated subelements) supports the optional EJB feature of local EJBs. --- Jasper New Features: --- Webapps New Features: == BUG FIXES AND IMPROVEMENTS: == -- Catalina Bug Fixes: -- Jasper Bug Fixes: - Webapps Bug Fixes: - KNOWN ISSUES IN THIS RELEASE: -- Redeploying From a Web Application Archive: -- If you attempt to undeploy, then redeploy, an application from the same web application archive file URL (where the URL refers to an actual WAR file, not to a directory), the redeploy will fail with error "zip file is closed". There appears to be a problem in the JDK's JarURLConnection class where JAR files are cached, even after they are closed, so that a request for a connection to the same URL returns the previous JarFile object instead of a new one. As a workaround, you should do one of the following: * Change the URL of the web application archive each time you redeploy. * Deploy from an unpacked directory (on the same server) instead of from a WAR file (this is often more convenient in a development environment anyway). -- Tomcat 4.0 and XML Parsers: -- Previous versions of Tomcat 4.0 exposed the XML parser used by Jasper (the JAXP/1.1 reference implementation) to web applications. This is no longer the case, because Jasper loads its parser with a new class loader instead. Keep the following points in mind when considering how to use XML parsers in Tomcat 4.0 and your web applications: * If you wish to make the JAXP/1.1 RI XML parser available to all web applications, simply move the "jaxp.jar" and "crimson.jar" files from the "$TOMCAT_HOME/jasper" directory to the "$TOMCAT_HOME/lib" directory. * If you wish to make another XML parser that is JAXP/1.1-compatible available to all web applications, install that parser into the "$TOMCAT_HOME/lib" directory and remove "jaxp.jar" and "crimson.jar" from the "$TOMCAT_HOME/jasper" directory. It has been reported that Xerces 1.3.1 can be used in this fashion, but 2.x alpha releases can not be. * If you wish to use an XML parser (such as Xerces) in the WEB-INF/lib directory of your web application, this should now be possible, because of the modified JAXP 1.1 parser mentioned below. WARNING: Tomcat 4.0 now ships with a modified version of the JAXP/1.1 (Final) "jaxp.jar" and "crimson.jar" files in the "jasper" subdirectory. The "sealed" attribute has been removed from the manifest file for these two JARs, to avoid "package sealing violation" errors that were caused by them in a JDK 1.3 environment. You MUST NOT replace these files with a different (or later) release of JAXP, unless that later release has had the sealed attribute removed, or you will encounter "package sealing violation" errors when trying to use a different XML parser in a web application.
RE: LoadBalancer worker
did you do ? JkMount /examples/servlet/* loadbalancer JkMount /examples/*.jsp loadbalancer -Original Message- From: Vikas Bansal [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 05, 2001 9:31 PM To: [EMAIL PROTECTED] Subject: Re: LoadBalancer worker Yes it is there. Sorry I did not mention it earlier- worker.list=myajp12_1, myajp12_2, myajp13_1, myajp13_2, loadbalancer GOMEZ Henri wrote: Hello, I want to enable the load balancer worker on Apache/Tomcat. Even though I have configured the workers.properties file as - worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers=myajp12_1, myajp13_1, myajp12_2, myajp13_2 Don't forget to add loadbalancer to workers list ! The load balancer worker is not invoked, for I do see the debug statements for lb worker in mod_jk.log. Could you tell me, what is it that I am doing. What additional configuration do I need to do to enable load balancer. Any help in this regard is appreaciated. -Vikas.
Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script sourcecode by URL trickery]
On Thu, 5 Apr 2001, Jon Stevens wrote: on 4/5/01 10:13 AM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: So we need to fix it :-) After all that's one of the diferences between the zillion templating systems and jsp - a spec with a wide variety of implementations that improve. I do agree with some of Jon's arguments - the spec is not perfect ( but I don't think HTTP spec is perfect either, or HTML or XSLT or even the servlet spec - and for many of those I could list more serious reasons for not using them and choosing a random alternative :-). Costin I would like to hear what is wrong with Velocity's spec: http://jakarta.apache.org/velocity/vtl-reference-guide.html http://jakarta.apache.org/velocity/user-guide.html http://jakarta.apache.org/velocity/developer-guide.html Nothing wrong - yet another fine language, and a very nice implementation. And nothing good either - or I coulnd't find anything revolutionary compared with other programming languages or other fine template-like systems. Arguing what is the best programming language or if interpreted is better than compiled is mostly a waste of time. Some people will prefer to learn VTL, other will prefer to use Java, other will like the XML-like syntax. I think code generation is a good thing, and I prefer using Jsp with Java for quick prototypes and taglibs when possible. Costin
TC 4.0B2 problems when compiled with jikes : Was RE: TC 4.02 error = jikes 1.3 problem
Hi, Did someone (Remy, Craig) has an idea about the problem at startup with a TC 4.0 compiled with jikes 1.3 ? Hi, Just trying a clean rebuilt of TC 4.0b2 and got : Using CLASSPATH: /var/tomcat4/bin/bootstrap.jar:/opt/IBMJava2-13/lib/tools.jar Using CATALINA_HOME: /var/tomcat4 Starting service Tomcat-Standalone Apache Tomcat/4.0-b2 Exception during startup processing java.lang.reflect.InvocationTargetException: java.lang.NoClassDefFoundError: org/apache/naming/factory/Constants at org.apache.naming.ResourceRef.clinit(ResourceRef.java) at org.apache.catalina.core.StandardContext.createNamingContext(St andardContext .java:3447) at org.apache.catalina.core.StandardContext.start(StandardContext. java:3098) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1059) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1059) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:253) at org.apache.catalina.core.StandardService.start(StandardService. java:353) at org.apache.catalina.core.StandardServer.start(StandardServer.java:454) at org.apache.catalina.startup.Catalina.start(Catalina.java:707) at org.apache.catalina.startup.Catalina.execute(Catalina.java:627) at org.apache.catalina.startup.Catalina.process(Catalina.java:177) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:177) Here is my TC4 jars layout : /var/tomcat4/bin/bootstrap.jar /var/tomcat4/common/lib/jndi.jar /var/tomcat4/common/lib/naming.jar /var/tomcat4/common/lib/servlet.jar /var/tomcat4/jasper/jasper-compiler.jar /var/tomcat4/jasper/xerces.jar /var/tomcat4/lib/jasper-runtime.jar /var/tomcat4/lib/namingfactory.jar /var/tomcat4/server/lib/catalina.jar /var/tomcat4/server/lib/jmxri.jar /var/tomcat4/server/lib/regexp.jar /var/tomcat4/server/lib/warp.jar /var/tomcat4/server/lib/xerces.jar I use the original server.xml. I checked and the Constants class which fails to load is in namingfactory.jar. ResourceRef is in naming.jar. So something is wrong with the packaging. Moving namingfactory.jar over to common/lib will probably fix the problem. I can't figure out why my setup is working fine, though ... I moved and it works now. I redo the test, with tc 4.02 binary, with : /var/tomcat4b/bin/bootstrap.jar /var/tomcat4b/common/lib/jndi.jar /var/tomcat4b/common/lib/naming.jar /var/tomcat4b/common/lib/servlet.jar /var/tomcat4b/jasper/jasper-compiler.jar /var/tomcat4b/jasper/jaxp.jar /var/tomcat4b/jasper/crimson.jar /var/tomcat4b/lib/jasper-runtime.jar /var/tomcat4b/lib/namingfactory.jar /var/tomcat4b/server/lib/catalina.jar /var/tomcat4b/server/lib/jmxri.jar /var/tomcat4b/server/lib/jakarta-regexp-1.2.jar /var/tomcat4b/server/lib/warp.jar /var/tomcat4b/server/lib/crimson.jar /var/tomcat4b/server/lib/jaxp.jar It works fine with namingfactory.jar in /var/tomcat4b/lib/. Since I also use jakarta-regexp-1.2.jar, the only difference since to be I used xerces-j instead of jaxp/crimson. I replaced xerces.jar by jaxp.jar/crimson.jar and moved namingfactory.jar back to /var/tomcat4/server/lib/ : /var/tomcat4/bin/bootstrap.jar /var/tomcat4/common/lib/jndi.jar /var/tomcat4/common/lib/naming.jar /var/tomcat4/common/lib/servlet.jar /var/tomcat4/jasper/jasper-compiler.jar /var/tomcat4/jasper/jaxp.jar /var/tomcat4/jasper/crimson.jar /var/tomcat4/lib/jasper-runtime.jar /var/tomcat4/lib/namingfactory.jar /var/tomcat4/server/lib/catalina.jar /var/tomcat4/server/lib/jmxri.jar /var/tomcat4/server/lib/jakarta-regexp-1.2.jar /var/tomcat4/server/lib/warp.jar /var/tomcat4/server/lib/crimson.jar /var/tomcat4/server/lib/jaxp.jar I've got the same problem ! The problem since to be with jikes 1.3. When I used javac from my IBM SDK 1.3 (latest) or jikes 1.2, everything is fine. But when compiled with jikes 1.3, there is something broken
Re: LoadBalancer worker
Great. I did the change you suggested and now it goes thru the loadbalancer worker. But now I have a question- It looks like this way all my ajp12 and ajp13 workers would be load balanced. So it might happen that the request may go to a ajp12/13 worker having low lb_value but that context might not be served by that worker! Because lb_worker will choose the worker with low lb_value. GOMEZ Henri wrote: did you do ? JkMount /examples/servlet/* loadbalancer JkMount /examples/*.jsp loadbalancer -Original Message- From: Vikas Bansal [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 05, 2001 9:31 PM To: [EMAIL PROTECTED] Subject: Re: LoadBalancer worker Yes it is there. Sorry I did not mention it earlier- worker.list=myajp12_1, myajp12_2, myajp13_1, myajp13_2, loadbalancer GOMEZ Henri wrote: Hello, I want to enable the load balancer worker on Apache/Tomcat. Even though I have configured the workers.properties file as - worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers=myajp12_1, myajp13_1, myajp12_2, myajp13_2 Don't forget to add loadbalancer to workers list ! The load balancer worker is not invoked, for I do see the debug statements for lb worker in mod_jk.log. Could you tell me, what is it that I am doing. What additional configuration do I need to do to enable load balancer. Any help in this regard is appreaciated. -Vikas.
Re: JNDI realm for Catalina
- Original Message -
From: "Martin Smith" [EMAIL PROTECTED]
I wonder if it wouldn't be useful to permit a principal or a credential to
be an
attribute in the user's (subject's) own entry, e.g., "creditbalance." (For
some
types of data, I wonder if it may be more efficient to maintain it
"distributed"
in subjects' entries rather than in a possibly very large and dynamic
attribute
list.)
(Perhaps it's obvious, but I'll mention that I'm a bit uncertain about the
distinction and appropriate practical uses of "principals" versus
"credentials".
My understanding - which may not be accurate! - is that in the context of a
web application the "principal" is the entity on behalf of which a request
is processed, while "credentials" are data used to authenticate that
principal - i.e. to establish its identity. But here I think you are talking
about something different from either - i.e. an attribute of an (already
authenticated) user that is used to decide whether to authorise access to
some resource.
In principle you might be able do what you want using the current code by
setting roleSearchBase to where the users entries are held and setting
roleSearchFilter to e.g. ((mail={0})(creditBalance 1)). This assumes
that you can define a "creditBalance" attribute type with a syntax that
makes the inequality work as you expect. In practice I'm not sure this is
necessarily the best approach in this particular case - perhaps it would be
better to retrieve the credit balance and make the comparison explicitly in
the application. Remember also that the role, once established, persists for
the lifetime of the session.
In general though it is certainly possible to define roles implicitly in
terms of attributes held in the user entries, and the design does support
this.
Does this model handle "dynamic" groups, by which I mean a reference to a
method/algorythm/formula computed at runtime, like "member of
ou=myDepartment",
or "person entries with creditbalance 1" ? I understand this can be
achieved by referring to an attribute that stores a URI that includes an
LDAP
query string.
I *think* this is pecular to the Netscape/iPlanet directory servers. It
seems that you store an LDAP search query in the form of an LDAP URL as the
value of a "memberURL" attribute in an entry with object class
"groupOfURLs". What's not clear to me is whether the directory server
automatically executes the query when you ask for the value of such an
attribute. (This would be an extension of the LDAP standard). If so, you
could just define roleSearchFilter to be (groupOfURL={1}), thus matching the
user's DN with the list of computed DNs. But if the directory server just
returns the URL for the client to use, the model as it stands would not
handle it.
In any case, this authenticator is a very exciting contribution.
Thanks! - but note that there are other offerings and this particular one
may not make it into the Catalina code.
John
Persistent connections in tomcat 3.x
Hi I wanted to findout if persistent/keepalive connections are supported by tomcat3.2 /3.3 In my application I am trying to invoke a servlet from a C application through plain sockets In my post header I am specifying Connection : keep-alive parameter, however when I try to reuse the connection and post again using the same socket, I get an error saying the socket has been shutdown. So my question is if Tomcat supports connection keep alive and if there is anyother way to support persistent connections in the above scenario. thanks _ Get your FREE download of MSN Explorer at http://explorer.msn.com
RE: TC3.2.x and security problems
I figured out the difference that's causing the URL to be decoded twice. It seems that as of JDK1.3.0 URLs using the file: scheme are now decoded like http: scheme URLs. For example file:c:\temp\%2e%2e\fubar.txt are interpreted as file:c:\temp\..\fubar.txt. In JDK1.2.2 this would have generated a FileNotFoundException. I think this is a bug, file URLs should not be URL decoded. We'll see if Sun agrees, but in the mean time I'll handle this in Tomcat to prevent file contents from being exposed. -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 05, 2001 10:05 AM To: [EMAIL PROTECTED] Subject: RE: TC3.2.x and security problems Here's an update. I've installed JDK1.3.0 and JDK1.3.1-beta and tested the following URLs. All the tests were run on Win2000 using Tomcat 3.2.2b2. The only difference between these runs was the value of the JAVA_HOME environment variable. The security problems I could duplicate *only* occurred when using JDK1.3.x. They *never* happened with JDK1.2.2. I was able to duplicate problems (directory listing and file contents) for URLs using sequences of /%252e%252e to 'escape' from the web application directory. None of the /%2e%2e attacks worked. I would appreciate it if others could try these URLs on other platforms to see if their results vary. I'm going to investigate the JDK1.3 issues on Win2000. GET /examples/jsp/num/numguess.jsp%00 JDK1.2.2 -- 404 JDK1.3.0 -- 404 JDK1.3.1 -- 404 GET /%252e%252e/%252e%252e/%00.jsp JDK1.2.2 -- 404 JDK1.3.0 -- Directory listing JDK1.3.1 -- Directory listing GET /examples/jsp/num/numguess.js%2570 JDK1.2.2 -- 404 JDK1.3.0 -- 404 JDK1.3.1 -- 404 GET /%2e%2e/%2e%2e/%00.jsp JDK1.2.2 -- 404 JDK1.3.0 -- 404 JDK1.3.1 -- 404 GET /%2e%2e/%2e%2e%5cLICENSE/%00.jsp JDK1.2.2 -- 404 JDK1.3.0 -- 404 JDK1.3.1 -- 404 GET /%252e%252e/%252e%252e%5cLICENSE/%00.jsp JDK1.2.2 -- 404 JDK1.3.0 -- File contents JDK1.3.1 -- File contents
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java WebdavServlet.java
remm01/04/05 19:45:48
Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java WebdavServlet.java
Log:
- Add addiotional check to prevent using DELETE and PUT on URLs
starting with /WEB-INF and /META-INF.
Revision ChangesPath
1.35 +16 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
Index: DefaultServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- DefaultServlet.java 2001/04/05 18:47:50 1.34
+++ DefaultServlet.java 2001/04/06 02:45:48 1.35
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
1.34 2001/04/05 18:47:50 remm Exp $
- * $Revision: 1.34 $
- * $Date: 2001/04/05 18:47:50 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
1.35 2001/04/06 02:45:48 remm Exp $
+ * $Revision: 1.35 $
+ * $Date: 2001/04/06 02:45:48 $
*
*
*
@@ -122,7 +122,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.34 $ $Date: 2001/04/05 18:47:50 $
+ * @version $Revision: 1.35 $ $Date: 2001/04/06 02:45:48 $
*/
public class DefaultServlet
@@ -575,6 +575,12 @@
String path = getRelativePath(req);
+if ((path.toUpperCase().startsWith("/WEB-INF")) ||
+(path.toUpperCase().startsWith("/META-INF"))) {
+resp.sendError(HttpServletResponse.SC_FORBIDDEN);
+return;
+}
+
// Looking for a Content-Range header
if (req.getHeader("Content-Range") != null) {
// No content range header is supported
@@ -636,6 +642,12 @@
}
String path = getRelativePath(req);
+
+if ((path.toUpperCase().startsWith("/WEB-INF")) ||
+(path.toUpperCase().startsWith("/META-INF"))) {
+resp.sendError(HttpServletResponse.SC_FORBIDDEN);
+return;
+}
// Retrieve the Catalina context
// Retrieve the resources
1.17 +10 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java
Index: WebdavServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- WebdavServlet.java2001/04/05 19:03:08 1.16
+++ WebdavServlet.java2001/04/06 02:45:48 1.17
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java,v
1.16 2001/04/05 19:03:08 remm Exp $
- * $Revision: 1.16 $
- * $Date: 2001/04/05 19:03:08 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java,v
1.17 2001/04/06 02:45:48 remm Exp $
+ * $Revision: 1.17 $
+ * $Date: 2001/04/06 02:45:48 $
*
*
*
@@ -125,7 +125,7 @@
* are handled by the DefaultServlet.
*
* @author Remy Maucherat
- * @version $Revision: 1.16 $ $Date: 2001/04/05 19:03:08 $
+ * @version $Revision: 1.17 $ $Date: 2001/04/06 02:45:48 $
*/
public class WebdavServlet
@@ -1685,6 +1685,12 @@
private boolean deleteResource(String path, HttpServletRequest req,
HttpServletResponse resp)
throws ServletException, IOException {
+
+if ((path.toUpperCase().startsWith("/WEB-INF")) ||
+(path.toUpperCase().startsWith("/META-INF"))) {
+resp.sendError(WebdavStatus.SC_FORBIDDEN);
+return false;
+}
String ifHeader = req.getHeader("If");
if (ifHeader == null)
