Re: tomcat8 ClassCastException
On Tue, Oct 18, 2016 at 3:17 PM, musafir wrote: > Hey Guys, can you pls provide some suggestions..exact copy of > tomcat+webapp working fine on one machine..no issues in tomcat7with either > jdk7/8 > > > What java version and vendor are you using? Or are you using Scala or some other JVM based language? Because, as the error clearly states, casting a String to an Integer simply isn't valid code, at least not in genuine Oracle Java 8. My guess is you've got different versions of an external library somewhere on each VM. One VM has userprofilesettings.get() returning an Integer compatible value and one VM has a library where userprofilesettings.get() returns a String. Compare all your library JARs and see where the difference is. > > On Monday, October 17, 2016, musafir wrote: > > > Hi Apache Team, > > > > Got 2 tomcat hosting same web application. Tomcats are installed on > > dedicated centos(6.8) VMs. Everything was working fine in tomcat7 till > > upgrade to tomcat8(8.0.38). > > > > Now on one server, i am getting below error.. > > java.lang.ClassCastException: java.lang.String cannot be cast to > > java.lang.Integer > > > > e.g code iFacType = (Integer)userprofilesettings.get("facilityType"); > > > > Can you guys pls help understand > > a) why it happens only on one server . is it something to do non > > deterministic loader as reported in https://bz.apache.org/ > > bugzilla/show_bug.cgi?id=57129 > > b) Since its happening only on one server. is there any quick fix i can > > use..fyi,if i downgrade to tomcat 7 on VM, application works fine. > > > > > > Regards, neet. > > > > > > > > >
Re: Restrict access to manager app by IP
On Fri, Sep 2, 2016 at 4:28 AM, Yuval Schwartz wrote: > Tomcat: 8.0.22 > JDK: 1.8.0_05 > > Hello, > > I am currently running a web application. > > I would like to restrict access to the manager app (it is currently being > hit by spammers every so often who are unable to connect (get a message > "...an attempt was made to authenticate the locked user")). > > I was thinking of adding a "manager.xml" file to > $CATALINA_BASE/conf/[enginename]/[hostname]/ that will contain the > following context container: > > > allow="[my_ip]"/> > > > Is this the correct way to achieve my goal of limiting access to the > manager app to only my IP. > > Of course, I do not want the rest of my webapp's access limited (which > is on the ROOT path). I only want access to the manager app limited. > > (I know I can also place the context container in my webapp's > META-INF/context.xml file, is there any preference to doing this over > what I suggested above?) > > Thank you > _ > Another way to keep them from hammering away with login attempts is to simply rename the manager webapp. Redeploy it to something like /manager123 instead of just /manager and the bots will never find it. It's obviously security theater, but it works great against scanners.
Re: Unable to access Manager App, Host Manager and Server Status urls
Tried that but no charm as of yet. If I add comments like the one I have bold, I am unable to access tomcat manager.So I have to uncomment it. After uncomment. It says access denied... Take just this out of context.xml and restart Tomcat and your browser. ** Actually I don't know if restarting is necessary on either, but it can't hurt.
Re: Unable to access Manager App, Host Manager and Server Status urls
On Sun, Aug 14, 2016 at 1:43 AM, Andrew M wrote: > I tried disabling SE Linux but no charm :( > What is interesting is I have enabled finest level of debugging but I > cannot see anything in log files as ALL or finest level of logging. > Make sure if you have an address filter in webapps/manager/META-INF/context.xml that it's correct, and try removing or commenting it out temporarily even if it does look correct just in case. Since your first message was 18 hours ago, I'm assuming at some point you have closed and reopened your browser? On my systems, if I enter the wrong user or password to get into the management console I get the 403 and I can't get back to the login prompt without completely closing and restarting the browser. I don't know if that's intentional or just a side effect of Firefox and the various privacy extensions I use, never bothered to look for the cause. So, depending on your browser, try closing/restarting, clearing caches and active logins, even try from a different browser.
Re: Multipart form submission does not work over SSL HTTP2 on Tomcat 9
On Sat, Mar 19, 2016 at 2:21 PM, Ajay Verma wrote: > Hello, > I'm trying to get multipart forms working in Tomcat 9 over HTTP2 (with TLS > enabled). > > The SSL Connector configuration in server.xml (Tomcat 9) is given > below protocol="org.apache.coyote.http11.Http11AprProtocol" maxThreads="150" > SSLEnabled="true"> > > > certificateFile="conf/2_toeflmadeeasy.com.crt" /> > Multipart form submission does not work (the form > variable values are not retrieved on server in the servlet) with above > connector.The sample multipart form html code is given below name="multiPartForm" method="post" enctype="multipart/form-data"> > value="test"> > File 1: > File 2: > > > I am trying to get form parameters by using the > getParameter("form_submission_type") method on HttpServletRequest, and it > returns null under HTTP2. If I remove the line className="org.apache.coyote.http2.Http2Protocol" />) it works. But now I > am not on HTTP2. > > Anyone have any ideas how I can get it to work on HTTP2? > Thanks in advance for any suggestions and comments. > Ajay > I can't speak for Tomcat 9, but for T8 getParameter() won't work on a multi-part form. I vaguely recall there's a Tomcat way of getting the parameters, but I ended up using Apache's FileUpload library which will generate a list of files and parameters for the request. Though I have no idea if FileUpload will work with HTTP2 or not.
Re: Parameter handling on forward
On Wed, Jan 13, 2016 at 12:20 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > All, > For the benefit of the archives: > https://bz.apache.org/bugzilla/show_bug.cgi?id=58836 > > This issue was raised in BZ and will be fixed in Tomcat 8.0.31 as well > as others. See the bug for details. > > Thanks, Mark, for the bug report and the test case. > > -chris > > I'm relieved it was a real bug and not me doing something embarrassingly stupid.
Re: Parameter handling on forward
Adding = to a parameter does cause it to be available to the destination servlet, but that doesn't seem like a particularly good solution. A parameter without a value is technically a keyless value, not the other way around. But I'll stick to the servlet terminology of calling them parameter names and values since request.getParameterNames and getParameterMap both return them as "Names" and not a value without a name. Parameters without a value (keyless value) are widely used and within spec without having to add the =. I wrote a couple of servlets and have been able to narrow down the problem to take form POST data out of the equation, but not been able to find a solution yet. I'm even more convinced that getRequestDispatcher().forward() or the receiving servlet are borking the parameters. This works: Directly access /page1?a=1&b&c=3&d The request arrives at the servlet with all 4 parameters, a and c have values, b and d don't but are in the parameter names list. This doesn't work: request.getRequestDispatcher("/page1?a=1&b&c=3&d").forward(request, response); The request arrives at the servlet with only the parameters a and c, not b and d. All 4 parameters are in the query string, but b and d are not in the parameter names list or map. Seems to me that if the exact same servlet can accept parameters without a value on a direct request, but fails on only some parameters when it's from a request dispatcher that something is wrong where the parameters are gathered the second time, or somewhere before they are made available to the destination. On Mon, Jan 11, 2016 at 3:41 PM, Andreas Junius wrote: > Did you try: > > "/page2?foo=&bar=123" > > Normally parameters come as key/value pairs, separated by an equal sign. > > > > On 12/01/16 09:21, Mark Olsson wrote: > >> I'm getting unexpected parameter handling with a >> request.getRequestDispatcher().forward(). Not sure if this is a bug or >> I'm >> using gRD.f wrong, but here's the situation: >> >> A POST is made with form data to a servlet (didn't try with a multipart >> content, just regular) and the servlet decides to redirect to another >> servlet using request.getRequestDispatcher().forward(), but adds >> parameters >> on the new address. Address parameters with a value "asdf=123" *are* sent >> to the new servlet but parameters without a value *aren't*. >> >> Example: >> 1. POST made to page1 with parameters input1="asdf" and button1 (no >> value). >> 2. The servlet handling page1 redirects to page2 and adds 2 parameters: >> >> request.getRequestDispatcher("/page2?foo&bar=123").forward(request,response). >> 3. page2 gets the original parameters input1="asdf", button1, and new >> bar="123" but not foo. foo is in the browser address and is in the >> request >> query string, but it's not one of the parameters sent along with the >> request object. Neither request.getParameterNames() nor >> request.getParameter() will find "foo". It also doesn't appear in the >> list >> of parameters in Netbeans' server monitor. >> 4. Changing the order of the parameters (/page2?bar=123&foo) doesn't fix >> it, but adding a value to foo does (/page2?foo=x&bar=123). >> >> So what's up with valueless parameters on a servlet forward? >> >> Tomcat: 8.0.26 >> Java: 1.8.0_60 Oracle >> OS: Win7 and Linux 3.14.20-20.44.amzn1.x86_64 >> > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Parameter handling on forward
I'm getting unexpected parameter handling with a request.getRequestDispatcher().forward(). Not sure if this is a bug or I'm using gRD.f wrong, but here's the situation: A POST is made with form data to a servlet (didn't try with a multipart content, just regular) and the servlet decides to redirect to another servlet using request.getRequestDispatcher().forward(), but adds parameters on the new address. Address parameters with a value "asdf=123" *are* sent to the new servlet but parameters without a value *aren't*. Example: 1. POST made to page1 with parameters input1="asdf" and button1 (no value). 2. The servlet handling page1 redirects to page2 and adds 2 parameters: request.getRequestDispatcher("/page2?foo&bar=123").forward(request,response). 3. page2 gets the original parameters input1="asdf", button1, and new bar="123" but not foo. foo is in the browser address and is in the request query string, but it's not one of the parameters sent along with the request object. Neither request.getParameterNames() nor request.getParameter() will find "foo". It also doesn't appear in the list of parameters in Netbeans' server monitor. 4. Changing the order of the parameters (/page2?bar=123&foo) doesn't fix it, but adding a value to foo does (/page2?foo=x&bar=123). So what's up with valueless parameters on a servlet forward? Tomcat: 8.0.26 Java: 1.8.0_60 Oracle OS: Win7 and Linux 3.14.20-20.44.amzn1.x86_64