Re: HTTP to HTTPS redirect not happening
Richard, I think the rule goes that you should avoid touching server.xml for something that web.xml can do. On Sun, Jul 21, 2019 at 4:40 AM Richard Huntrods wrote: > > I apologise for top posting in advance, but just a quick update and > quicker question... > > After Konstantin found my typo, I tried editing the global web.xml file > (/conf/web.xml) . In my case, this is actually the file I want based on > the behaviour described by Konstantin as this entire tomcat instance is > for this one application and it's static web pages, so *everything* > needs to have the redirect. > > After fixing the typo, I tried it again and it works perfectly. > > So now I have two ways to accomplish what I want: > 1. Edit /conf/web.xml and add the lines. > > 2. Edit server.xml and add the RewriteValve line, then create > rewrite.config in /conf/Catalina/localhost. > > So my question - which is considered "more elegant" or better, more > appropriate appoach - the valve or the change to web.xml? > > I'm leaning towards the valve simply because I kind of like the whole > concept of valves, but if editing web.xml is just as good... ? > > Thanks, > > -Richard > > > On 7/20/2019 2:08 PM, Richard Huntrods wrote: > > Sorry for top-posting. It's the default with my mail program > > (thunderbird)... > > > > On 7/20/2019 11:27 AM, Konstantin Kolinko wrote: > >> сб, 20 июл. 2019 г. в 17:47, Richard Huntrods : > >>> OK. That was really weird. > >>> > >>> As I said in my message, following the directions on the web did NOT > >>> work. It didn't force redirection from http to https. > >>> > >>> What it DID end up doing was to kill the tomcat servlet application. > >>> Before the change it was working fine, and after the change it would > >>> only generate a 404 page. > >>> > >>> I reverted to the original /conf/web.xml, restarted tomcat and the > >>> servlet application is back up and running perfectly. > >>> > >>> So this code in /conf/web.xml affected the servlet but not the ROOT > >>> static web pages. > >> 1. The web.xml file and its behavior are defined in the Servlet > >> Specification. > >> > >> Some random instructions on the net have to be used carefully. > >> > >> 2. The web.xml file is the one in your web application > >> (WEB-INF/web.xml). > >> > >> The /conf/web.xml file provides defaults for all web applications, and > >> SHOULD not be edited. (The /conf/context.xml should not be exited as > >> well. That is another frequent error.). > >> > >> Those defaults are merged with the web.xml file of your web > >> application using merging rules defined in the Servlet Specification. > >> > >> There is an option, "logEffectiveWebXml" [1] that turns on logging of > >> the merged web.xml file. > > I still am having trouble understanding why the web application's > > WEB-INF/web.xml would be the appropriate place to put the change when > > I want to affect ROOT. I would have thought > > webapps/ROOT/WEB-INF/web.xml would have been the correct one. > >> > >> 3. Beware of typos. > >> > >> The tag "" is misspelled. > > > > AARRR > > > > TYPOS > > > > And I checked that code several times before implementing it. Of > > course it wouldn't work 'as designed'. Ouch. > > > > I can clearly see why 'fixing stuff' using that code would generate > > the 404 errors I was seeing. That does prove I was editing the correct > > web.xml files, at least. Since the typo was in the block that then > > defined the url-pattern, messing that up would mess up everything. > > > > One person asked what the logs said. Nothing. Start up log was normal, > > access log was normal. > > > >> > >> There is an option, "xmlValidation" [1] that turns on automatic > >> validation of web.xml against the XML schema specified in that file. > >> > >> (Personally, I usually run with > >> org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true > >> and that turns "xmlValidation" on as well). > >> > >> 4. Top-posting is bad. > > > > Again, sorry. In the end I solved it using a Rewritevalve instead of > > web.xml, and I think that may be the more elegant solution. Certainly > > it's cleaner - edit server.xml and add one file, rewrite.config. That > > takes care of everywhere; both the static pages I started wanting to > > fix, and also the servlet application which I discovered could be > > forced to run http when I was testing. This fixes all. > > > > One last point. I started this particular application for a client > > back in early 2001. At that time I was considered a maverick for > > choosing open source (Tomcat, MySQL) over the then-ubiquitous > > proprietary solutions "everyone" was using. I even got to speak at > > Unix user groups at the time, and even spoke at a CIPS meeting in > > August 2001 (Montreal, PQ, Canada) on the use of open source for > > enterprise solutions. > > > > Mostly folks simply didn't want to believe it could be done. > > > > Fast forward to 2019, when Tomcat & Mysql/MariaDB are now often the > > ubiquitous choices, with proprietary
Re: HTTP to HTTPS redirect not happening
I apologise for top posting in advance, but just a quick update and quicker question... After Konstantin found my typo, I tried editing the global web.xml file (/conf/web.xml) . In my case, this is actually the file I want based on the behaviour described by Konstantin as this entire tomcat instance is for this one application and it's static web pages, so *everything* needs to have the redirect. After fixing the typo, I tried it again and it works perfectly. So now I have two ways to accomplish what I want: 1. Edit /conf/web.xml and add the lines. 2. Edit server.xml and add the RewriteValve line, then create rewrite.config in /conf/Catalina/localhost. So my question - which is considered "more elegant" or better, more appropriate appoach - the valve or the change to web.xml? I'm leaning towards the valve simply because I kind of like the whole concept of valves, but if editing web.xml is just as good... ? Thanks, -Richard On 7/20/2019 2:08 PM, Richard Huntrods wrote: > Sorry for top-posting. It's the default with my mail program > (thunderbird)... > > On 7/20/2019 11:27 AM, Konstantin Kolinko wrote: >> сб, 20 июл. 2019 г. в 17:47, Richard Huntrods : >>> OK. That was really weird. >>> >>> As I said in my message, following the directions on the web did NOT >>> work. It didn't force redirection from http to https. >>> >>> What it DID end up doing was to kill the tomcat servlet application. >>> Before the change it was working fine, and after the change it would >>> only generate a 404 page. >>> >>> I reverted to the original /conf/web.xml, restarted tomcat and the >>> servlet application is back up and running perfectly. >>> >>> So this code in /conf/web.xml affected the servlet but not the ROOT >>> static web pages. >> 1. The web.xml file and its behavior are defined in the Servlet >> Specification. >> >> Some random instructions on the net have to be used carefully. >> >> 2. The web.xml file is the one in your web application >> (WEB-INF/web.xml). >> >> The /conf/web.xml file provides defaults for all web applications, and >> SHOULD not be edited. (The /conf/context.xml should not be exited as >> well. That is another frequent error.). >> >> Those defaults are merged with the web.xml file of your web >> application using merging rules defined in the Servlet Specification. >> >> There is an option, "logEffectiveWebXml" [1] that turns on logging of >> the merged web.xml file. > I still am having trouble understanding why the web application's > WEB-INF/web.xml would be the appropriate place to put the change when > I want to affect ROOT. I would have thought > webapps/ROOT/WEB-INF/web.xml would have been the correct one. >> >> 3. Beware of typos. >> >> The tag "" is misspelled. > > AARRR > > TYPOS > > And I checked that code several times before implementing it. Of > course it wouldn't work 'as designed'. Ouch. > > I can clearly see why 'fixing stuff' using that code would generate > the 404 errors I was seeing. That does prove I was editing the correct > web.xml files, at least. Since the typo was in the block that then > defined the url-pattern, messing that up would mess up everything. > > One person asked what the logs said. Nothing. Start up log was normal, > access log was normal. > >> >> There is an option, "xmlValidation" [1] that turns on automatic >> validation of web.xml against the XML schema specified in that file. >> >> (Personally, I usually run with >> org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true >> and that turns "xmlValidation" on as well). >> >> 4. Top-posting is bad. > > Again, sorry. In the end I solved it using a Rewritevalve instead of > web.xml, and I think that may be the more elegant solution. Certainly > it's cleaner - edit server.xml and add one file, rewrite.config. That > takes care of everywhere; both the static pages I started wanting to > fix, and also the servlet application which I discovered could be > forced to run http when I was testing. This fixes all. > > One last point. I started this particular application for a client > back in early 2001. At that time I was considered a maverick for > choosing open source (Tomcat, MySQL) over the then-ubiquitous > proprietary solutions "everyone" was using. I even got to speak at > Unix user groups at the time, and even spoke at a CIPS meeting in > August 2001 (Montreal, PQ, Canada) on the use of open source for > enterprise solutions. > > Mostly folks simply didn't want to believe it could be done. > > Fast forward to 2019, when Tomcat & Mysql/MariaDB are now often the > ubiquitous choices, with proprietary solutions are used mostly where > upper management has bought the FUD. > > A lot has changed in Tomcat in that time; in Unix as well. I started > with Solaris 8, then Solaris 10, and more recently Ubuntu. I love the > way things have gotten better. > > More than that, I try to "keep up" with changes in security and > overall robustness and best practices. I did just update from Tomcat > 8.5.41
Re: Re: HTTP to HTTPS redirect not happening
Sorry for top-posting. It's the default with my mail program (thunderbird)... On 7/20/2019 11:27 AM, Konstantin Kolinko wrote: > сб, 20 июл. 2019 г. в 17:47, Richard Huntrods : >> OK. That was really weird. >> >> As I said in my message, following the directions on the web did NOT >> work. It didn't force redirection from http to https. >> >> What it DID end up doing was to kill the tomcat servlet application. >> Before the change it was working fine, and after the change it would >> only generate a 404 page. >> >> I reverted to the original /conf/web.xml, restarted tomcat and the >> servlet application is back up and running perfectly. >> >> So this code in /conf/web.xml affected the servlet but not the ROOT >> static web pages. > 1. The web.xml file and its behavior are defined in the Servlet Specification. > > Some random instructions on the net have to be used carefully. > > 2. The web.xml file is the one in your web application (WEB-INF/web.xml). > > The /conf/web.xml file provides defaults for all web applications, and > SHOULD not be edited. (The /conf/context.xml should not be exited as > well. That is another frequent error.). > > Those defaults are merged with the web.xml file of your web > application using merging rules defined in the Servlet Specification. > > There is an option, "logEffectiveWebXml" [1] that turns on logging of > the merged web.xml file. I still am having trouble understanding why the web application's WEB-INF/web.xml would be the appropriate place to put the change when I want to affect ROOT. I would have thought webapps/ROOT/WEB-INF/web.xml would have been the correct one. > > 3. Beware of typos. > > The tag "" is misspelled. AARRR TYPOS And I checked that code several times before implementing it. Of course it wouldn't work 'as designed'. Ouch. I can clearly see why 'fixing stuff' using that code would generate the 404 errors I was seeing. That does prove I was editing the correct web.xml files, at least. Since the typo was in the block that then defined the url-pattern, messing that up would mess up everything. One person asked what the logs said. Nothing. Start up log was normal, access log was normal. > > There is an option, "xmlValidation" [1] that turns on automatic > validation of web.xml against the XML schema specified in that file. > > (Personally, I usually run with > org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true > and that turns "xmlValidation" on as well). > > 4. Top-posting is bad. Again, sorry. In the end I solved it using a Rewritevalve instead of web.xml, and I think that may be the more elegant solution. Certainly it's cleaner - edit server.xml and add one file, rewrite.config. That takes care of everywhere; both the static pages I started wanting to fix, and also the servlet application which I discovered could be forced to run http when I was testing. This fixes all. One last point. I started this particular application for a client back in early 2001. At that time I was considered a maverick for choosing open source (Tomcat, MySQL) over the then-ubiquitous proprietary solutions "everyone" was using. I even got to speak at Unix user groups at the time, and even spoke at a CIPS meeting in August 2001 (Montreal, PQ, Canada) on the use of open source for enterprise solutions. Mostly folks simply didn't want to believe it could be done. Fast forward to 2019, when Tomcat & Mysql/MariaDB are now often the ubiquitous choices, with proprietary solutions are used mostly where upper management has bought the FUD. A lot has changed in Tomcat in that time; in Unix as well. I started with Solaris 8, then Solaris 10, and more recently Ubuntu. I love the way things have gotten better. More than that, I try to "keep up" with changes in security and overall robustness and best practices. I did just update from Tomcat 8.5.41 to 9.0.22 on Wednesday. It went without a hitch and took about 30 minutes total, including testing on the devel server. Basically it was easy because I try and keep things up to date. But... there are still places where legacy code lives in the application. Sadly, I'm one developer and it was a pretty big system. I tend to be proactive, but only if I think the benefit can really justify the time spent figuring it all out. Cheers, -Richard > [1] http://tomcat.apache.org/tomcat-9.0-doc/config/context.html > > Best regards, > Konstantin Kolinko > --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- This communication is intended for the use of the recipient to whom it is addressed, and may contain confidential, personal, and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communications received in error, or subsequent reply, should be deleted or destroyed. ---
Re: Re: HTTP to HTTPS redirect not happening
Thanks. However, what I don't understand is why putting that code into the
webapps WEB-INF/web.xml would cause the behaviour I want in ROOT.
Sadly, this is a production server and I can't play with it except after hours.
EDIT. I tried working with web.xml on my development server, and could not get
it to work, no matter which web.xml I used. In fact, whenever I edited the
'correct' web.xml, I immediately started getting '404' errors. If I removed the
changes and restarted, the errors went away.
So I tried something different after re-checking the internet. My original info
came from here:
https://gist.github.com/jtgasper3/10501274
after typing "force tomcat http to https" the above link was one, and the one
I'd used to originally edit tomcat/conf/web.xml.
The following bit caught my eye:
albertus82 commented on Oct 31, 2018
Some applications don't work correctly with that security-constraint, so I
followed a completely different approach:
Edit conf/server.xml and add the following element into :
Create the file conf/Catalina/localhost/rewrite.config:
RewriteCond %{HTTPS} =off
RewriteRule ^(.*) https://%{HTTP_HOST}:443$1 [R=301]
I tried that on localhost (devel box) and it didn't work at first, but only
because I did not have port 80 'turned on' on that machine. Once I did that it
worked.
I then implemented the above 'fix' in the production conf/server.xml and
conf/Catalina/localhost and after restarting tomcat, ALL PAGES redirect from
http to https as I had wanted. I even put the web pages back to just using
index.html (moral: always make backups before you start doing stuff!).
On reflection, I do think the valve was the more appropriate way to tackle this
problem, so I'm very happy with the solution.
-R
On 7/20/2019 3:48 AM, logo wrote:
Richard,
Am 20.07.2019 um 04:19 schrieb Richard Huntrods
:
I tried implementing automatic redirection from HTTP to HTTPS on my
tomcat today, but it's not working.
First, my system:
OS: Ubuntu 18.04.2 LTS (server)
Tomcat: 9.0.22 (installed from tomcat distribution, not via apt get)
Java: OpenJDK "11.0.3" 2019-04-16
Mysql: Ver 14.14 Distrib 5.7.26
This web application has it's own domain (let's call it "mydomain.com" )
and has working HTTPS - and has done for some time now.
Static web pages are served on this application via tomcat using the
ROOT directory ../tomcat/webapps/ROOT
Again, this is working just fine. If I type
"https://mydomain.com; I see
the secure static pages. If I type "http://mydomain.com; I
see the same
pages, but browsers inform me the page isn't secure.
I want to force tomcat to redirect "http://mydomain.com; to
"https://mydomain.com; always.
I found instructions for auto-redirection on several on-line sites, and
all had the same instructions.
I already have the redirect code in server.xml:
So all I had to add (according to the instructions) was code at the end
of ...tomcat/conf/web.xml
Secured
/*
CONFIDENTIAL
just before the final
This should go into your webapp's WEB-INF/web.xml! Not the tomcat/conf!
Hope this helps,
Peter
I did this and restarted tomcat. It doesn't work.
After restarting tomcat, if I type in
"http://mydomain.com; I still see
the unsecured version. It does not auto-redirect to https.
What am I missing?
Thanks,
-Richard
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
This communication is intended for the use of the recipient to whom it is
addressed, and may contain confidential, personal, and or privileged
information. Please contact us immediately if you are not the intended
recipient of this communication, and do not copy, distribute, or take action
relying on it. Any communications received in error, or subsequent reply,
should be deleted or destroyed.
---
-
To unsubscribe, e-mail:
users-unsubscr...@tomcat.apache.org
For additional commands, e-mail:
users-h...@tomcat.apache.org
[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]
Virus-free.
www.avast.com
--
This communication is intended for the use of the recipient to whom it is
addressed, and may contain confidential, personal, and or privileged
information. Please contact us immediately if you are not the intended
recipient of this communication, and do not copy, distribute, or take action
relying on it. Any communications received
Re: WAR file not deploying correctly
пт, 19 июл. 2019 г. в 12:47, Victor WILLART : > > Hi everybody, > > > I am using Tomcat 8.0, and I am struggling to replace and deploy a WAR file. > Tomcat 8.0 has reached End of Life and should not be used anymore. The replacements are Tomcat 8.5 and 9.0. > > I made a new WAR file, named it like the old one, and replaced it in my > webapps folder. But the new generated folder for my application is just > containing a single folder "config" which is empty. All the other folders and > files are missing … I tried also to deploy it through the Tomcat Manager and > it happened the same. > > > I don't think my war file is wrong since I have a back up folder of my app > that was working perfectly before trying this, and the back up WAR file isn't > working neither. Only replacing the deployed folder by the deployed folder > from back up makes my app work again correctly. > > > If you have any hints or guesses about this, I would gladly try them. > 1. A WAR file is effectively a ZIP archive (with minor differences like using UTF-8 to encode file names). The first thing Tomcat does when you deploy the web application is to unpack the file. You can perform this step manually using the "jar"utility from JDK. If you unpack the file manually, you would better remove the war file from the webapps directory (or at least rename its extension), so that auto-deployment does not interfere. It may be that your war file is broken, or does not contain anything besides the "config" directory. The "t" command of the jar utility can be used to test the war file and to list its contents (as suggested by Christopher). 2. When you undeploy a web application, make sure that all its files (in webapps and in work directory) are removed. The "config" directory may remain from an incomplete undeployment. E.g. if the files in the config directory are owned by root user and cannot be deleted by the user running Apache Tomcat. 3. I hope that you do not run two copies of Tomcat over the same webapps directory at the same time. 4. Read the logs. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTP to HTTPS redirect not happening
сб, 20 июл. 2019 г. в 17:47, Richard Huntrods : > > OK. That was really weird. > > As I said in my message, following the directions on the web did NOT > work. It didn't force redirection from http to https. > > What it DID end up doing was to kill the tomcat servlet application. > Before the change it was working fine, and after the change it would > only generate a 404 page. > > I reverted to the original /conf/web.xml, restarted tomcat and the > servlet application is back up and running perfectly. > > So this code in /conf/web.xml affected the servlet but not the ROOT > static web pages. 1. The web.xml file and its behavior are defined in the Servlet Specification. Some random instructions on the net have to be used carefully. 2. The web.xml file is the one in your web application (WEB-INF/web.xml). The /conf/web.xml file provides defaults for all web applications, and SHOULD not be edited. (The /conf/context.xml should not be exited as well. That is another frequent error.). Those defaults are merged with the web.xml file of your web application using merging rules defined in the Servlet Specification. There is an option, "logEffectiveWebXml" [1] that turns on logging of the merged web.xml file. 3. Beware of typos. The tag "" is misspelled. There is an option, "xmlValidation" [1] that turns on automatic validation of web.xml against the XML schema specified in that file. (Personally, I usually run with org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true and that turns "xmlValidation" on as well). 4. Top-posting is bad. [1] http://tomcat.apache.org/tomcat-9.0-doc/config/context.html Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: OT: Tomcat on AWS for Dummies
Chris, > Jerry, > >> On 7/19/19 13:38, Jerry Malcolm wrote: > I have had a dedicated hosted environment with WAMP and > Tomcat for over 15 years. I'm very familiar with everything > related to that environment... apache http, mysql, dns > server, the file system, JAMES, and all of my management > scripts that I've accumulated over the years. Everything is > in the same box and basically on the same desktop. But now I > have a client that has needs that are best met in an AWS > environment. >> Can you explain that in a little more depth? What is it about AWS >> that meets their needs better? > >> I ask because you can provision a one-box wonder in AWS just like >> you do on a physical space with a single server. You just have to >> use remote-desktop to get into it, and then it's all the same. > >> But if they want to use RDS, auto-scaling, and other >> Amazon-provided services then things can get confusing. >>> Unfortunately, that is the precise reason we need to go AWS >>> Extremely high availability and scalability / load-balancing >>> across multiple instances. There will need to at least one >>> instance running at all times. Even when doing >>> maintenance/upgrades on other instances. > > It's not "unfortunate" necessarily. At least it makes it clear why > they want to migrate to AWS. > >> So the answer to your question really depends upon what the client >> thinks they'll be getting by you taking your existing product "to >> the cloud". > > I understand just enough AWS to be dangerous, which is not > much I do know that it's a bunch of different modules, > and I believe I lose the direct file system access. >> That heavily depends upon how you do things. You can get yourself >> a server with a disk and everything, just like you are used to >> doing. >>> Do you mean AWS offers a 'file server' module that I can >>> basically access directly as a drive from TC? If so, that eases >>> my mind a bunch. I manage and serve gigabytes of videos and >>> photos. I don't really want a full CMS implementation. Just >>> want a big hard drive I can get to. > > No, AWS doesn't really have a "file server" module that you can > enable. Do you need a large disk for bulk storage? What are you > storing? Perhaps switching over to a key-value store (which can act > like a filesystem) or a document-store database (e.g. CouchDB) if you > have fairly regular documents that you want to store. All of those > technologies are quite cloud-friendly. You can even use them > single-node if you want to make your application available to either > AWS-based clients OR your more traditional one-box-wonder clients. Or, > you can abstract your "write a file somewhere" process so that you can > swap implementations at run-time: configuration says local-disk? Use > FileWriter. Using CouchDB? Push the file to CouchDB through it's APIs. > What about using EFS (NFS store) in this environment? For Windows, an NFS client would have to be installed, but that doesn't seem like much of a barrier. > > I've watched an AWS intro video and a couple of youtube > videos on setting up TC in AWS. But they always starts with > "now that you have your AWS environment set up". I am > looking for something that explains the big picture of > migrating an existing WAMP+TC to AWS. I am not so naive to > think that there won't be significant rip-up to what I have > now. But I don't want to do unnecessary rip-up just because I > don't understand where I'm heading. Basically, I don't know > enough to know what I don't know But I need to start > planning ahead and learning soon if I'm going to have any > disasters in my code where I might have played it too loose > with accessing the file system directly in my dedicated > environment. > > Has anyone been down this path before and could point me to > some tutorials targeted to migrating WAMP+TC to AWS? Or > possible hand-hold me just a little...? I'm a pretty quick > learner. I just don't know where to start. >> As usual, start with your requirements :) > >>> Requirements are what I have now in a single box, but with the >>> addition of multiple instances of TC (and HTTPD and/or mySQL?) >>> for HA and load balancing. > > One box with multi is ... not HA. Sorry. That allows you to do things > like upgrade the application without taking it down completely. But it > does not allow you to perform maintenance on the OS because everything > has to come down. > >>> Day-1 launch won't be massive traffic and theoretically could be >>> handled by my single dedicated server I have today. But if this >>> takes off like the client predicts, I don't want to get caught >>> flat-footed and have to throw together an emergency redesign to >>> begin clustering TC to handle the traffic. Rather go live >>> initially with single instance AWS, but with a thought-out (and >>>
Re: HTTP to HTTPS redirect not happening
Fixed it by brute force. First, I tried putting the changes ONLY in ../tomcat/webapps/ROOT/WEB-INF/web.xml instead of ../tomcat/conf/web.xml The good news is that didn't affect the servlet application. The bad news is now the http://mydomain.com/ started getting the 404 error. So I undid that and the error went away. That led me to the brute force approach. The application (servlets on tomcat) has a large set of static web pages that are used as promotional material for the application. In the early days this was on a different apache server, but over the years (and due to colocation costs) migrated to the ROOT directory of tomcat. It's always worked just fine, so why mess with stuff that's working and not 'wrong'. There are about a dozen html pages and lots of other files, but only the dozen html pages matter. They all have a single link (via tabbed menu) to "index.html". It was not difficult to rename index.html to be home.html and change all the links (took all of 10 min total). I then created a new index.html with the single key line in : https://mydomain.com/home.html;> This line I've used before in other java servlet/tomcat applications when I really want http://mydomain.com to automatically redirect to the servlet application (I change home.html to the servlet URL). It works. After making this change - and I didn't even have to restart tomcat - it now works perfectly. Eventually I'll figure out what I did wrong trying to use web.xml to do the above auto-redirection, but this works and is simple. -R On 7/20/2019 7:47 AM, Richard Huntrods wrote: > OK. That was really weird. > > As I said in my message, following the directions on the web did NOT > work. It didn't force redirection from http to https. > > What it DID end up doing was to kill the tomcat servlet application. > Before the change it was working fine, and after the change it would > only generate a 404 page. > > I reverted to the original /conf/web.xml, restarted tomcat and the > servlet application is back up and running perfectly. > > So this code in /conf/web.xml affected the servlet but not the ROOT > static web pages. > > I'm thinking I need to make the change I noted, but in ROOT/web.xml > instead. I'll try that today. But it was weird that the change in > /conf/web.xml killed the servlet but didn't affect the ROOT static > pages at all. Especially weird since the servlet application ONLY > runs on port 443 (https). > > -R > > On 7/19/2019 7:18 PM, Richard Huntrods wrote: >> I tried implementing automatic redirection from HTTP to HTTPS on my >> tomcat today, but it's not working. >> >> First, my system: >> OS: Ubuntu 18.04.2 LTS (server) >> Tomcat: 9.0.22 (installed from tomcat distribution, not via apt get) >> Java: OpenJDK "11.0.3" 2019-04-16 >> Mysql: Ver 14.14 Distrib 5.7.26 >> >> This web application has it's own domain (let's call it >> "mydomain.com" ) and has working HTTPS - and has done for some time >> now. >> >> Static web pages are served on this application via tomcat using the >> ROOT directory ../tomcat/webapps/ROOT >> >> Again, this is working just fine. If I type "https://mydomain.com; I >> see the secure static pages. If I type "http://mydomain.com; I see >> the same pages, but browsers inform me the page isn't secure. >> >> I want to force tomcat to redirect "http://mydomain.com; to >> "https://mydomain.com; always. >> >> I found instructions for auto-redirection on several on-line sites, >> and all had the same instructions. >> >> I already have the redirect code in server.xml: >> >> >connectionTimeout="2" >>redirectPort="443" /> >> >> So all I had to add (according to the instructions) was code at the >> end of ...tomcat/conf/web.xml >> >> >> >> Secured >> /* >> >> >> CONFIDENTIAL >> >> >> >> just before the final >> >> I did this and restarted tomcat. It doesn't work. >> >> After restarting tomcat, if I type in "http://mydomain.com; I still >> see the unsecured version. It does not auto-redirect to https. >> >> What am I missing? >> >> Thanks, >> -Richard --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- This communication is intended for the use of the recipient to whom it is addressed, and may contain confidential, personal, and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communications received in error, or subsequent reply, should be deleted or destroyed. --- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTP to HTTPS redirect not happening
Richard, > Am 20.07.2019 um 16:47 schrieb Richard Huntrods : > > OK. That was really weird. > > As I said in my message, following the directions on the web did NOT > work. It didn't force redirection from http to https. > > What it DID end up doing was to kill the tomcat servlet application. > Before the change it was working fine, and after the change it would > only generate a 404 page. > > I reverted to the original /conf/web.xml, restarted tomcat and the > servlet application is back up and running perfectly. > > So this code in /conf/web.xml affected the servlet but not the ROOT > static web pages. > > I'm thinking I need to make the change I noted, but in ROOT/web.xml > instead. I'll try that today. But it was weird that the change in > /conf/web.xml killed the servlet but didn't affect the ROOT static pages > at all. Especially weird since the servlet application ONLY runs on > port 443 (https). > Be careful where you put that element. If I remember correctly the order of the elements for web.xml is quite picky (at least it was when I added it a couple of years ago). In my app this goes right after welcome-file-list and before error-page. The error log should you show the reason why the app does not start or start incomplete. Peter > -R > > On 7/19/2019 7:18 PM, Richard Huntrods wrote: >> I tried implementing automatic redirection from HTTP to HTTPS on my >> tomcat today, but it's not working. >> >> First, my system: >> OS: Ubuntu 18.04.2 LTS (server) >> Tomcat: 9.0.22 (installed from tomcat distribution, not via apt get) >> Java: OpenJDK "11.0.3" 2019-04-16 >> Mysql: Ver 14.14 Distrib 5.7.26 >> >> This web application has it's own domain (let's call it "mydomain.com" >> ) and has working HTTPS - and has done for some time now. >> >> Static web pages are served on this application via tomcat using the >> ROOT directory ../tomcat/webapps/ROOT >> >> Again, this is working just fine. If I type "https://mydomain.com; I >> see the secure static pages. If I type "http://mydomain.com; I see the >> same pages, but browsers inform me the page isn't secure. >> >> I want to force tomcat to redirect "http://mydomain.com; to >> "https://mydomain.com; always. >> >> I found instructions for auto-redirection on several on-line sites, >> and all had the same instructions. >> >> I already have the redirect code in server.xml: >> >> > connectionTimeout="2" >> redirectPort="443" /> >> >> So all I had to add (according to the instructions) was code at the >> end of ...tomcat/conf/web.xml >> >> >> >> Secured >> /* >> >> >> CONFIDENTIAL >> >> >> >> just before the final >> >> I did this and restarted tomcat. It doesn't work. >> >> After restarting tomcat, if I type in "http://mydomain.com; I still >> see the unsecured version. It does not auto-redirect to https. >> >> What am I missing? >> >> Thanks, >> -Richard > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > -- > This communication is intended for the use of the recipient to whom it is > addressed, and may contain confidential, personal, and or privileged > information. Please contact us immediately if you are not the intended > recipient of this communication, and do not copy, distribute, or take action > relying on it. Any communications received in error, or subsequent reply, > should be deleted or destroyed. > --- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > smime.p7s Description: S/MIME cryptographic signature
Re: HTTP to HTTPS redirect not happening
OK. That was really weird. As I said in my message, following the directions on the web did NOT work. It didn't force redirection from http to https. What it DID end up doing was to kill the tomcat servlet application. Before the change it was working fine, and after the change it would only generate a 404 page. I reverted to the original /conf/web.xml, restarted tomcat and the servlet application is back up and running perfectly. So this code in /conf/web.xml affected the servlet but not the ROOT static web pages. I'm thinking I need to make the change I noted, but in ROOT/web.xml instead. I'll try that today. But it was weird that the change in /conf/web.xml killed the servlet but didn't affect the ROOT static pages at all. Especially weird since the servlet application ONLY runs on port 443 (https). -R On 7/19/2019 7:18 PM, Richard Huntrods wrote: > I tried implementing automatic redirection from HTTP to HTTPS on my > tomcat today, but it's not working. > > First, my system: > OS: Ubuntu 18.04.2 LTS (server) > Tomcat: 9.0.22 (installed from tomcat distribution, not via apt get) > Java: OpenJDK "11.0.3" 2019-04-16 > Mysql: Ver 14.14 Distrib 5.7.26 > > This web application has it's own domain (let's call it "mydomain.com" > ) and has working HTTPS - and has done for some time now. > > Static web pages are served on this application via tomcat using the > ROOT directory ../tomcat/webapps/ROOT > > Again, this is working just fine. If I type "https://mydomain.com; I > see the secure static pages. If I type "http://mydomain.com; I see the > same pages, but browsers inform me the page isn't secure. > > I want to force tomcat to redirect "http://mydomain.com; to > "https://mydomain.com; always. > > I found instructions for auto-redirection on several on-line sites, > and all had the same instructions. > > I already have the redirect code in server.xml: > > connectionTimeout="2" >redirectPort="443" /> > > So all I had to add (according to the instructions) was code at the > end of ...tomcat/conf/web.xml > > > > Secured > /* > > > CONFIDENTIAL > > > > just before the final > > I did this and restarted tomcat. It doesn't work. > > After restarting tomcat, if I type in "http://mydomain.com; I still > see the unsecured version. It does not auto-redirect to https. > > What am I missing? > > Thanks, > -Richard --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- This communication is intended for the use of the recipient to whom it is addressed, and may contain confidential, personal, and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communications received in error, or subsequent reply, should be deleted or destroyed. --- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Security vulnerabilities with tomcat 9
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sumit, On 7/20/19 08:47, Sumit Bhardwaj wrote: > Hi, > > We are using tomcat 9 and getting following two vulnerabilities in > security scans. > > Cookie Does Not Contain The "secure" Attribute (1) Cookie Does Not > Contain The "HTTPOnly" Attribute (1) Does the security scan tell you the NAME of the cookie(s) without these attributes? > We have done things mentioned in > https://geekflare.com/secure-cookie-flag-in-tomcat/ > > true true > > > and also updating the *context.xml for *useHttpOnly="true" It has > not helped. Nor surprising, since both of those are the default settings when using HTTPS. You *are* using HTTPS, right? > We also tried updating our web application's web.xml with the > cookie-config, but it has also not helped. > > What else do we need to do? Are you using a load-balancer? If so, what is the setup? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl0zFYkACgkQHPApP6U8 pFjdcw//QclBk/X1qPXzUtG+5zR/V7WNaALYN+14mY2l14/yp4XJbMC3fCcO3RFe l3hhScjQU6lWmKECN6fB6tXcjHTds4wYCnVifVHa/cQI8cQ7FK5p755lzAybbw+G UzGqGNZ8IYVcGtLGHxwSTv7iKQ4PTynHaVO8rcC6hNXg6YfMsle6YuWxG8+HGkhn 6H0Lqk0bqgX5ZGsjw8bc2r8AgICQye7trpH6UIdIAHmYwzXtlle5r6orR2O7pVJp KvViPKuUinJOPcGbMV0wh2iQxLaWy8ZNiJy/YcHS+Z8A/M3kigrwigc+Lt3c9PYz wLBOPNoOmvK/4csdR0UA7iOYbTXZdsdSk19Rfh+CdC0Tb9rF7klVnLp/qFodEFBQ EdruM20y8MD0XRaYmPGx+gjr2CqR9htBttpV9QnGooBV9BNO78FVSGo9+sBrwEIr UBs8R/Qs9ozHt12S6rY+eF4yY2H9SZLZKYihg1DF3VcQiHahnKaprI3KYSVar2P3 0h7gDx7L/QBLCt09h/70ECSordtGGn2AXIKHCuIbakYxYB16s3poPY/pYZdoc9YN GovTKKyvN4nHGv34eF+hJd3gFMRIBINLl0B6gf9gOoYUmu0lM+2C9gNZPhOb2dIM VXI4hnfWly9+G+MzTv94jpcQnilhxmO4Rz+2XzWXKFB5eERbYho= =3xaO -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: OT: Tomcat on AWS for Dummies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jerry, > On 7/19/19 13:38, Jerry Malcolm wrote: I have had a dedicated hosted environment with WAMP and Tomcat for over 15 years. I'm very familiar with everything related to that environment... apache http, mysql, dns server, the file system, JAMES, and all of my management scripts that I've accumulated over the years. Everything is in the same box and basically on the same desktop. But now I have a client that has needs that are best met in an AWS environment. > Can you explain that in a little more depth? What is it about AWS > that meets their needs better? > > I ask because you can provision a one-box wonder in AWS just like > you do on a physical space with a single server. You just have to > use remote-desktop to get into it, and then it's all the same. > > But if they want to use RDS, auto-scaling, and other > Amazon-provided services then things can get confusing. >> Unfortunately, that is the precise reason we need to go AWS >> Extremely high availability and scalability / load-balancing >> across multiple instances. There will need to at least one >> instance running at all times. Even when doing >> maintenance/upgrades on other instances. It's not "unfortunate" necessarily. At least it makes it clear why they want to migrate to AWS. > So the answer to your question really depends upon what the client > thinks they'll be getting by you taking your existing product "to > the cloud". > I understand just enough AWS to be dangerous, which is not much I do know that it's a bunch of different modules, and I believe I lose the direct file system access. > That heavily depends upon how you do things. You can get yourself > a server with a disk and everything, just like you are used to > doing. >> Do you mean AWS offers a 'file server' module that I can >> basically access directly as a drive from TC? If so, that eases >> my mind a bunch. I manage and serve gigabytes of videos and >> photos. I don't really want a full CMS implementation. Just >> want a big hard drive I can get to. No, AWS doesn't really have a "file server" module that you can enable. Do you need a large disk for bulk storage? What are you storing? Perhaps switching over to a key-value store (which can act like a filesystem) or a document-store database (e.g. CouchDB) if you have fairly regular documents that you want to store. All of those technologies are quite cloud-friendly. You can even use them single-node if you want to make your application available to either AWS-based clients OR your more traditional one-box-wonder clients. Or, you can abstract your "write a file somewhere" process so that you can swap implementations at run-time: configuration says local-disk? Use FileWriter. Using CouchDB? Push the file to CouchDB through it's APIs. I've watched an AWS intro video and a couple of youtube videos on setting up TC in AWS. But they always starts with "now that you have your AWS environment set up". I am looking for something that explains the big picture of migrating an existing WAMP+TC to AWS. I am not so naive to think that there won't be significant rip-up to what I have now. But I don't want to do unnecessary rip-up just because I don't understand where I'm heading. Basically, I don't know enough to know what I don't know But I need to start planning ahead and learning soon if I'm going to have any disasters in my code where I might have played it too loose with accessing the file system directly in my dedicated environment. Has anyone been down this path before and could point me to some tutorials targeted to migrating WAMP+TC to AWS? Or possible hand-hold me just a little...? I'm a pretty quick learner. I just don't know where to start. > As usual, start with your requirements :) > >> Requirements are what I have now in a single box, but with the >> addition of multiple instances of TC (and HTTPD and/or mySQL?) >> for HA and load balancing. One box with multi is ... not HA. Sorry. That allows you to do things like upgrade the application without taking it down completely. But it does not allow you to perform maintenance on the OS because everything has to come down. >> Day-1 launch won't be massive traffic and theoretically could be >> handled by my single dedicated server I have today. But if this >> takes off like the client predicts, I don't want to get caught >> flat-footed and have to throw together an emergency redesign to >> begin clustering TC to handle the traffic. Rather go live >> initially with single instance AWS, but with a thought-out (and >> tested/verified) plan to easily begin clustering when the need >> hits. One of the first things I'd take a look at is what it would take to switch from vanilla MySQL to one of the databases available through RDS. This sounds stupid:
Re: Security vulnerabilities with tomcat 9
If you have a load balancer you will need to add these attributes there as well... Sent from my T-Mobile 4G LTE Device Original message From: Sumit Bhardwaj Date: 7/20/19 8:52 AM (GMT-05:00) To: Tomcat Users List Subject: Security vulnerabilities with tomcat 9 Hi, We are using tomcat 9 and getting following two vulnerabilities in security scans. Cookie Does Not Contain The "secure" Attribute (1) Cookie Does Not Contain The "HTTPOnly" Attribute (1) We have done things mentioned in https://geekflare.com/secure-cookie-flag-in-tomcat/ true true and also updating the *context.xml for *useHttpOnly="true" It has not helped. We also tried updating our web application's web.xml with the cookie-config, but it has also not helped. What else do we need to do? Best Sumit - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Security vulnerabilities with tomcat 9
Hi, We are using tomcat 9 and getting following two vulnerabilities in security scans. Cookie Does Not Contain The "secure" Attribute (1) Cookie Does Not Contain The "HTTPOnly" Attribute (1) We have done things mentioned in https://geekflare.com/secure-cookie-flag-in-tomcat/ true true and also updating the *context.xml for *useHttpOnly="true" It has not helped. We also tried updating our web application's web.xml with the cookie-config, but it has also not helped. What else do we need to do? Best Sumit
Re: WAR file not deploying correctly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Victor, On 7/19/19 05:47, Victor WILLART wrote: > Hi everybody, > > > I am using Tomcat 8.0, and I am struggling to replace and deploy a > WAR file. > > > I made a new WAR file, named it like the old one, and replaced it > in my webapps folder. But the new generated folder for my > application is just containing a single folder "config" which is > empty. All the other folders and files are missing … I tried also > to deploy it through the Tomcat Manager and it happened the same. > > > I don't think my war file is wrong since I have a back up folder of > my app that was working perfectly before trying this, and the back > up WAR file isn't working neither. Only replacing the deployed > folder by the deployed folder from back up makes my app work again > correctly. > > > If you have any hints or guesses about this, I would gladly try > them. Anything in the logs files that might explain? On the server, try running this command: $ jar tvf [application].war - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl0zCbkACgkQHPApP6U8 pFjyoQ//RahZPPmCWqUXWoKwDaraAbEkOeyBSlJ17rFlFW8doMnKSHqz20vYlQEu DuW5FlJMlBVCfr2fpsyn5ObDjHJKa/ejlKrIHg5/2qUKBH44DnEfD0u7J32wnUNO hvJ+HH1p5e530n2XlvphTeDi8cWSVeFKCZLL+toHcSvOeXPUAJIfNpzwLpd40JV0 NAfXeAyu7jIMBzwnue8Z1AA1tDegAMQw0qGAtdxPUoQa6FWTiSfW1XuMqfdVUMB6 85q96QPoFc7Majqvd85No+4RqPZ/b5mRvZMyBsNiLeeUO7kdzxLPYoIq3oZO8lS6 c7jFhRsKCRqmriyk2xASrgrR0Ti0Q3SgaYCWvVIfnuutgMI7GppXJJ5fIPhm23FK dE3/CnjgtJiZkobOAYvEWnJigpm7SvUmjIfZX5RhV0rMM/vRCRO+eedrSkAcKtv4 oJmthCBTgzJOgBSeAv33ZKc7r4o6Ct/5Hf1ugl6+1AhqMxHctjPxyRvz62byH25m rr0mgE5OmPfITyghcgWqNPppSkdgtbMNbJoec12KljFpm8Gy0COiojT4LjaGma5g rYvCoj1Zp7mCBlzcUcceJtJTX8vAU1ltaV/7GNzGEADfDkzp+/Hq5Ph6EI0uiFE5 hzRUtQODf54YT65y2sDMyxs0wT5r64P6wWXTF5PoirKAZzPzstw= =TKdG -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTP to HTTPS redirect not happening
Richard, > Am 20.07.2019 um 04:19 schrieb Richard Huntrods : > > I tried implementing automatic redirection from HTTP to HTTPS on my > tomcat today, but it's not working. > > First, my system: > OS: Ubuntu 18.04.2 LTS (server) > Tomcat: 9.0.22 (installed from tomcat distribution, not via apt get) > Java: OpenJDK "11.0.3" 2019-04-16 > Mysql: Ver 14.14 Distrib 5.7.26 > > This web application has it's own domain (let's call it "mydomain.com" ) > and has working HTTPS - and has done for some time now. > > Static web pages are served on this application via tomcat using the > ROOT directory ../tomcat/webapps/ROOT > > Again, this is working just fine. If I type "https://mydomain.com; I see > the secure static pages. If I type "http://mydomain.com; I see the same > pages, but browsers inform me the page isn't secure. > > I want to force tomcat to redirect "http://mydomain.com; to > "https://mydomain.com; always. > > I found instructions for auto-redirection on several on-line sites, and > all had the same instructions. > > I already have the redirect code in server.xml: > > connectionTimeout="2" >redirectPort="443" /> > > So all I had to add (according to the instructions) was code at the end > of ...tomcat/conf/web.xml > > > > Secured > /* > > > CONFIDENTIAL > > > > just before the final This should go into your webapp's WEB-INF/web.xml! Not the tomcat/conf! Hope this helps, Peter > > I did this and restarted tomcat. It doesn't work. > > After restarting tomcat, if I type in "http://mydomain.com; I still see > the unsecured version. It does not auto-redirect to https. > > What am I missing? > > Thanks, > -Richard > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > -- > This communication is intended for the use of the recipient to whom it is > addressed, and may contain confidential, personal, and or privileged > information. Please contact us immediately if you are not the intended > recipient of this communication, and do not copy, distribute, or take action > relying on it. Any communications received in error, or subsequent reply, > should be deleted or destroyed. > --- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > smime.p7s Description: S/MIME cryptographic signature
