tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Tomcat6 - Context - aliases
Date Sat, 07 Apr 2012 19:51:53 GMT
André Warnier wrote:
> Léa,
> Léa Massiot wrote:
> ...
>> Actually I realized that even with the previous mechanism I used 
>> (using the
>> "aliases" attribute of the "Context" element of the 
>> "w/WEB-INF/context.xml"
>> file), I could directly retrieve a resource by typing its exact URL in a
>> browser and without having to identify in any way prior to the 
>> retrieval...
> I think that what we are missing here, is what exactly you are trying to 
> achieve.
> And personally (no offense intended) I have the feeling that what you 
> are trying to do is fairly simple and classic, but that the way you are 
> going about it makes it complicated and probably unsafe.
> Let me try to summarise.
> 1) upload of documents/files :
> - Users are able to access the webserver and to upload files/documents 
> to it.
> You have not told us how that works, if there are several users or just 
> one, if all users are uploading to the same location, if this capability 
> is restricted (login) and so on..
> - when a user uploads a file/document, this file/document gets written 
> somewhere on the webserver. Where ? are there several upload locations ? 
> and how is it decided what gets written where ? if 2 users upload a 
> file/document with the same filename, does the second one overwrite the 
> first ?
> 2) download of files/documents :
> - Users can (should) login to the webserver, and after that they are 
> able to download files/documents.  Do all users have access to all 
> uploaded documents ? should it be so that each user (or group of users) 
> only gets access to "his own" documents ? When a gicen user logs in, 
> does he get a list of all the documents ? or a list of only "his" 
> documents ?
> Does your application ("/w" ?) build a list of the files, as a html page 
> with links, on which the user can just click to download a file/document 
> ? and if so, what does bother you about the exact "look" of that link ? 
> the user does not see the URL, he sees only what you choose to display, 
> right ? iow in the link :
> <a href="/an_alias_1/file_1.txt">file_1.txt</a>
> the user only see the "file_1.txt" part, right ?
> And if the link was :
> <a href="/w/something-else-altogether/12345">file_1.txt</a>
> the user would still only see "file_1.txt", right ?
> So, if I summarise, the only part which is somewhat iffy, is that in 
> your mechanism via Context, you are providing a URL which allows any 
> user to just use that URL to retrieve a document (his or someone 
> else's), without even having to login.
> 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.
> In other words, why not store the documents in a directory below your 
> "/w" context (which would be protected by the web.xml of the "/w" 
> context, and provide the user with a link like :
> <a href="/w/files/userx/file_1.txt">file_1.txt</a>
> I guess that I don't see why you would have to go through the bother of 
> creating another Context on-the-fly (and then one without any 
> access-control whatsovever).
> Of course, you /could/ store the files somewhere else, but then if that 
> is a separate Tomcat context, you would need a separate authentication - 
> or a cross-context authentication.  And if that location is not a Tomcat 
> context, then you would need your webapp to also retrieve and deliver 
> the files to the clients (which is quite simple, and is the way I would 
> have looked at it in the first place; and this would allow you to 
> control who can access what).
> By the way, have you looked at the DAV application available for Tomcat ?
> See :
Addendum, triggered by a response from Konstantin to another recent post on this list :
Do you know that when a Context is undeployed by Tomcat, all its files are deleted ?
An "undeploy" of a Context does not generally happen by itself, but with your method 
consisting of creating a new context on-the-fly, if ever an undeploy did happen, all the 
uploaded files in that Context would be deleted.  Probably not what you want to risk.
There are some things like that which are difficult to explain to users of your 
application.. ;-)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message