Thanks for your reply Mark, I exposed this "Valve + RequestFacade subclassing" scenario to the other guys on my project and we prefer not to modify Tomcat internals. We are currently hesitating between introducing a ServletFilter and subclassing org.springframework.security.securechannel.SecureChannelProcessor. We use the second on production today, I added the small piece of code at the end of this email for the people who would be intesrested.
Cyrille -- Cyrille Le Clerc cyrille.lecl...@pobox.com clecl...@xebia.fr http://blog.xebia.fr public class TrustedRemoteAddressesEnabledSecureChannelProcessor extends SecureChannelProcessor implements ChannelProcessor { private final Logger logger = Logger.getLogger(TrustedRemoteAddressesEnabledSecureChannelProcessor.class); private Pattern[] trustedRemoteAddresses = new Pattern[] { Pattern.compile("10\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}"), Pattern.compile("192\\.168\\.\\d{1,3}\\.\\d{1,3}"), Pattern.compile("169\\.254\\.\\d{1,3}\\.\\d{1,3}"), Pattern.compile("127\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}") }; public void setSecuredRemoteAddresses(List<String> securedRemoteAddressesAsString) { List<Pattern> newSecuredRemoteAddresses = new ArrayList<Pattern>(); for (String securedRemoteAddr : securedRemoteAddressesAsString) { newSecuredRemoteAddresses.add(Pattern.compile(securedRemoteAddr)); } trustedRemoteAddresses = newSecuredRemoteAddresses.toArray(new Pattern[0]); } @Override public void decide(FilterInvocation invocation, ConfigAttributeDefinition config) throws IOException, ServletException { final boolean isSecureRemoteAddr = matchOne(invocation.getHttpRequest().getRemoteAddr(), trustedRemoteAddresses); if (logger.isDebugEnabled()) { logger.debug("Decide for " + invocation.getFullRequestUrl() + ", request.remoteAddr=" + invocation.getHttpRequest().getRemoteAddr() + ", isSecureRemoteAddr=" + isSecureRemoteAddr); } HttpServletRequestWrapper requestWrapper = new HttpServletRequestWrapper(invocation.getHttpRequest()) { @Override public boolean isSecure() { return super.isSecure() || isSecureRemoteAddr; } }; FilterInvocation filterInvocationWrapper = new FilterInvocation(requestWrapper, invocation.getResponse(), invocation.getChain()); super.decide(filterInvocationWrapper, config); } public static boolean matchOne(String str, Pattern... patterns) { for (Pattern pattern : patterns) { if (pattern.matcher(str).matches()) { return true; } } return false; } } On Tue, Jun 23, 2009 at 11:45 AM, Mark Thomas <ma...@apache.org> wrote: > > Cyrille Le Clerc wrote: > > Thank you for the clarification Mark. > > > >> Depending on where the session is created, you might be able to use a > >> filter to wrap your response and modify the secure attribute of any > >> cookies as they are added to the response. > > > > I am sorry to bother you but I don't see how I could wrap the class > > o.a.c.connector.Response whose method addCookieInternal(cookie) is > > called by o.a.c.connector.Request.doGetSession(boolean) to create the > > JSESSIONID cookie. > > Sorry, my bad. It was late and I wasn't thinking clearly. > > > If all this is to complex, I will fall back to another approach that > > is to do pattern matching (10.*) on request.remoteAddr to flag > > RequestFacade.secure=true if the requests come from my secured network > > area. This will let request.secure=false if request.scheme=http and > > thus have non-secure JSESSIONID cookies. > > I tested with a valve called SecuredRemoteAddressesValve (1) that I > > precede of RemoteIpValve (2) to process the x-forwarded-for header to > > find the real remoteAddr and this works fine. > > That sounds like a good solution to me. Valves were the other area I was > going to suggest you investigate. > > Mark > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
