2014-07-05 20:00 GMT+04:00 Falco Schwarz <hid...@falco.me>:
> On Sat, Jul 5, 2014 at 12:39 PM, Mark Thomas <m...@homeinbox.net> wrote:
>> Maybe look at a third party security plugin like Spring Security? Not sure 
>> if this is supported but worth a look.
>>
>> Mark
>
> Thanks Mark and Konstantin for your quick replies. I tried to
> accomplish this only using Spring Security and I also got kinda stuck
> with the processing ordering. It is possible to use expressions like:
>
>     <security:http>
>         <security:intercept-url pattern="/**"
> access="hasIpAddress('127.0.0.1') and hasRole('ROLE_JMX')" />
>         <security:http-basic />
>     </security:http>
>
> ... but yet again, because of the http-basic tag, the user is always
> presented with an authentication instead of being denied.
>
> In the end I found a solution which suits my needs: combining the
> RemoteAddrFilter with Spring Security. This way the RemoteAddrFilter
> always prevents access if the client is not localhost. If the client
> is localhost then Spring Security kicks in and finally authenticates
> the User.
>
> Quite complicated for such a simple task and I really did not expect
> to find so little information regarding such an issue on the internet.

Ask spring security people?

(They wrote recently that they shut down all their forums, and support
is currently provided via stackoverflow.
http://spring.io/blog/2014/06/18/retiring-the-forum-spring-io-website
)

I think you can inject RemoteAddrFilter into Spring Security filter
chain (that is if you do not want to configure it separately in
web.xml),

http://docs.spring.io/spring-security/site/docs/3.2.4.RELEASE/reference/htmlsingle/#ns-custom-filters

> From a systems administrator perspective there is no way I would
> present a login form first and then deny via ip filters, but I guess
> that is just how the servlet spec is defined.
>

I think that admins usually do not want to bother with web application
internals such as web.xml. The usual solution is to configure a
RemoteAddrValve.


Best regards,
Konstantin Kolinko

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

Reply via email to