RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Request.java
De: Remy Maucherat [mailto:[EMAIL PROTECTED]] Enviado el: viernes 15 de febrero de 2002 2:53 I don't quite understand, as the patch only add filtering out an empty string, right ? Or did I miss something ? Well the problem is that under a connector ( at least under jk+ajp ) you need to configure the passing of HTTP server auth info to tc or not, with the patch supplied by Jonathan Pierce ( althought it works in most cases ) , you lose this control, it's difficult to assure if a newly installed TC under jk will have auth working or not, and which one will be used ( the HTTP server or TC ). You can have varying behaviours on TC dependending on external configs. 1) if you doesnt care about the HTTPServer auth nor you have cofingured in you own, tc auth will be used. 2) If you have HTTPServer auth working but it's not configured in a way compatible with tc ( Same users in TC and HTTPServer) , you will have failing examples in tc, ever. 3) and so on.. In any case, I just applied the patch as it looked ok to me. If the patch is bad, revert it. It's not bad at all, but makes tc auth under a connector unpredictable.. Sorry for having only words, but i dont have the time to dig in the jtc-ajp-4.0 code right now, but is simply a matter of pass an attribute ( tomcatAuthentication to be backwards compatible with tc3.3 ) used in the connector element in server.xml to that point in code, and check it, in case true simply dont use connector auth and do the reverse if false.. Remy Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Request.java
Quoting myself ( sorry ) the connector element in server.xml to that point in code, and check it, in case true simply dont use connector auth and do the reverse if false.. A last detail, to be fully backward compatible with tc3.3 ( and i think fully compliant with the spec ) this must default to NOT use HTTP server auth and only honor TC own's.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Request.java
Quoting myself ( sorry ) the connector element in server.xml to that point in code, and check it, in case true simply dont use connector auth and do the reverse if false.. A last detail, to be fully backward compatible with tc3.3 ( and i think fully compliant with the spec ) this must default to NOT use HTTP server auth and only honor TC own's.. I think I get it. What's the property name I should be using (so that I don't confuse users too much) ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Request.java
I don't understand what you mean here. If you want tomcat to authenticate, and the userid is passed in, your code doesn't call setUserPrincipal. If you want Tomcat to authenticate, you set 'tomcatAuthentication' to true (that's the default), in which case the connector will always set the user pricipal to null, regardless of what was set by the connector. When the userid passed in is the empty string (not null) and you don't want Tomcat authentication, your code will set the user principal to an Ajp13Principal wrapping the empty string and Tomcat will generate the access denied (403) error when the user hits the page through the connector since the user principal will not be null, but will also be an invalid empty string userid. If you don't want Tomcat to authenticate, you set 'tomcatAuthentication' to false, and the fact of whether or not the pricipal is valid is irrelevant, since Tomcat is never supposed to authenticate in the first place. Note the (ajp.remoteUser() != null) which prevents calling toString on the possibly null field. I think I implemented what Nacho recommended (and which seems more consistent). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Request.java
remm02/02/14 16:54:43
Modified:jk/java/org/apache/ajp/tomcat4 Ajp13Request.java
Log:
- Apply fix for 5647 and 6219.
- Patch submitted by Jonathan Pierce jonathan.pierce at seagram.com
Revision ChangesPath
1.7 +3 -1
jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Request.java
Index: Ajp13Request.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Request.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- Ajp13Request.java 31 Jan 2002 17:18:51 - 1.6
+++ Ajp13Request.java 15 Feb 2002 00:54:43 - 1.7
@@ -113,8 +113,10 @@
setServerPort(ajp.getServerPort());
String remoteUser = ajp.remoteUser().toString();
-if (remoteUser != null) {
+if ((remoteUser != null) (!(remoteUser.equals( {
setUserPrincipal(new Ajp13Principal(remoteUser));
+} else {
+setUserPrincipal(null);
}
setAuthType(ajp.authType().toString());
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Request.java
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: viernes 15 de febrero de 2002 1:55 Perhaps is better to have explicit control over that, to disable or enable the control of the native auth honoring..the infamous tomcatAuthentication attribute.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Request.java
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: viernes 15 de febrero de 2002 1:55 Perhaps is better to have explicit control over that, to disable or enable the control of the native auth honoring..the infamous tomcatAuthentication attribute.. I don't quite understand, as the patch only add filtering out an empty string, right ? Or did I miss something ? In any case, I just applied the patch as it looked ok to me. If the patch is bad, revert it. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Request.java
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: viernes 15 de febrero de 2002 1:55 Perhaps is better to have explicit control over that, to disable or enable the control of the native auth honoring..the infamous tomcatAuthentication attribute.. I don't quite understand, as the patch only add filtering out an empty string, right ? Or did I miss something ? In any case, I just applied the patch as it looked ok to me. If the patch is bad, revert it. i think native auth honoring is different than the problem this patch addresses. i don't think the patch should be reverted (so long as it works :)). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Request.java
It's a trust issue. By default, 3.3 doesn't trust IIS's/Apache's authentication and will check it again. I agree that we should implement tomcatAuth in 4.0.3 if at all. - Original Message - From: Kevin Seguin [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, February 14, 2002 6:18 PM Subject: RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Request.java De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: viernes 15 de febrero de 2002 1:55 Perhaps is better to have explicit control over that, to disable or enable the control of the native auth honoring..the infamous tomcatAuthentication attribute.. I don't quite understand, as the patch only add filtering out an empty string, right ? Or did I miss something ? In any case, I just applied the patch as it looked ok to me. If the patch is bad, revert it. i think native auth honoring is different than the problem this patch addresses. i don't think the patch should be reverted (so long as it works :)). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Request.java
seguin 01/06/25 09:00:43
Modified:jk/java/org/apache/ajp Ajp13.java AjpRequest.java
jk/java/org/apache/ajp/tomcat4 Ajp13Request.java
Log:
changed AjpRequest so that it extends org.apache.tomcat.util.http.BaseRequest.
NOTE: not sure if this is the *right thing* -- perhaps AjpRequest should wrap
BaseRequest.
guess we'll figure that out later :)
Revision ChangesPath
1.8 +26 -23jakarta-tomcat-connectors/jk/java/org/apache/ajp/Ajp13.java
Index: Ajp13.java
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/Ajp13.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- Ajp13.java2001/06/24 21:17:49 1.7
+++ Ajp13.java2001/06/25 16:00:38 1.8
@@ -316,20 +316,20 @@
// Translate the HTTP method code to a String.
byte methodCode = msg.getByte();
-req.method.setString( methodTransArray[(int)methodCode - 1] );
+req.method().setString(methodTransArray[(int)methodCode - 1]);
-msg.getMessageBytes(req.protocol);
-msg.getMessageBytes(req.requestURI);
+msg.getMessageBytes(req.protocol());
+msg.getMessageBytes(req.requestURI());
-msg.getMessageBytes(req.remoteAddr);
-msg.getMessageBytes(req.remoteHost);
-msg.getMessageBytes(req.serverName);
-req.serverPort = msg.getInt();
+msg.getMessageBytes(req.remoteAddr());
+msg.getMessageBytes(req.remoteHost());
+msg.getMessageBytes(req.serverName());
+req.setServerPort(msg.getInt());
isSSL = msg.getBool();
// Decode headers
- MimeHeaders headers = req.headers;
+ MimeHeaders headers = req.headers();
int hCount = msg.getInt();
for(int i = 0 ; i hCount ; i++) {
String hName = null;
@@ -345,23 +345,26 @@
if(0xA000 == isc) {
msg.getInt(); // To advance the read position
hName = headerTransArray[hId - 1];
- vMB= headers.addValue( hName );
+ vMB= headers.addValue(hName);
} else {
// XXX Not very elegant
- vMB=msg.addHeader( headers );
- if( vMB==null) return 500; // wrong packet
+ vMB = msg.addHeader(headers);
+ if (vMB == null) {
+return 500; // wrong packet
+}
}
msg.getMessageBytes(vMB);
// set content length, if this is it...
if (hId == SC_REQ_CONTENT_LENGTH) {
-req.contentLength = (vMB == null) ? -1 : vMB.getInt();
+int contentLength = (vMB == null) ? -1 : vMB.getInt();
+req.setContentLength(contentLength);
} else if (hId == SC_REQ_CONTENT_TYPE) {
ByteChunk bchunk = vMB.getByteChunk();
-req.contentType.setBytes(bchunk.getBytes(),
- bchunk.getOffset(),
- bchunk.getLength());
+req.contentType().setBytes(bchunk.getBytes(),
+ bchunk.getOffset(),
+ bchunk.getLength());
}
}
@@ -377,19 +380,19 @@
break;
case SC_A_REMOTE_USER :
-msg.getMessageBytes(req.remoteUser);
+msg.getMessageBytes(req.remoteUser());
break;
case SC_A_AUTH_TYPE:
-msg.getMessageBytes(req.authType);
+msg.getMessageBytes(req.authType());
break;
case SC_A_QUERY_STRING :
- msg.getMessageBytes(req.queryString);
+ msg.getMessageBytes(req.queryString());
break;
case SC_A_JVM_ROUTE:
-msg.getMessageBytes(req.jvmRoute);
+msg.getMessageBytes(req.jvmRoute());
break;
case SC_A_SSL_CERT :
@@ -424,16 +427,16 @@
}
if(isSSL) {
-req.scheme = req.SCHEME_HTTPS;
-req.secure = true;
+req.setScheme(req.SCHEME_HTTPS);
+req.setSecure(true);
}
// set cookies on request now that we have all headers
-req.cookies.setHeaders(req.headers);
+req.cookies().setHeaders(req.headers());
// Check to see if there should be a body packet coming along
// immediately after
- if(req.contentLength 0) {
+ if(req.getContentLength() 0) {
/* Read present data */
