Comments inline:
On 8/10/2013 4:29 AM, André Warnier wrote:
Saurabh Agrawal wrote:
Hi,
I have developed Struts 2 application which is deployed on Tomcat. I
am using Eclipse to do the coding and configured Tomcat with Eclipse
to deploy the war from Eclipse itself.
My requirement is that all static assets should be served from Apache
HTTP Server because in our production environment that will be the set
up.
As a result, I have configured image URLS like –
<img src=”/common/images/test.jpg” />
The assumpition is common folder will be the present in the doc root.
I have copied common folder in the ROOT of Tomcat so that it can be
accessed from /common in the URL. However, my images are not getting
picked with the above URL.
I do not pretend to understand your complete setup here, but it looks to
me like you are setting yourself up for a very insecure website layout.
If you are locating resources in Tomcat's webapps/ROOT directory, but
then serving them with Apache HTTPD (and for that, mapping the Tomcat
ROOT folder to make it directly accessible from the HTTPD server), it
means that for *everything* in the Tomcat webapps/ROOT folder your are
completely bypassing the Tomcat bultin security.
(For example, it means that HTTPD users will have direct access to
Tomcat's ROOT/WEB-INF folder files, whatever private information may be
in there.)
HTTPS users will also have access to the source of whatever *.JSP pages
you put there.
Heed the bold text here :
http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html
The point is : by default, Tomcat "knows" that it should not serve
anything from the WEB-INF sub-ditectory, nor serve "raw" JPS's.
But HTTPD does not know that, and by default it will serve these things
without having a second look.
You /can/ make this secure by correct configuration, but it needs
careful work, and it is easy to verlook something.
Hopefully the original poster is just emulating what will be in
production. In other words, rather than having an Apache HTTPD server
with the static files on his development machine, as well as connecting
Apache HTTP and Tomcat with AJP, he's using a shortcut to make sure all
the URLs work.
If not, then yes, security will be a potential issue if you're not
careful. However, if the WAR file containing /common only contains
static material, there may not be much risk.
However, if I create a war file using Maven and deploy it on the
server, /common works. So I think it may be the problem wuth embedded
tomcat instance within eclipse for which may be ROOT is not the doc root.
Can anyone suggest how can it work i.e. deploying application from
eclipse to a configured tomcat instance in eclipse ?
Thanks.
Regards,
SAURABH AGRAWAL
Manager Technology
—
SapientNitro
Aachvis Softech Private Limited SEZ,
“Oxygen”, (Tower C), Ground – 3rd Floor,
Plot No. 7, Sector 144 Expressway,
Noida 201 304, Uttar Pradesh, India
desk +91 (120) 479 5000
mobile +91 981 866 4383
fax +91 (120) 479 5001
Sadly, Eclipse does not work the way you think it does. Eclipse does not
really use CATALINA_HOME/webapps when it deploys applications. It uses
the following:
workspace/.metadata/plugins/org.eclipse.wst.server.core/tmp[n]/wtpwebapps/[context-name]
where [n] is the number of the server you've started up (I think if you
have multiple servers, this depends on which server you start first),
and [context-name] is the context name.
If you look in that directory, you'll see only the applications you've
deployed via Eclipse (no default ROOT application, no examples, no
manager application, nothing).
The cleanest way around this is to deploy everything from within Eclipse.
You could copy the static files to that location, but I don't know if
tmp[n] changes.
You could also set up an Apache HTTPD server, copy the files there, and
link the two with AJP. While that sounds a bit more complicated, it's
not really that difficult. This would have the advantage of more closely
emulating the production environment as well.
. . . . just my two cents.
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
