Re: tomcat8 ClassCastException

[Mark Olsson]

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

[Mark Olsson]

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

[Mark Olsson]

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

[Mark Olsson]

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

[Mark Olsson]

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

[Mark Olsson]

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.

Parameter handling on forward

[Mark Olsson]

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=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) doesn't fix
it, but adding a value to foo does (/page2?foo=x=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

Re: Parameter handling on forward

[Mark Olsson]

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=3
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=3").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 <andr...@junius.info> wrote:

> Did you try:
>
> "/page2?foo==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=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) doesn't fix
>> it, but adding a value to foo does (/page2?foo=x=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
>
>