Hi Mark,

On Tue, 4 Jun 2024 at 15:50, Mark Thomas <ma...@apache.org> wrote:

> On 04/06/2024 05:07, Tom Robinson wrote:
> > Hi,
> >
> > We are running a tomcat7 application
>
> You do realise that support for Tomcat 7 ended on 31 March 2021 don't you?
>

Yes, I do realise that tomcat7 is very old. We are running a legacy
application not of our design.

> on our LAN which gets redirected from
> > a private, internal IP Address to an external ip address at which point
> it
> > fails. I can't find where this is happening.
>
> Is it an actual redirect - i.e. a 30x response? Or do you mean something
> else?
>
> If a redirect, does it redirect on the first request?
>

OK, you are right, it's not a redirect (not a 30x response). I didn't think
to go into developer mode on the browser to check this until now.

> Where and what can I check for this redirect and how to control it or
> > switch it off all together.
>
> Tomcat doesn't do this by default.
>
> Tomcat 7 doesn't have the redirect valve so it won't be that.
>
> Are you sure that the redirect is being issued by Tomcat? Might there be
> a reverse proxy in mix somewhere?
>

No reverse proxies configured that I specifically know about.


> Other than that, it would have to be in the application code somewhere.
>

In that case it must be as you say; i.e. in the code somewhere.


> > I browse to here on our LAN:
> >
> > https://myinternalhost.mydomain.com.au:8443
>
> Check what myinternalhost.mydomain.com.au resolves to in terms of an IP
> address.
>

Amongst other things, I administer the network, DNS and DHCP so I know that
the name resolution is correct. I have re-checked to confirm.

Try requesting a page that won't trigger a directory redirect. Something
> like:
>
> https://myinternalhost.mydomain.com.au:8443/index.html
>
> You may need to adjust that for your application.
>

I found this in tomcat7/webapps/index.jsp:

# cat index.jsp
<%@ taglib uri="/tags/struts-logic" prefix="logic" %>

<logic:redirect forward="logon"/>

That's the entire file! I'm not really clued in to how that works but it
does look like a code based redirect.

This whole query has come about because I've been trying to secure the
tomcat webapps with SSL. The certificate management in java is challenging
having to use yet another certificate management tool (keytool).

I realise now that I've just browsed to a default webapp running on tomcat.
Further investigation shows that the other webapps (some 17 separate
webapps) are indeed working correctly and SSL secured. I think I just
panicked a little seeing the 'redirect' to an external IP and got
bogged down unnecessarily into that redirect.

For example, if I browse to:

https://myinternalhost.mydomain.com.au:8443/legacyapp1

the webapp runs, there is no redirect and it's SSL secured. The same for
legacyapp[2-17].

I appreciate and thank you for your help.

Kind regards,
Tom


>
> > I end up here:
> >
> > https://a.b.c.d:8443/kb
> >
> > Where a.b.c.d is our external, ISP provided IP Address.
> >
> > Why is this happening and how can I fix it?
> >
> > *Kind regards,*
> >
> > *Tom Robinson*
> > *IT Manager/System Administrator*
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
*MoTeC Pty Ltd*

121 Merrindale Drive
Croydon South 3136
Victoria Australia
*T: *61 3 9761 5050
*W: *www.motec.com.au <https://www.motec.com.au/>


-- 
 <http://www.facebook.com/motec.global> 
<http://www.youtube.com/user/MoTeCAustralia> 
<https://www.instagram.com/motec_global/> 
<https://www.linkedin.com/company/motec-global>


-- 
 <https://www.thebatteryshow.eu/en/home.html>

-- 


Disclaimer Notice: This message, including any attachments, contains 
confidential information intended for a specific individual and purpose and 
is protected by law. If you are not the intended recipient you should 
delete this message. Any disclosure, copying, or distribution of this 
message or the taking of any action based on it is strictly prohibited.

Reply via email to