I assume that the standard way of dealing with static caching is to have e.g. 
an images (css etc) directory and have that not secure?

Simple question but can you do one /* constraint and then override that with a 
subsequent /images (and css etc) constraint or is there a different preferred 
way to do this kind of setup? It would be mildly annoying if I have to have all 
my main pages under some subdir (lengthening my URLs) just to differentiate, so 
I assume there is a better way?

R.

On 10 Nov 2009, at 10:42, Pid wrote:

> On 10/11/2009 10:07, Robert Denison wrote:
>> Hi P,
>> 
>> Thanks very much for your reasoned helpful response.
>> 
>> I fancied securing only login because I only want logged in users to see the 
>> service and I want the login to be secure (passwords are safe) but the data 
>> itself is irrelevant so I figure why spend cpu cycles encrypting/decrypting 
>> normal data communication? :)
> 
> Using SSL can interfere with caching of CSS, images etc.  Getting those for 
> each main request could cost the client more time than the encryption takes.
> 
> Paying attention to static resource caching is a good idea.
> 
> 
>> To be honest I'm happy to just encrypt the whole thing if that's just going 
>> to save me a lot of hassle.
> 
> Do it, see how it works out.  Then try:
> 
>> My last stab at this is maybe I could use a scenario of filtering all 
>> requests and essentially do:
>> 
>> if (logged in) {
>>   if (https) goto http
>> } else {
>>   if (http) goto https
>> }
>> 
>> And then rely on the security constraint only for requiring login and the 
>> Valve only for forwarding the request to the login page?
> 
> This would probably work out OK, (just remember that the Filter will work at 
> a level above/after the Valve has a chance to act).
> 
> 
> p
> 
> 
> 
>> R.
>> 
>> On 9 Nov 2009, at 23:05, Pid wrote:
>> 
>>> On 09/11/2009 22:33, Robert Denison wrote:
>>>> Hi all,
>>>> 
>>>> I am trying to have setup my tomcat webapp to be secure for login only.
>>>> It works as you'd expect if the security-constraint for /* is unsecure
>>>> and if I make it secure (using CONFIDENTIAL) for /*.
>>>> 
>>>> However if I try to make it secure only for the login page and unsecure
>>>> elsewhere any attempt to go to a page redirects to the login page but
>>>> unsecure - not using the https and higher port. I've seen comments about
>>>> filters to redirect up to the https port but my thoughts are:
>>>> 
>>>> 1) From what I understand it should be possible with multiple
>>>> constraints for different URLs, and
>>>> 2) as I only want to do this if the user is not logged in I'm not sure
>>>> how the filter would work.
>>>> 
>>>> I have a working https Connector because I can use the service
>>>> configured for /* to be secure.
>>> 
>>> So, to summarise, you want *only* the login page to be sent over SSL?
>>> 
>>> 
>>> The login page isn't ever requested directly, it's forwarded to by the 
>>> AuthenticationValve.  This means that you can place it out of the way, in, 
>>> say:
>>> 
>>> WEB-INF/login/form.jsp
>>> WEB-INF/login/error.jsp
>>> 
>>> but it also means that you shouldn't directly request the login page.
>>> 
>>> When you're using Container managed security, you request a secured 
>>> resource and the Valve forwards to the form.  Once you authenticate the 
>>> original request is restored.
>>> 
>>> Your config won't enforce SSL for the login page because the container 
>>> forwards the request to the page after it recognises the /* rule requires a 
>>> login.
>>> 
>>> 
>>> If you want the whole app to require a login, you can either choose to use 
>>> SSL, or not, but you can't easily send the login page only over SSL.
>>> 
>>> If only one part of the app required a login, you could employ a Filter to 
>>> downgrade to non-SSL when the URL didn't match that path.
>>> 
>>> Is there a particular reason why you want to downgrade after login?
>>> 
>>> 
>>> You might look into the Tomcat compatible SecurityFilter project, as it 
>>> provides very similar functionality to container managed security, but more 
>>> flexibility.
>>> 
>>> http://securityfilter.sourceforge.net/
>>> 
>>> 
>>> p
>>> 
>>> 
>>>> Any offered help appreciated.
>>>> 
>>>> The relevant (I think) web.xml snippet is:
>>>> 
>>>> <security-constraint>
>>>> <web-resource-collection>
>>>> <web-resource-name>Application Login</web-resource-name>
>>>> <url-pattern>/login.jsp</url-pattern>
>>>> <http-method>GET</http-method>
>>>> <http-method>POST</http-method>
>>>> </web-resource-collection>
>>>> <auth-constraint>
>>>> <role-name>player</role-name>
>>>> </auth-constraint>
>>>> <user-data-constraint>
>>>> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>>>> </user-data-constraint>
>>>> </security-constraint>
>>>> 
>>>> <security-constraint>
>>>> <web-resource-collection>
>>>> <web-resource-name>Application</web-resource-name>
>>>> <url-pattern>/*</url-pattern>
>>>> </web-resource-collection>
>>>> <auth-constraint>
>>>> <role-name>player</role-name>
>>>> </auth-constraint>
>>>> </security-constraint>
>>>> 
>>>> <!-- Define the Login Configuration for this Application -->
>>>> <login-config>
>>>> <auth-method>FORM</auth-method>
>>>> <realm-name>Application</realm-name>
>>>> <form-login-config>
>>>> <form-login-page>/jsp/login.jsp</form-login-page>
>>>> <form-error-page>/jsp/error.jsp</form-error-page>
>>>> </form-login-config>
>>>> </login-config>
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> 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
> 


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

Reply via email to