[mapserver-dev] Enable/disable OWS layers by IP list

Wed Feb 13 11:27:42 PST 2013

Hi Daniel,

Thanks for the suggestions. Looks like it doesn't require too much
additional work to follow this, and we can still keep the required amount
of changes at minimum.  I also thought an RFC is to be posted in this topic.

Best regards,

Tamas

2013/2/13 Daniel Morissette <dmorissette at mapgears.com>

> Thank you Steve for suggesting the support of subnet masks (a.b.c.d/mask),
> I was going to suggest the same thing.
>
> I also would like to suggest supporting both a list of addresses from a
> file, or the ability to provide the values directly in the mapfile. In
> cases where there are only a couple of IPs to list, being able to specify
> them directly in the mapfile would be much more user-friendly.
>
> e.g.
>
> space-delimited list of addresses:
>
>   "ows_allowed_ip_list" "123.45.67.89 11.22.33.44"
>
> or ref to a file:
>
>   "ows_allowed_ip_list" "file:/path/to/list_of_ips.**txt"
>
>
> I think that long term we'll want more powerful access control mechanisms,
> we have discussed this several times here, but that is a much bigger issue
> to tackle and I think the proposed mechanism can easily be deprecated
> without important side-effects the day that we would have something more
> powerful in place.
>
> And finally, even if that is a simple and straightforward addition, I
> think that a short RFC to document it would be nice and I'd encourage you
> to produce one. RFCs are often the only reference for some features until
> they make it to the docs... there are even some features from a few
> releases ago for which the RFC is still the only/best docs available
> (unfortunately).
>
>
> Daniel
>
>
>
> On 13-02-13 10:18 AM, Tamas Szekeres wrote:
>
>> Hi Steve,
>>
>> Thanks for the comments, using CIDR notation
>> <http://en.wikipedia.org/wiki/**CIDR_notation<http://en.wikipedia.org/wiki/CIDR_notation>>
>> to define ranges would be
>>
>> reasonable. This would allow to define subnets in a single row. I think
>> it would work with both ipv4 and ipv6 addresses.
>>
>> Best regards,
>>
>> Tamas
>>
>>
>>
>> 2013/2/13 Stephen Woodbridge <woodbri at swoodbridge.com
>> <mailto:woodbri at swoodbridge.**com <woodbri at swoodbridge.com>>>:
>>
>>  > On 2/13/2013 8:45 AM, Tamas Szekeres wrote:
>>  >>
>>  >> Hi Devs,
>>  >>
>>  >> I got a requirement from Faunalia (http://www.faunalia.it) to
>>  >> establish option to Enable/disable OWS layers by IP list.
>>  >> We need to add two new parameters to the WEB section of the mapfile,
>>  >> and/or in the METADATA section of every single layer:
>>  >>
>>  >> 1. "ows_allowed_ip_list"
>>  >> 2. "ows_denied_ip_list"
>>  >>
>>  >> Both should point to a file with a list of IP addresses.
>>  >
>>  >
>>  > If you are pointing to a file then these should be
>>  >
>>  > ows_allowed_ip_file
>>  > ows_denied_ip_file
>>  >
>>  > to avoid confusion. Using "list" implies that a item target should be
>> a list
>>  > of ip addrs and not a file.
>>  >
>>  > These should not allow parameter substitution as that would be a simple
>>  > defeat of the mechanism.
>>  >
>>  > Do you plan to support address ranges like:
>>  >
>>  > 192.168.1.1-192.168.1.10
>>  > 192.168.1.0/24 <http://192.168.1.0/24>
>>
>>  >
>>  > Otherwise looks fine.
>>  >
>>  > -Steve W
>>  >
>>  >> The aim is to let the admin to define list of users, identified
>>  >> through their IPs to
>>  >> allow or deny access to one or more specific WMS or WFS layers.
>>  >>
>>  >> I've prepared an implementation to this requirement which appears to
>>  >> be a fairly simple addition to the code:
>>  >>
>>  >>
>> https://github.com/szekerest/**mapserver/commit/**
>> 4b7c203a1782cd56d01c34e1079a18**4c04e51207<https://github.com/szekerest/mapserver/commit/4b7c203a1782cd56d01c34e1079a184c04e51207>
>>  >>
>>  >> In my approach if both the allowed list and the denied list contains
>>  >> the current endpoint IP then the denied list will take precedence.
>>  >> If allowed_ip_list or ows_denied_ip_list is not specified or the
>>  >> specified files are not readable then the current behaviour will
>>  >> continue to work.
>>  >>
>>  >> Issue has also been added for this addition:
>>  >> https://github.com/mapserver/**mapserver/issues/4588<https://github.com/mapserver/mapserver/issues/4588>
>>  >>
>>  >>
>>  >> Let me know about your opinion whether this change is reasonable.
>>  >> Would that require an RFC to be added?
>>  >>
>>  >> Deadline of this addition is close, so I'd prefer to include this as
>>  >> soon as possible.
>>  >>
>>  >>
>>  >> Best regards,
>>  >>
>>  >> Tamas
>>  >> ______________________________**_________________
>>  >> mapserver-dev mailing list
>>  >> mapserver-dev at lists.osgeo.org <mailto:mapserver-dev at lists.**osgeo.org<mapserver-dev at lists.osgeo.org>
>> >
>>
>>  >> http://lists.osgeo.org/**mailman/listinfo/mapserver-dev<http://lists.osgeo.org/mailman/listinfo/mapserver-dev>
>>  >>
>>  >
>>  > ______________________________**_________________
>>  > mapserver-dev mailing list
>>  > mapserver-dev at lists.osgeo.org <mailto:mapserver-dev at lists.**osgeo.org<mapserver-dev at lists.osgeo.org>
>> >
>>
>>  > http://lists.osgeo.org/**mailman/listinfo/mapserver-dev<http://lists.osgeo.org/mailman/listinfo/mapserver-dev>
>>
>>
>>
>> ______________________________**_________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org
>> http://lists.osgeo.org/**mailman/listinfo/mapserver-dev<http://lists.osgeo.org/mailman/listinfo/mapserver-dev>
>>
>>
>
> --
> Daniel Morissette
> http://www.mapgears.com/
> Provider of Professional MapServer Support since 2000
>
>
> ______________________________**_________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/**mailman/listinfo/mapserver-dev<http://lists.osgeo.org/mailman/listinfo/mapserver-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20130213/6b3fd403/attachment-0001.html>