tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Tomcat6 - Context - aliases
Date Mon, 09 Apr 2012 22:05:30 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message