tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: making security constraints configureable
Date Mon, 07 Nov 2011 20:31:00 GMT
Terence M. Bandoian wrote:
>  On 1:59 PM, Konstantin Kolinko wrote:
>> 2011/11/3 Leon Rosenberg<rosenberg.leon@gmail.com>:
>>> I have a situation where an application is accessable from outside in
>>> staging and production environment, but shouldn't be open for public
>>> in staging environment.
>> Put it behind Apache HTTPD (or any other proxy) and let HTTPD handle
>> authentication&  authorization instead of Tomcat.
>>
>> I'd advise against using BASIC auth in public internet, unless the
>> channel is protected with HTTPS.
>>
>>> What we did so far was, that we excluded everyone via web.xml:
>>>
>> You can automate the above. If you pack your war file using Ant, you
>> can use<replaceregexp>  task.
>>
>> Best regards,
>> Konstantin Kolinko
> 
> I'm not sure what "open for public" means above.
> 
> What about using a system property (e.g. myorg.myapp.isStagingEnv=true) 
> in a filter or valve to accept or reject requests?
> 
If I (belatedly) understand the requirements properly, Leon does not not want to reject 
/all/ requests (that, he could do by undeploying the application).  It is more something 
like this :

- requests originating from a range of IP addresses (e.g. the internal LAN) should be 
accepted, without authentication
- requests originating from anywhere else should be submitted to authentication.

Practical case : the application is in a testing state, and should not be available to the

public at large, only to inside testers. The inside testers should not have to login for that.
However, occasionally, someone may be sitting in an Internet Cafe and want to do a demo 
for a customer from there. He should be able to access the application, but only after 
logging in.

Leon, if the above is not the right description, please correct it.  In such matters, the

devil is in the details.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message