tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Dynamic Security Constraints?
Date Sat, 10 Mar 2012 19:26:15 GMT
André Warnier wrote:
> Leo Donahue - PLANDEVX wrote:
>>> -----Original Message-----
>>> From: André Warnier []
>>> Subject: Re: Dynamic Security Constraints?
>>> Leo Donahue - PLANDEVX wrote:
>>>> I'm not sure this is the right subject line, but if I wanted to use
>>> Tomcat to publish large files (several GB) for different customers to
>>> download, and each customer wanted their own secure URL (form based
>>> login over HTTPS) from which to download their data, how would I add a
>>> new security constraint url-pattern for authentication for new customers
>>> without restarting the server?  Is that even the correct approach?
>>>> Or would it just be easier to deploy a new pre-configured webapp for
>>> each customer?
>>> Your own choice of phrasing above is a bit ambiguous, but indeed your
>>> last solution seems to be the easiest to implement.
>>> Among other reasons, since you do not know who they are before they
>>> login, it would be difficult to present each one of them with their own
>>> specific login page.
>>> (That's the ambiguous part, so I'm not sure that I understand your
>>> requirement correctly).
>> Occasionally I get requests for GIS data in the tens of gigabytes.  
>> Our ftp won't let us upload that amount of data, so I thought why not 
>> zip it and place it on Tomcat for them to download.  This data was 
>> sensitive in nature and they wanted a secure login to whatever URL I 
>> provided for them to download that data.
>> Example:  when they access 
>> this URL, they are presented with a form based login over HTTPS, and 
>> once authenticated, Tomcat serves up a directory with their zip file.  
>> Essentially, I would already have a preconfigured SQL database with 
>> users/roles and just whip up a webapp and send the customer a 
>> url/username/password with which to login.  I was thinking I would 
>> just have webapp template that I modify when I get a request like 
>> that, deploy and then undeploy it after they get their data.  Is there 
>> a better way? 
> Well, if they can all use the same login page, then after they login you 
> know who they are.  And if you anyway have a database back-end, then 
> whatever webapp they are logged-in to, can do a database lookup and 
> retrieve /their/ download link from the database, and display it on the 
> response page.  Then you need only one webapp, and all you need to do is 
> add or modify or delete a record in the database.
> Just don't make the download link too obvious, not to encourage one of 
> them to change it a little bit just to try..
> For example, I would not make it like :
> ;-)

Addenda :
1) there is a bit more to this, in terms of the logic of that application. You'd have to 
think carefully of where you place these files to download, so that Tomcat does not 
unwittingly provide the possibility for a user to download such a file directly (bypassing

the login) by providing a URL that points to the file directly.
2) if the files being downloaded are really "in the tens of GB", you may want to pay 
attention to the overhead of delivering them under HTTPS, which would have your host 
encrypt the whole communication for downloading the files also.
I am not sure how much impact that would have on your host, be it may be significant.
3) Before you even start this, it may be wise to do a quick back-of-hand calculation about

the time it takes to download such a file over the average communications link. Tens of GB

is hundreds of Gigabits. You may be surprised at the number of hours your customers would

need, to download such a file.  Neither you nor them may be pleased at saturating your 
respective Internet links for the duration; nor at having to restart the download in case

there's a hiccup after 90%.
(tip : at 1 Mbit/s download speed, it would take close to 3 hours to download 1 Gbyte)
It may be better to send them a USB stick by post..

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

View raw message