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

Thu Feb 14 08:26:25 PST 2013

Probably do have the same issue although there are other mechanisms to make layers not queryable etc… so it’s probably not as big an issue. I agree it would be a nice addition following the same approach as with OWS. Would it make sense to move mode/request limiting and this other access control to an ACCESS … END block?

Steve

From: Tamas Szekeres [mailto:szekerest at gmail.com]
Sent: Thursday, February 14, 2013 9:48 AM
To: Lime, Steve D (MNIT)
Cc: Daniel Morissette; mapserver-dev at lists.osgeo.org
Subject: Re: [mapserver-dev] Enable/disable OWS layers by IP list

Steve,

With regards to disabling the stock CGI modes I wonder if we have the same issue for example when limiting access to certain WMS layers by using the wms_enable_request setting.

For a workaround, I think it would be easy to implement a similar parameter (for example ms_disable_modes) in the WEB section to control which modes are not to be handled.

For example "ms_disable_modes"  "*" would dispatch only those requests where explicit mode is not set by URL. I notice we also have a modeStrings array in mapservutil.c which could provide the option to disable the modes selectively, something like:

"ms_disable_modes" "MAP BROWSE LEGEND"

What is you opinion?

Best regards,

Tamas

2013/2/14 Lime, Steve D (MNIT) <Steve.Lime at state.mn.us<mailto:Steve.Lime at state.mn.us>>
I think this needs an RFC... This isn't a trivial addition. For example, this mechanism needs to
apply to stock CGI operations (mode=...) as well or someone could simply work around the OWS
interfaces using their CGI equivalent.

Which gets me thinking about being able to limit those via a mapfile or shut that functionality
off altogether.

Steve

________________________________________
From: mapserver-dev-bounces at lists.osgeo.org<mailto:mapserver-dev-bounces at lists.osgeo.org> [mapserver-dev-bounces at lists.osgeo.org<mailto:mapserver-dev-bounces at lists.osgeo.org>] on behalf of Daniel Morissette [dmorissette at mapgears.com<mailto:dmorissette at mapgears.com>]
Sent: Wednesday, February 13, 2013 11:12 AM
To: mapserver-dev at lists.osgeo.org<mailto:mapserver-dev at lists.osgeo.org>
Subject: Re: [mapserver-dev] Enable/disable OWS layers by IP list

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> 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>
> <mailto:woodbri at swoodbridge.com<mailto: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> <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/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
>  >>
>  >>
>  >> 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> <mailto:mapserver-dev at lists.osgeo.org<mailto:mapserver-dev at lists.osgeo.org>>
>  >> 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> <mailto:mapserver-dev at lists.osgeo.org<mailto:mapserver-dev at lists.osgeo.org>>
>  > 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>
> 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<mailto:mapserver-dev at lists.osgeo.org>
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>
http://lists.osgeo.org/mailman/listinfo/mapserver-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20130214/5acfb81a/attachment-0001.html>