Hi all- I've encountered a potential bug in Tomcat 4.0's AJP13 listener. I have a default installtion of Apache 1.3.22, mod_jk, and Tomcat 4.0.1. I have duplicated this environment on both Windows 2000 and Linux. mod_jk is talking to Tomcat via ajp13. Tomcat is (as default) listening on 8080 for its HTTP interface and on 8009 for ajp13. The problem is this: when I access to Tomcat manager application through Apache+mod_jk, i.e. http://myserver/manager/list, I get properly challenged to log in, but my username and password never work, and Tomcat eventually says I am unauthorized. If I then access the same resource directly through Tomcat, i.e. http://myserver:8080/manager/list, I get access with no problem. The problem could be in mod_jk, although I suspect it may lie in Tomcat's ajp13 listener (simply because mod_jk is older and more widely used, whereas Tomcat 4 is newer). Please let me know if this is a bug, and if I can assist in any way. Thanks! Best regards, Richard
Hi, I have observed the same. The latest mod_jk has introduced the option not to use the login information from the apche server. May be that there is the problem. I can run my applications with tomcat 3.2.3 and 3.3a and the authentication works fine. I want to use tomcat 4.0.1 now, but basic authentication does not work with mod_jk and ajp 13.
*** Bug 5951 has been marked as a duplicate of this bug. ***
Hi, I found a statement about this problem in the tomcat-user mailing list from last October, which says that realm authentication with ajp13 has not been ported to Tomcat 4.0.1 yet, but is expected to be ported to Tomcat 4.0.2. (http://www.mail-archive.com/tomcat-user%40jakarta.apache.org/msg36130.html) Best regards Rüdiger Plüm
Created attachment 1085 [details] fix by calling RequestBase.setAuthorization()
I have seen the same problem. I applied Adam's patch to jakarta-tomcat-connectors from CVS updated tonight, and HTTP Basic Authentication worked, even over SSL. This was using a build of Tomcat 4.1-dev from a few weeks ago. I have the karma to commit this, but since I don't normally work on the apache connectors, I'll leave the commit to one of the regulars.
Commited Adam's patch to the HEAD of the jakarta-tomcat-connectors cvs repository. Fixed in CVS.
Hello, I'm the submitter of bug 5951 which was marked a duplicate of this bug. I just downloaded 4.0.2 which contains the patches above. I am still having the *exact* problem as bug 5951. Here is a reprint of that bug less the AJP13 debug log which is still at bug 5951. Can anyone tell me if they successfully got this working under apj13 of the windows redirector? (tomcat 3.3) Thanks Much Mike Reprint of bug 5951: I tried the tomcat 3.2 security example using basic authentication with tomcat 4 standalone (http connector). It works fine. As soon as I use the tomcat 4 ajp13 connector with iis5, it does not work. Where I expect the authentication dialog to appear, it simply just goes directly to a tomcat 4.0.2 http status 403 - access to the requested resource has been denied screen. I expected tomcat to respond with a Status: 401 unauthorized and a WWW-Authenticate: Basic Realm="xxxx" response. I even tried it with the /manager webapp with the same results. I even tried it with form base authentication with same results. Please advise.
i just tried accessing the manager webapp with 4.0.2 and IIS, without any luck. it appears that the auth challenge is not being done (the WWW- Authenticate header is not sent) across ajp. so, i'm not sure why, but it's definitely not working with IIS. don't know about apache/netscape.
I've confirmed that the problem still exists in Tomcat 4.0.2. I first rebuilt the native connector from D:\jakarta-tomcat-connectors-4.0.2-src\jk\native\iis. I've configured Tomcat4.0.2 with the AJP 1.3 Connector and successfully installed the iisapi dll from Tomcat3.3 into IIS. I am attempting to serve a protected page through the connector using the protected realm example. When I hit the page directly on port 8080, I get the expected login form challenge behavior. When I hit the page through the connector, I get a 403 access denied error. http://localhost:8080/examples/jsp/security/protected/index.jsp redirects to the login screen as expected. http://localhost/examples/jsp/security/protected/index.jsp returns 403 - Access to the requested resource has been denied. Jonathan
This is related to <http://nagoya.betaversion.org/bugzilla/show_bug.cgi? id=2342>, the solution it's not easy, and there is no workaround right now: 1) Implement the "tomcatAuthentication" hack from 3.3 in j-t-c's Ajp for 4.0, this way at least we can have TC auth working under IIS.. with IIS you can not use native auth at all, at least with actual ISAPI_PLUGIN.. 2) Start the dig to use what Bug#2342 suggest, that is, to use the correct Hook in IIS5.. while maitaining IIS4 compatibility..
Hi Nacho, My thoughts is that number 1 should definitely be implemented with or without the 3.3 tomcatAuthentication attribute. Just want tomcat to honor any authentication situations present in the web.xml file if a request is forwarded to tomcat via ajp13 or any other connector. For number 2, if we wanted iis5 to do authentication, this patch is one way to do it if you got iis5 and willing to dump users in the windows users db. If you are a hosting co. or iis4 user, you can buy software (M$) to take over iisX authentication which runs as an isapi filter with a higher order than tomcat's redirector. So at least there are other options available if you want iisx authentication with or without tomcat authentication. Thanks for allowing me to contribute my input. Mike
*** Bug 6219 has been marked as a duplicate of this bug. ***
I've confirmed the fix for the AJP13 Connector / Authentication problem in 4.0.2. This solves high priority bugs 5647 and 6219. Please have one of the committers confirm the fix and check it in to cvs. The issue was reported in Bug 6219. I tested the following modification and it seems to resolve the problem. The problem is in org.apache.ajp.tomcat4.Ajp13Request.setAjpRequest The fix is below: Replace from line 115: // String remoteUser = ajp.remoteUser().toString(); // if(remoteUser != null) // setUserPrincipal(new Ajp13Principal(remoteUser)); String remoteUser = ajp.remoteUser().toString(); if ((remoteUser != null) && (! remoteUser.equals (""))) { setUserPrincipal(new Ajp13Principal(remoteUser)); } else { setUserPrincipal(null); } After making this modification, I am able to successfully serve the protected example url through the IIS connector and get properly challenged by the login screen and am able to login and logout as expected. http://localhost/examples/jsp/security/protected/index.jsp
This bug has been fixed in j-t-c, by introducing a new property for the AJP connector.
Hello, I just downloaded nightly build Feb-25 to see if the Feb-16 fix worked. Using the IIS connector and the /security/protected example, I am still not being challenged by a login screen. Tomcat just jumps directly to the 403 unauthorized screen. Can anyone else confirm that this problem still exists? Mike
make sure that the jakarta virtual directory does not have "Integrated Windows authentication" turned on. to check/edit this: Internet Services Manager Applet -> Default Web Site -> jakarta -> properties -> Directory Security -> click the "Edit" button in the "Anonymous access and authentication control" frame.
Sorry folks. I just realized the nightly build did not include the updated connectors. I rebuilt the jk jars from the cvs and EVERYTHING WORKED FINE. Thank you. Is there any way to include this stuff in the nightly builds?
Are you sure the bug is resolved in Tomcat4.0.2 release for IIS connector as well? I've added very similar bug for AJP13 with IIS (ID: 6219), and it has been marked as a duplicate of this one... But I've downloaded the 4.0.2, along with new filter DLL for IIS, and the problem still exists. Maybe the filter DLL should not include fields, that do not have values, in AJP13 packets? Otherwise, the patch from 6219 should be applied to AJP13Request.java to get this work.
We did a deep examination, and found that the source of this problem resides inside the IIS DLL code, file: jakarta-tomcat- connectors/jk/native/isapi/jk_isapi_plugin.c : 1) The instance 's' of a structure jk_ws_service_t is inited with a call to: jk_init_ws_service(&s), where the member s.remote_user is set to NULL; 2) that instance is passed to InitService method, which contains this line: GETVARIABLE("REMOTE_HOST", &s->remote_host, ""); The line simply sets the value of s->remote_host to empty string, instead of leaving its NULL. This method affects also other variables. 3) The AJP message is then filled with variables, that were not present in original request, but were substitited empty strings instead of NULLs 4) The AJP13 message parser (in Java), initializes all found variables with no value with empty arrays, resulting later in their conversion to empty Strings instead of null's. That later (in AJP13Request.java) results in empty Principal being set in HttpServletRequest. Solutions: As may be observed in CVS for AJP13Request, the patch was applied to one version only, and has been removed in current version. So, either apply the patch again, or change jk_isapi_plugin.c such that it won't initialize server variables that are not present in original request (just remove the lines from InitService function).
I've downloaded the latest 4.0.4beta2, and use it in combination with Apache 1.3.? from the latest OpenBSD distro. In my web.xml app, I request BASIC authentication. 1) If I put JkMount outside wirtual hosts in httpd.conf, it works. 2) After putting JkMount into one (name) virtual host, it fails (by failing, I mean: the popup windows comes up, but WITH THE WRONG resource name (the name of the virtual host:80) and authentication fails. Is that possible? Cedric
That, what I've said on 2002-03-04, is a bit wrong: the AJP connector DLL works correctly (I've looking at the wrong branch) - as Microsoft said in MSDN, when IIS is queried about REMOTE_USER, it returns empty string when user is anonymous (and in the correct connector branch, all variables are evaluated by querying IIS, not by examining request directly). So, there are two possible solutions: 1). Don't call setUserPrincipal(..) in AJP13Request.setAJPRequest OR 2). In FormAuthenticator, check not only for NULL in getUserPrincipal(), but also for empty String. The bug was corrected in CVS version 1.7 of AJP13Request.java only - solution 1 was applied, and then removed in version 1.8.
I tried both of those solutions and neither worked for me. Did they work for anyone else? I did do some more digging, and I am finding that jk_isapi_plugin.c is seeing the Authorization request, but by the time the request reaches RequestHandler.java, authorization is equal to null. Is this not more closely related to the problem than the setting of the principal object? Here is essentially what I did to find this info out: In HttpFilterProc (jk_isapi_plugin.c) I added: if(p->GetHeader(pfc, "Authorization:", (LPVOID)Authorization, (LPDWORD) &szAuthorization)) { jk_log(logger, JK_LOG_ERROR, "HttpFilterProc Got Authorization: %s \n",Authorization); }else { jk_log(logger, JK_LOG_ERROR, "HttpFilterProc Authorization Not Found\n"); } it returned: [Tue Mar 26 15:48:21 2002] [jk_isapi_plugin.c (628)]: HttpFilterProc started [Tue Mar 26 15:48:21 2002] [jk_isapi_plugin.c (648)]: HttpFilterProc Got Author ization: Basic cHdhZG1pbjpwd2FkbWlu AND in RequestHandler.decodeRequest(), the base request (BaseRequest.java) is dumped to the log if debug (on the connector element in server.xml) is set > 5). *- I modified BaseRequest.toString() to also print the authorization object. *BTW - decodeRequest() happens before setAjpRequest(). That dumps out: 2002-03-26 15:48:21 Ajp13Request[5] Request: === BaseRequest === method = OPTIONS protocol = HTTP/1.1 requestURI = /slide/test remoteAddr = 127.0.0.1 remoteHost = 127.0.0.1 serverName = localhost serverPort = 80 remoteUser = authType = queryString = null authorization = null scheme = http secure = false contentLength = 0 contentType = null attributes = {} headers = === MimeHeaders === accept-language = en-us connection = close host = localhost user-agent = WebDrive/5.01 NT pragma = no-cache content-length = 0 cookies = === Cookies === jvmRoute = null Isn't our problem here?
If anyone has already problems, please check against 4.0.4, this bug seems to be fixed from some time ago.. There some good explations in the bug's log about how to config IIS & Tomcat to get done, please check them before reopen..
When using Tomcat 4.0.3 all works fine, but after we switch to Tomcat 4.0.4 (final) whe no longer get the REMOTE_USER from IIS (REMOTE_USER is null). Workaround: copy the tomcat-ajp.jar from version 4.0.3 to 4.0.4 and it works again.
You need to set the attribute tomcatAuthentication="false" in the ajp13 connector line, inside serevr.xml, not sure if coyote/jk2 supports that already.. But this bug was posted against the original Ajp13 connector , sio i'm closing it, please add another bug, if you are having problems with Coyote/jk2, this one has much information very outdated and perhaps is worse to maintain it.. than to open another Thanks..