Léa Massiot wrote:
@André Warnier: Thank you for your detailed answer.
As of your objections:
1) We don't agree with each other. I *DO* care about what URLs look like:
a) in general, b) for some reasons related to the user's speaking language,
c) for search engines, d) ...
One cannot argue with convictions.
The URL of a link can be seen in many circumstances and is used in various
ways both by humans and bots.
I would point out nevertheless that, in the case of an application such as the one you
describe, you probably do /not/ want bots to be able to point directly to the documents
uploaded by users. In particular since you seem to want the documents to be acessed via a
link which contains the original name of the file uploaded by the user. One may easily
consider this as at least a lack of privacy.
2) I want the resources (files and other things like databases) to be stored
outside the servlets container and more precisely on another partition,
especially if data get erased when the context which contains them is
undeployed!
That is a good idea in general. One of the reasons is, that there is no guarantee that
the location where the application is stored, is even writeable (apart from initially
putting the application there of course); another being that you may not have room enough
there for the uploaded files.
André Warnier wrote
Do you know that when a Context is undeployed by Tomcat, all its files
are deleted ?
This is certainly not what I want. I would expect Tomcat to provide a
mechanism for it not to happen. (See my questions at the end of this post).
See
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Automatic_Application_Deployment
(but remember, this is Tomcat-centric; other servlet containers may have other rules, as
long as they match the Servlet Specification).
André Warnier wrote
with your method consisting of creating a new context on-the-fly
Am I? I put "an_alias_1.xml" in "/etc/tomcat6/Catalina/localhost/" once and
only once (never touch it again afterwards).
That was not totally clear. What is also not clear, is how and when you do
that.
Any way, when you create such a Context file, in effect you are creating a new web
application. To have the container protect this application in any way (iow controlling
access to the user fils stored there), you would need to also have, in the application's
"docBase", a WEB-INF subdirectory containing a web.xml file which describes the security
constraints of that application.
André Warnier wrote
But this is a logical consequence of building a context "from scratch",
outside of you "/w" context, and having Tomcat serve it, without any kind
of security protecting that location.
See above. That is what I meant.
It's not exactly my full responsibility. I'm looking for a solution,
remember. I'm not especially keen on that solution.
I thought that you were the one developing that application ?
See Christopher's answer.
André Warnier wrote
An "undeploy" of a Context does not generally happen by itself
What is the probability of such an event occurring? If it's like a "rm -R"
on the directory, I'll forget about it.
So, given your thoughtful observations, here are my questions:
1) Can you tell me how to test a context undeployment in command line (not
via Tomcat Manager please)?
Yes, using the Tomcat Manager is the easiest way.
One can also invoke the function of the Tomcat Manager, via command-line tools (wget,
curl, etc..).
And as indicated in the page mentioned above, it can also happen when modifying your
Context file, modifying a directory etc..
My point is : accidents happen. But one doesn't have to make it easy for them to happen.
You will have a directory where users upload their own files, perhaps many of them, and
perhaps files that they would very much like not to loose. Putting these files at risk to
be deleted, due to a misconfiguration or by an operator action which is not necessarily as
evident as "rm -R" does not seem like a good idea.
Nobody can decide for you what your real priorities are, between having "nice" URL's, and
creating a system that is safe, controlled, and easy to manage.
You have not explained how users upload their files. Presumably, it is via a POST, to a
servlet you have created. That servlet knows where to store the files that are uploaded,
via some parameter which it reads somewhere.
Christoper's (and my own) suggestion is to create a similar servlet that serves to
download the files, and which would use the same parameter to know where to download them
from.
(And, this parameter could be stored in either the web.xml of the application, or in a
properties file, as explained by the article to which I pointed you earlier.)
Tomcat itself would not know where the files are stored, so it could not
"undeploy" them.
Access control to the download (just as for the upload) would be done by the container
protection of this application.
And the application itself could impose further constraints to who can upload or download
files.
And since you control the application, and through which URL it is to be accessed, you are
still free to make the URLs as nice as possible.
2) Is there any way, I can prevent a context to be undeployed ever (like
setting a specific option in a configuration file, in "an_alias_1.xml" for
example)?
Look in the doc for "autodeploy" and "deployIgnore". But again, I believe that this is
Tomcat-specific (and even maybe version-specific).
3) Is there any good example illustrating how to do a cross context
authentication you can point me to?
Look here :
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Single_Sign_On
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
