ant install java.net.ProtocolException: Server redirected too many times (20)
I am trying to build an app under tomcat 9-0-14 that I had previously built under tomcat 7 several years ago. however when I run the "ant install" command it fails with the following errors. BUILD FAILED C:\barry\hockey3\build.xml:369: java.net.ProtocolException: Server redirected too many times (20) build.xml : 362 , 371 362: 364: 365: 370: 371: Here is a directory listing where my java software is located C:\Program Files\Java>dir Volume in drive C is TI10673200G Volume Serial Number is 5E9D-3D3F Directory of C:\Program Files\Java 01/16/2019 11:47 AM . 01/16/2019 11:47 AM .. 01/01/2019 03:47 PM jdk1.8.0_191 01/16/2019 11:46 AM jre1.8.0_201 0 File(s) 0 bytes 4 Dir(s) 589,238,714,368 bytes free I am running on a Windows 10 64 bit system. Any ideas on how to resolve this issue ? So far my searches have not turned up anything usefull. -- == Barry Kimelman Atlanta, GA, USA
Re: Tomcat 8.5 SPNEGO Active Directory stuck with a "Failed authenticate() test"
Am 2019-02-08 um 12:54 schrieb Tommy Schneider: Hello, I'm trying to set up Tomcat 8.5 with SPNEGO in the following environment: Tomcat: 8.5.37 built: Dec 12 2018 12:07:02 UTC Platform/OS: AIX 7.2 ppc64 Java: Eclipse OpenJ9 9-internal+0-adhoc.jenkins From what I can see in the catalina log I think it's almost working (AD user is returned back correctly), but in the web application I always get stuck with a HTTP 401. No matter whether I'm using a JNDI realm or a simple JAAS realm. I also tried different approaches in the application's web.xml like using "*" as generic role name or specifiying a list of role names like they should come back from the AD). I'm starting to think the cause may still be somewhere in the SPNEGO/Kerberos stuff and not in my realm/application config. Currently I'm trying to use a simple JAAS realm (as I found a tutorial saying this is the simplest way to go when you just need the user name and no roles) snippet from server.xml snippet from catalina.out: Found KeyTab /opt/apache-tomcat-8.5/conf/tomcat.keytab for HTTP/mymachine.mycompany@mycompany.com Found ticket for HTTP/mymachine.mycompany@mycompany.com to go to krbtgt/mycompany@mycompany.com expiring on Fri Feb 08 21:26:27 CET 2019 Entered Krb5Context.acceptSecContext with state=STATE_NEW Looking for keys for: HTTP/mymachine.mycompany@mycompany.com Added key: 17version: 15 Added key: 18version: 15 Added key: 23version: 15 Found unsupported keytype (3) for HTTP/mymachine.mycompany@mycompany.com Found unsupported keytype (1) for HTTP/mymachine.mycompany@mycompany.com >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType Using builtin default etypes for permitted_enctypes default etypes for permitted_enctypes: 18 17 16 23. >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType MemoryCache: add 1549621587/000784/231A915D0FE70A039CF82095FC685C843F4D981D20A70F972015D8EB16D07CA5/myusern...@mycompany.com to myusern...@mycompany.com| HTTP/mymachine.mycompany@mycompany.com >>> KrbApReq: authenticate succeed. >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType >>>Delegated Creds have pname=myusern...@mycompany.com sname=krbtgt/mycompany@mycompany.com authtime=null starttime=20190208095329Z endtime=20190208195235ZrenewTill=20190215095235Z Krb5Context setting peerSeqNumber to: 883655442 >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType Krb5Context setting mySeqNumber to: 318684000 [Krb5LoginModule]: Entering logout [Krb5LoginModule]: logged out Subject 08-Feb-2019 11:26:27.415 FINE [https-jsse-nio-443-exec-5] org.apache.catalina.authenticator.AuthenticatorBase.invoke Failed authenticate() test I'm happy with the part where "myusern...@mycompany.com" is returned back from the AD, so I think most of the stuff is configured correctly so far. However I have no idea what the last 3 lines indicate. Is it ok that the "logout" occurs here? What causes the authenticator to fail? Is this still related to the SPNEGO stuff or is it caused by the realm or an incorrect web.xml in the application (I tried different variants here and it all seems to end up with a "org.apache.catalina.authenticator.AuthenticatorBase.invoke Failed authenticate() test". Let me know if you need more configuration details. Any help would be greatly appreciated We need more debug output. This doesn't really help. Please enable it, it will help. The Kerberos debug output you see is is just Sun-internal which has nothing to do with the Tomcat code. The logout() is performed on the LoginContext required to obtain server credentials. The are released (hence logout performed) as soon as the security context has been established and the GSS src name has been obtained. Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
migration from tomcat 7.0 to 8.5
I've read the migration manuals and have tried to make the changes to my configuration files to work correctly in tomcat v8.5, but it's not. I'm not an expert on XML files and JDK so please help me. I'm sure this is crazy simple for you experts. The server.xml conf file is OK between the two versions. But my application's deployment is having problems. In my tomcat v7 conf/Catalina/localhost directory, I have ed.xml file for my application containing: So the question is what to do with Loader section. After spending about 6 hours and reading tons of other web posts from others trying to do the same thing, I finally have something working, kinda. My web application at least deploys when tomcat starts. The Loader part in the .xml was replaced with: I think I'm up to 12 hours messing with this and reading everything I can get my hands on. I still don't have a good understanding of what webAppMount is or what I should set it to, and, for that matter, internalPath. I changed PostResources to JarResources and nothing changed. The jar files are not getting found or the classes in the jar files are not getting found. When I access the JSP page that need to resolve classes in these .jar's, I get org.apache.jasper.JasperException: Unable to compile class for JSP: An error occurred at line: [20] in the generated java file: [/work/Catalina/localhost/ed/org/apache/jsp/charters_jsp.java] Only a type can be imported. com.google.api.client.json.JsonFactory resolves to a package Line 20 is: import com.google.api.client.json.JsonFactory; I'd really like to get off Tomcat 7 before it's EOL. Please help with what I need to do to make my app work in Tomcat 8.5.X Thanks, Paul - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Does Tomcat count incoming connections?
> -Original Message- > From: john.e.gr...@wellsfargo.com.INVALID > [mailto:john.e.gr...@wellsfargo.com.INVALID] > Sent: Friday, February 08, 2019 2:24 PM > To: users@tomcat.apache.org > Subject: [[EXTERNAL]] RE: Does Tomcat count incoming connections? > > Chris, > > > > -Original Message- > > From: Christopher Schultz > > Sent: Friday, February 08, 2019 11:48 AM > > To: users@tomcat.apache.org > > Subject: Re: Does Tomcat count incoming connections? > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > John, > > > > > > You can get this count from the Connector via JMX. > > > > Look at the tree under /Catalina/GlobalRequestProcessor/[connector] > > and there is a "requestCount" attribute that can be queried. > > > > Looks like it's an int value, so it can overflow. > > > > - -chris > > Thanks but the requestCount really does appear to be requests and not > connections. I have keepAliveTimeout and maxKeepAliveRequests at their > defaults (unlimited timeout and 100 requests) and I see the count go up with > each request, even though my client reports that the connection is getting > reused. > > I'm asking because I need some hard data on whether clients are reusing > their connections for performance reasons. How about the Catalina Threadpool ? It has busyThreads, active connections, poller threads, and keep-alive threads metrics. Ron -- This e-mail message is being sent solely for use by the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by phone or reply by e-mail, delete the original message and destroy all copies. Thank you. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Does Tomcat count incoming connections?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 John, On 2/8/19 15:24, john.e.gr...@wellsfargo.com.INVALID wrote: >> -Original Message- From: Christopher Schultz >> Sent: Friday, February 08, 2019 >> 11:48 AM To: users@tomcat.apache.org Subject: Re: Does Tomcat >> count incoming connections? >> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> John, >> >> >> You can get this count from the Connector via JMX. >> >> Look at the tree under >> /Catalina/GlobalRequestProcessor/[connector] and there is a >> "requestCount" attribute that can be queried. >> >> Looks like it's an int value, so it can overflow. >> >> - -chris > > Thanks but the requestCount really does appear to be requests and > not connections. I have keepAliveTimeout and maxKeepAliveRequests > at their defaults (unlimited timeout and 100 requests) and I see > the count go up with each request, even though my client reports > that the connection is getting reused.> I'm asking because I need > some hard data on whether clients are reusing their connections for > performance reasons. I'm really sorry. I must admit I read the first sentence and not the second and told you something you already wrote in your first post :( I don't see anywhere that a connection count is currently available, but it doesn't seem like it would be that much work to add it. I'm not sure what the best place to /put it/ would be, since there really isn't anything that coarse-grained in the JMX tree at this point. For example, the GlobalRequestProcessor is, as the name suggests, request-oriented. I think the ProtocolHandler is much the same. The Connector itself is, unfortunately, mostly useless because it just shows the configuration of the connector and nothing really live. Hopefully Mark or Rémy will reply; they both understand the connection management at a very low level and will probably say "already done!" or "eww... that's going to be complicated." With luck, the former. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxd6GYACgkQHPApP6U8 pFjshQ/9E/6rZJQFeOxG6inXp7WjeJYb4tm1tlaA+DUeWhRBVTjnl3FT7yVmD3O5 ZxXt4oelVeeCyhqWVlKOYvAPL5N24gZYJMiRJB5CA33rQrpmmiLLQ9dH6glssTDM 5BWCp2rvMMlns6fpVu7X+FEcIS+yh/Ps4Ttb6SsoRWIdFkpAChO5/qZB2uHrV15Y 1L2sKf9djmZVx3w3nmb9HmcNMTsPa/iE1PpxAcXEF566P6jxKrqhLn/nkhgFeOb4 72EUA+ctd5oPpRyCl/BbbdmPVIzRBD+HP0JAjGA4HPYO6oKoAXwvvveGwA5U3MFJ rOQyZhfZ97a0qVC+9sqNJ6twdv+5xzJr/EybRNndKA+imMP86wC8nqAJCRHuK5Y5 YiHKJlXNu3vmqnbODyplWWIqyuKtDfIopGZQyHatRU2iV3Zki3JhfhAb1eMPjISn dS8qY3+/y8YGbKa7ZEurEO0qdW8j4KTUKixx3Qqft7vNexzk3YAm4mN+hLgzptZk Twlo1FD8qJEHiRUk9QB79Z8m+NqcQDdNanMg1fPeEgpdt6hzLT3P3eulE8zL6Qy2 W71cLeF4Z5/xrQhd5cdWwgFWTy/h2E4P9hmEMK+hVrPdwWRslpvBGOGWUiR93pbm yRxou6fsi4cYX4ZWIuiJH0bRNcM27kyhdxYs5GIhh6n0MWm7IbE= =ktWZ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Does Tomcat count incoming connections?
Chris, > -Original Message- > From: Christopher Schultz > Sent: Friday, February 08, 2019 11:48 AM > To: users@tomcat.apache.org > Subject: Re: Does Tomcat count incoming connections? > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > John, > > > You can get this count from the Connector via JMX. > > Look at the tree under /Catalina/GlobalRequestProcessor/[connector] > and there is a "requestCount" attribute that can be queried. > > Looks like it's an int value, so it can overflow. > > - -chris Thanks but the requestCount really does appear to be requests and not connections. I have keepAliveTimeout and maxKeepAliveRequests at their defaults (unlimited timeout and 100 requests) and I see the count go up with each request, even though my client reports that the connection is getting reused. I'm asking because I need some hard data on whether clients are reusing their connections for performance reasons. John - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: current best practices for Tomcat with SSL on port 443
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Garret, On 2/8/19 08:27, Garret Wilson wrote: > On 2/7/2019 9:54 PM, Christopher Schultz wrote: >> … I would argue that adding Apache httpd into the mix (where is >> it not already there) is more complicated than using Let's >> Encrypt with Tomcat. > > > OK, I guess I didn't figure in the part about adding/configuring > the connector. But still there are a few things I have doubts > about, just looking over the document quickly: > > * There's still the issue about listening on lower port numbers. > From the presentation, it looks like I would need to teach myself > about iptables. Or use jsvc. Or authbind. There are lots of ways to make lower-numbered ports work these days. Are the students running their own servers / VMs / containers / whatever? I mean... not everyone can have port 80 on the same machine, so... jsvc is fairly straightforward. catalina.sh supports it pretty much directly. > I wonder if students (and I) would find mucking with iptable > configurations easier than just installing apache using APT and > editing some XML files. (I don't know; I haven't looked into it > deeply.) And the presentation tantalizingly mentioned something > called "jsvc" but didn't provide any further details. I'll have to > research that. Then I'll search for "jsvc vs iptables", etc. So > the presentation is a good thing to tell me what to look for. jsvc is a native wrapper around Tomcat that can elevate privileges, bind to port 80 (and 443, or whatever you need), then drop privileges. > * What about forwarding from the non-secure site to the HTTPS > site? Apache makes that pretty easy; actually it's a little arcane, > but once you have the virtual host file one wants one can use it as > a pattern. I'll note that the presentation didn't cover that. Just put this into your web.xml like always (right?): Whole site /* CONFIDENTIAL Tomcat will handle the redirect if you try to access the application via a non-secure protocol. > Or is that something iptables is responsible for, too? Nope, iptables doesn't re-write protocols. It only re-wires ports. If you connect to a secure service with a non-secure protocol, the TLS handshake will fail. At least, on Tomcat it will. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxdwtAACgkQHPApP6U8 pFgPAxAAi8EEFByG47X9hmad00CWNEs2eV/8QMDtWdNtGasDJ95vPxYxRjvE/crZ WiOSxv6aGBtv2aZ/yOW/PJ+dccb7gup0R2KRL+Z9snjvAD3R6mEIYSx0QZ/bQAz9 qERVd2LV2s22Suea6KU1Dcws9PqLw6l9R+I1FgywqTjvFcKmlG9BeHZetvhjesby tCoM/plhCCO1Jo48Nyha0ew4s8TPQ0CkAx0i344y/e7K+PFwRpzvhtP+Q8Nje/// lx1Kq29BHshCImeD76/FCjLNQonr/PNDaoqPDnrRqji8Nvks78zAg0ejFSDSKXvg //fbFNAEpkK+OWkS+2HjyR93DKkHLAnP7nVj2Gcl+5ehqy0tqKL4lZFLbRyNxc81 Wz50G67YgaEFDJzXZwFGn5eTFyiynlu9DmWRKPJB9UpJvWwJe0MVkTxwQ0N9oaYe ++HU9fjSUDAxAm6vcVEReujra7B+6UYOgiafbNjGAcgXp4du3pt5cnHvuPJzFfU4 EXDgLAsdoKOIm55AUUwXNIAnKPTsXjzOSuVp0SPXjwXaAz21Uxw7cWBbAKeznKDV gIaKfBw40FwyZaKQxzb+ag5R+Apm4Zvy8hQq6vVn5CzZcTaTq0ME9zj5pWM6DB1j dOwZmMvAkg7ZtvGkBv5m+vAakLFrM0Wp4cRyvriB2V6eHSeyQW8= =WdDP -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Does Tomcat count incoming connections?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 John, On 2/8/19 12:09, john.e.gr...@wellsfargo.com.INVALID wrote: > I'm interested in knowing how many new incoming connections are > being created, possibly per connector. Does Tomcat have such a > thing? I assume it would involve counting calls to > ServerSocketChannel.accept() or something like that. I see the > GlobalRequestProcessor MBean has a request count, but I would also > like to know connection count. You can get this count from the Connector via JMX. Look at the tree under /Catalina/GlobalRequestProcessor/[connector] and there is a "requestCount" attribute that can be queried. Looks like it's an int value, so it can overflow. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxdwLsACgkQHPApP6U8 pFg3oQ/9Ey53oVrsO7Z2kxjnMJPEbLLKf4UV9J9GMSuolTR2Bd9LaqBGhjbcwCwm cRfGwvywzVihazJNZcHuPZI0SftdpGjWMay/vnJbaxsyzgqj09WCnR9QFYlOJx4x B73E0OAllGXW11XlgnfC/XCeH2OdIjRwHFCSwoLQ0RfzKAHp54KBGzGJODxWUfWV uDjDmSLBxT37SdwpUehx8MtbJB9Z/Hp28zIrmjNrFHIcPwJ19HFYxe+I5nyqPHgA 4qniywWghcQErnBAfYJB/IJn66gBI7eH1UwJKOVQJ56VDFphjpjiXZX3AxFIe586 NylvXO0xcMkO4c91RiZwPh0fXvzT2s+1DP1ZI7ruDWtQ7+oJlv3DniJbfbQHN2pM Elax5g367fPSEWItZ8aS+Yy1UyEsDAZt/fGe9qB+Gvbqld0U0ppJ6qBqKVYz4+4T GVS/vO3bdcG11S/Yp7b+4ImjfEUL3OI46mN7G3BhapRS8r8tzuThoqKnTpQQI69O LCSs5Sqmeot8lbjGWnDtFmG+dBCyXPQ2H2tBhDid2HXyiDoQhArTezGHoD6h3Rqa b2Q3WdiSLtWP2Lffwym/AHbavwfE/6eUvCtWhXBNG2KHT9JTwAj/w/zBAFYsM5MD jTdbN4gf8g+ZNjjWL3NJivbkTS5N3yx0CW2eK+T4Vq16aCw+VOo= =cPja -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Does Tomcat count incoming connections?
Hi all, I'm interested in knowing how many new incoming connections are being created, possibly per connector. Does Tomcat have such a thing? I assume it would involve counting calls to ServerSocketChannel.accept() or something like that. I see the GlobalRequestProcessor MBean has a request count, but I would also like to know connection count. Thank you John
Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Pawel, On 2/7/19 19:41, Pawel Veselov wrote: > Sorry for a rather rude intrusion. If you think it's rude, why did you do it? > On Thu, Feb 7, 2019 at 4:18 PM Christopher Schultz > wrote: > >> Chunked encoding is like sending a bunch of small HTTP >> message-pieces (I have to be careful about my wording here, since >> "part" actually means something in multipart messages > > May be just "chunks"? :) Defining a word using the word itself is circular-reasoning. If you looked-up "chunk" in the dictionary and it said: "Chunk: (n) chunk", you'd be kind of lost, wouldn't you? >> Then, you send each chunk with a chunk size (in decimal bytes), a >> CRLF pair, then your content, and another CRLF pair. The final >> chunk has a length of 0 (zero): >> >> 32 [32 bytes of data] 128 [128 bytes of data] 0 > > Chunk sizes are expressed in hexadecimal notation, though, not > decimal. Yes, thank you for the correction. Those numbers should have been: 20 [32 bytes of data] 80 [128 bytes of data] 0 - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxdkOAACgkQHPApP6U8 pFgxQBAAk8GXkkc4bXp0Uf4JmaBtxthDrRIqs6eUx6wqjQdeJgTCAGUIF4274j9k bmfaYWx0d4/ZZ4yibrD/7RjSn3ezSaE69x1beYs7UaFZTdooA8azspMCgh0iDmx1 OcbYFpo2qjrsA0GIoxmP8qBbSCXV/guw/OmCRmj4LFBV3hc5+ADu4ioxcko6jWSa hNxmBNcpH8nlUqeNeb3bSK/fh1FKBHQFEVe46KI0dXkYVoTNfoTqKohxyzRpMh/h xhMb0MWyad04F6k0gBuoaCnzsuq5ZKdnKRXuslpidhFT3Jc2/NdGBpQcYhjYoGgT 2PHVgrlshu+CTl5Gn/6KvFUGE2O0yyRuirpv6iQZ9kQ/3Gn3FlrgT5ZxhHbRZ1B7 7a98TegGyRn5KQ4YvJkpjGljtkfxBjjRfvA1NBhdHRplUuaxB4U/mROccDCVXVr9 YybUVGNwP1Zd4no8B4NKtDyAGXFtgkJz/SCCmZ4F5EYkCAXLRnNZ27nXfrA6XYYO QxOe7XaAy9PMKiaW7L+wIevHeXPhrPlgus4usS/F1ZelDxY6nY1oekJmpCTX4gnm HlgrLIA35YGPjQGVhqtvQhJGSg+JQGIX5Azj98fjJ0hypy1obHXOtvCe+/O93i/q OsRj9gcxXybTTp24G1U8J03p0s+o3q7gb9Tf9La/AqrB4hvpZLA= =1Oqx -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: current best practices for Tomcat with SSL on port 443
On 2/7/2019 9:54 PM, Christopher Schultz wrote: … I would argue that adding Apache httpd into the mix (where is it not already there) is more complicated than using Let's Encrypt with Tomcat. OK, I guess I didn't figure in the part about adding/configuring the connector. But still there are a few things I have doubts about, just looking over the document quickly: * There's still the issue about listening on lower port numbers. From the presentation, it looks like I would need to teach myself about iptables. I wonder if students (and I) would find mucking with iptable configurations easier than just installing apache using APT and editing some XML files. (I don't know; I haven't looked into it deeply.) And the presentation tantalizingly mentioned something called "jsvc" but didn't provide any further details. I'll have to research that. Then I'll search for "jsvc vs iptables", etc. So the presentation is a good thing to tell me what to look for. * What about forwarding from the non-secure site to the HTTPS site? Apache makes that pretty easy; actually it's a little arcane, but once you have the virtual host file one wants one can use it as a pattern. I'll note that the presentation didn't cover that. Or is that something iptables is responsible for, too? Cheers, Garret
Tomcat 8.5 SPNEGO Active Directory stuck with a "Failed authenticate() test"
Hello, I'm trying to set up Tomcat 8.5 with SPNEGO in the following environment: Tomcat: 8.5.37 built: Dec 12 2018 12:07:02 UTC Platform/OS: AIX 7.2 ppc64 Java: Eclipse OpenJ9 9-internal+0-adhoc.jenkins >From what I can see in the catalina log I think it's almost working (AD user is returned back correctly), but in the web application I always get stuck with a HTTP 401. No matter whether I'm using a JNDI realm or a simple JAAS realm. I also tried different approaches in the application's web.xml like using "*" as generic role name or specifiying a list of role names like they should come back from the AD). I'm starting to think the cause may still be somewhere in the SPNEGO/Kerberos stuff and not in my realm/application config. Currently I'm trying to use a simple JAAS realm (as I found a tutorial saying this is the simplest way to go when you just need the user name and no roles) snippet from server.xml snippet from catalina.out: Found KeyTab /opt/apache-tomcat-8.5/conf/tomcat.keytab for HTTP/mymachine.mycompany@mycompany.com Found ticket for HTTP/mymachine.mycompany@mycompany.com to go to krbtgt/mycompany@mycompany.com expiring on Fri Feb 08 21:26:27 CET 2019 Entered Krb5Context.acceptSecContext with state=STATE_NEW Looking for keys for: HTTP/mymachine.mycompany@mycompany.com Added key: 17version: 15 Added key: 18version: 15 Added key: 23version: 15 Found unsupported keytype (3) for HTTP/mymachine.mycompany@mycompany.com Found unsupported keytype (1) for HTTP/mymachine.mycompany@mycompany.com >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType Using builtin default etypes for permitted_enctypes default etypes for permitted_enctypes: 18 17 16 23. >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType MemoryCache: add 1549621587/000784/231A915D0FE70A039CF82095FC685C843F4D981D20A70F972015D8EB16D07CA5/myusern...@mycompany.com to myusern...@mycompany.com| HTTP/mymachine.mycompany@mycompany.com >>> KrbApReq: authenticate succeed. >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType >>>Delegated Creds have pname=myusern...@mycompany.com sname=krbtgt/mycompany@mycompany.com authtime=null starttime=20190208095329Z endtime=20190208195235ZrenewTill=20190215095235Z Krb5Context setting peerSeqNumber to: 883655442 >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType Krb5Context setting mySeqNumber to: 318684000 [Krb5LoginModule]: Entering logout [Krb5LoginModule]: logged out Subject 08-Feb-2019 11:26:27.415 FINE [https-jsse-nio-443-exec-5] org.apache.catalina.authenticator.AuthenticatorBase.invoke Failed authenticate() test I'm happy with the part where "myusern...@mycompany.com" is returned back from the AD, so I think most of the stuff is configured correctly so far. However I have no idea what the last 3 lines indicate. Is it ok that the "logout" occurs here? What causes the authenticator to fail? Is this still related to the SPNEGO stuff or is it caused by the realm or an incorrect web.xml in the application (I tried different variants here and it all seems to end up with a "org.apache.catalina.authenticator.AuthenticatorBase.invoke Failed authenticate() test". Let me know if you need more configuration details. Any help would be greatly appreciated thx and kind regards, Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 9.0.16 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 9.0.16. Apache Tomcat 9 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language, Java WebSocket and JASPIC technologies. Apache Tomcat 9.0.16 is a bugfix and feature release. The notable changes compared to 9.0.14 include: - Update the packaged version of the Tomcat Native Library to 1.2.21 to pick up the memory leak fixes when using NIO/NIO2 with OpenSSL. - Remove extras (JMX remote listener and web services object factories) and merge them back into the core build. - Correct a regression in the fix for 53737 that did not correctly scan the web application directory structure for JSPs. - Improve HTTP/2 timeout handling Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-9.0-doc/changelog.html Downloads: http://tomcat.apache.org/download-90.cgi Migration guides from Apache Tomcat 7.x and 8.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Receiving 403 with Tomcat 9, works with Tomcat 8
Hi Mark, Am Mittwoch, 6. Februar 2019, 15:32:26 CET schrieb Mark Thomas: [snip] > You need to set cors.allowed.origin to an appropriate value. See: > http://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#CORS_Filter thanks for your pointers, but unfortunately even setting the value to '*' has no effect, we still get the 403 for this request. Is there anything else we can to to debug this? Some logger settings? Regards, Jörg - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org