shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Wheeldon <>
Subject RE: IP Based Restrictions
Date Tue, 31 Jan 2017 18:35:13 GMT
Done. See

If someone would like to take a look / fix the default ini / help me get it into trunk it’d
be appreciated,



From: Brian Demers []
Sent: Thursday, January 12, 2017 4:16 PM
Subject: Re: IP Based Restrictions

I like it, we could even create a default IpSource so the INI file could work out of the box,
something like:

ipFilter.ipSource = x.x.x.x, x.x.x.x/24

On Thu, Jan 12, 2017 at 5:25 AM, Richard Wheeldon <<>>
It’s the whole app for now.

So I could grab the IpAddressMatcher from Spring sec and repackage it (rather than introducing
a dep between shiro and spring which would be a bit crazy)

Then create:

package org.apache.shiro.web.filter.authz;

public interface IpSource {
    public List<String> getIpRanges();

package org.apache.shiro.web.filter.authz;

public class IpFilter extends AuthorizationFilter {
    public void setIps(List<String> ips) { ... }
    public void setIpSource(IpSource source) { ... }
    public getHost(ServletRequest request) {
        return request.getRemoteHost();
    protected boolean isAccessAllowed(ServletRequest request, ServletResponse response, Object
mappedValue) throws Exception {
        String host = getHost();
        for (IpAddressMatcher matcher : matchers) {
                    if (matcher.matches(host)) {
                return true;
        return false;

package com.voxsmart.stuff;

public class XffIpFilter extends IpFilter {
    public getHost()

package com.voxsmart.stuff;

public class DatabaseIpSource {

    public getIpRanges() {
        ... select range from ...

And put in shiro.ini:
ipSource = com.voxsmart.stuff.DatabaseIpSource
ipFilter = com.voxsmart.stuff.XffIpFilter
ipFilter.ipSource = ipSource

/* = ipSource,...

Does this seem reasonable?

From: Brian Demers [<>]
Sent: Tuesday, January 10, 2017 5:14 PM
Subject: Re: IP Based Restrictions

Take a look at this block of code in the AuthenticatingFilter:

Are you trying to restrict an IP/range for a individual users. Or a range for the whole application?
  A realm would work for the user case. For the application case, you could probably just
create a filter.

Either way, great stuff!

On Tue, Jan 10, 2017 at 11:39 AM, Richard Wheeldon <<>>

Having broken the back of the token based MFA, my next quest in bolting down my app is to
add configurable IP-based restrictions. I’m thinking of a realm which reads a list of IPs
or ranges (v4 or v6) from a DB then checks if the host matches.

Two questions:

  1.  Is there any interest in my producing a generic / re-usable JdbcHostRestrictionRealm
and kicking it back upstream? I can probably do this by cribbing from JdbcRealm.
  2.  My app is sat behind a load balancer which changes the IP address. Since we control
the load balancer we can trust the X-Forwarded-For header in a downstream app. Is there a
preferable place to hook in the logic to read it from the request and set it on the token?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message