Hello Andre,

sorry for the late response.

Putting a httpd or lightttpd or nginx in front of our staging tomcat
came to our mind too. The problem with this approach is however, that
it
reduces the idea of having a staging environment to absurdity, at
least in technical sense, because its not similar to the production
environment anymore.
In this setup we couldn't make any reliable loadtesting against
preproduction/staging, because its simple not the same as production
;-)

But thanx nevertheless ;-)

regards
Leon


On Mon, Nov 7, 2011 at 4:19 PM, André Warnier <a...@ice-sa.com> wrote:
>
> @Leon (trying to do better this time) : I presume that you have a separate
> Tomcat server (or instance) for staging. If so, the easiest solution would
> be to leave the production one as it is, and your app as it is, and put an
> apache httpd front-end before only the staging Tomcat, and only for external
> accesses. The filtering/authentication would happen on the front-end, and it
> would only pass the external requests to the back-end staging Tomcat if the
> access conditions are met.
> Internal accesses can still go to the staging Tomcat directly, and access
> the app without authentication.
> That should be easy to set up, easy being a function of how easily you can
> set up this Apache front-end with a separate hostname on the Internet, and
> allow it to proxy-pass requests to your internal Tomcat staging server.
> As you probably do not have a plethora of external staging user-ids, the
> type of authentication setup could be very simple (basic auth, file-based).
> If basic auth is too insecure, you can run the browser/front-end part over
> HTTPS, still without changing anything on Tomcat.
>
>
>
> Daniel Mikusa wrote:
>>
>> Leon,
>>
>> One possible way to work around this would be to use an SSH tunnel or a
>> VPN (like OpenVPN) to access your network from the remote locations.
>>
>> Dan
>>
>>
>> On Sat, 2011-11-05 at 08:53 -0700, Leon Rosenberg wrote:
>>>
>>> Hello Daniel,
>>>
>>> I can't use IP-Adresses, because it is possible that we show the
>>> preproduction system in a starbucks to some customers for user testing
>>> purposes.
>>> I have no means to know which adresses are allowed and which not.
>>>
>>> regards
>>> Leon
>>>
>>> On Thu, Nov 3, 2011 at 7:09 PM, Daniel Mikusa <dmik...@vmware.com> wrote:
>>>>
>>>> Leon,
>>>>
>>>> Is it a requirement for you to use BASIC auth?  or could you use
>>>> something like the Remote Address Filter to restrict by IP address?
>>>>
>>>>
>>>> https://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Remote_Address_Filter
>>>>
>>>> If you configure this valve in the restricted environment you can then
>>>> control who can access to just that environment.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On Thu, 2011-11-03 at 10:10 -0700, Leon Rosenberg wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> 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.
>>>>> What we did so far was, that we excluded everyone via web.xml:
>>>>>
>>>>>
>>>>>        <!-- security configuration -->
>>>>>        <login-config>
>>>>>                <auth-method>BASIC</auth-method>
>>>>>        </login-config>
>>>>>        <security-role>
>>>>>                <role-name>my-access</role-name>
>>>>>        </security-role>
>>>>>        <security-constraint>
>>>>>                <display-name>blub</display-name>
>>>>>                <web-resource-collection>
>>>>>                        <web-resource-name>myres</web-resource-name>
>>>>>                        <url-pattern>*.html</url-pattern>
>>>>>                </web-resource-collection>
>>>>>                <auth-constraint>
>>>>>                        <role-name>my-access</role-name>
>>>>>                </auth-constraint>
>>>>>        </security-constraint>
>>>>>        <!-- /security configuration -->
>>>>>
>>>>> Is there any possibility to make this conditional, depending on an
>>>>> environment property? Is there any other opportunity to achieve the
>>>>> same?
>>>>> Currently we have to kill the above lines from web.xml after each
>>>>> deployment and this sucks ;-(
>>>>>
>>>>> regards
>>>>> Leon
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

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

Reply via email to