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 : http://wiki.apache.org/tomcat/Tomcat/WebDav
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
