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