tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leon Rosenberg <>
Subject Re: making security constraints configureable
Date Wed, 09 Nov 2011 09:25:35 GMT
Hello Terence,

the System property would be indeed the easiest way, unfortunately I
wouldn't know that the descriptive security in web.xml supports
scripting with environment variables. If it does, it would solve all
the problems ;-)


2011/11/8 Terence M. Bandoian <>:
>  On 1:59 PM, André Warnier wrote:
>> Terence M. Bandoian wrote:
>>>  On 1:59 PM, Konstantin Kolinko wrote:
>>>> 2011/11/3 Leon Rosenberg<>:
>>>>> 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.
> The system property that indicates whether or not the application is in a
> staging or test environment would be used in conjunction with a test
> against, for example, request.getRemoteUser() or request.isUserInRole() or
> request.getRemoteAddr().
> -Terence Bandoian
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message