I like it, we could even create a default IpSource so the INI file could work out of the box, something like:
[main] ipFilter.ipSource = x.x.x.x, x.x.x.x/24 On Thu, Jan 12, 2017 at 5:25 AM, Richard Wheeldon < [email protected]> wrote: > 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) > > https://github.com/spring-projects/spring-security/blob/ > master/web/src/main/java/org/springframework/security/web/ > util/matcher/IpAddressMatcher.java > > > > 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(); > > } > > @Override > > 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 { > > @Override > > public getHost() > > parseIpAddressFromXffHeader(request.getHeader(XFF_HEADER)) > > } > > } > > > > package com.voxsmart.stuff; > > > > public class DatabaseIpSource { > > > > @Override > > public getIpRanges() { > > ... select range from ... > > } > > } > > > > And put in shiro.ini: > > [main] > > ipSource = com.voxsmart.stuff.DatabaseIpSource > > ipFilter = com.voxsmart.stuff.XffIpFilter > > ipFilter.ipSource = ipSource > > > > [urls] > > /* = ipSource,... > > > > Does this seem reasonable? > > > > *From:* Brian Demers [mailto:[email protected]] > *Sent:* Tuesday, January 10, 2017 5:14 PM > *To:* [email protected] > *Subject:* Re: IP Based Restrictions > > > > Take a look at this block of code in the AuthenticatingFilter: > > https://github.com/apache/shiro/blob/ef5450b9f4be74ee93040111539482 > 3b9e1fc3e6/web/src/main/java/org/apache/shiro/web/filter/ > authc/AuthenticatingFilter.java#L62-L72 > > > > 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 < > [email protected]> wrote: > > Hi, > > > > 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? > > > > Richard > > >
