Hi Daniel,<div><br></div><div>As I've mentioned before assuming the planned enhancement will provide the same functionality, we won't object deprecating the metadata itself. This will probably mentioned in the migration guide to make sure how to transfer the existing configuration to the new environment.</div>
<div><br></div><div>Best regards,</div><div><br></div><div>Tamas</div><div><br></div><div><br></div><div><br><br><div class="gmail_quote">2013/3/1 Daniel Morissette <span dir="ltr"><<a href="mailto:dmorissette@mapgears.com" target="_blank">dmorissette@mapgears.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 13-02-28 8:39 AM, Tamas Szekeres wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2013/2/28 thomas bonfort <<a href="mailto:thomas.bonfort@gmail.com" target="_blank">thomas.bonfort@gmail.com</a><br>
<mailto:<a href="mailto:thomas.bonfort@gmail.com" target="_blank">thomas.bonfort@gmail.<u></u>com</a>>><div class="im"><br>
<br>
    I agree that this is a complex area that in some case will need to be<br>
    handled by application specific methods. My point is that limiting by<br>
    ip only covers a tiny fraction of the AA<br>
    (authentication/authorization) scenarios, and that we will have to be<br>
    backwards compatible with it in the long run the day we have the<br>
    funds/needs for a full fledged AA component.<br>
<br>
<br>
We don't necessarily required to be backward between major version<br>
changes. Users should update their mapfiles so they could migrate their<br>
IP lists to some other places if required (Assuming we remain function<br>
compatible)<br>
<br>
</div></blockquote>
<br>
<br>
Thomas, Tamas,<br>
<br>
For my part, I already tought about this issue and think that in a future iteration of AA support we would likely end up deprecating the new metadata introduced by RFC 90 and replace them with a more complete system.<br>

<br>
At Mapgars we have worked on the GeoPrisma project in the last few years (<a href="http://geoprisma.org/" target="_blank">http://geoprisma.org/</a>) and learned a lot about access control mechanism use cases around geospatial services. The project is mostly dormant now but the lessons learned are still in our mind. I also believe that a future iteration of GeoPrisma would look very different from what it is today. However before this happens we need to have the time/resources/funding so don't expect to see this happen in the short term.<br>

<br>
I think what we'd need is a C lib/module (call it libgeoprisma or whatever) that can be plugged into MapServer or other geospatial services (TinyOWS, MapCache, etc.) to provide spatially-aware access control services around a commoon set of config directives (configured only once for all services). If MapServer was built with this extension then it would make some extra checks to control access to data at various levels of granularity, etc.<br>

<br>
I do not have a clear picture yet of what this beast would be like in the end, but it is clear to me that this approach would involve deprecating what was introduced in RFC-90, which means that as much as I usually care a lot about backwards compatibility, in this specific case it is probably not that big a deal.<br>

<br>
My 0.02$<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Daniel Morissette<br>
<a href="http://www.mapgears.com/" target="_blank">http://www.mapgears.com/</a><br>
Provider of Professional MapServer Support since 2000</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
mapserver-dev mailing list<br>
<a href="mailto:mapserver-dev@lists.osgeo.org" target="_blank">mapserver-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/mapserver-dev" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/mapserver-dev</a><br>
</div></div></blockquote></div><br></div>