[MapProxy] mapproxy auth

[Oliver Tonnhofer]

Hi,

you could let the user first log in on a website and set a cookie. You could then validate the cookie in the MapProxy authorization middleware. If the cookie is not present, you can return the normal HTTP basic-auth response, so desktop GIS clients will still work.

See: AuthTktCookiePlugin in repoze.who or http://pythonhosted.org/itsdangerous/ 


Regards,
Oliver

-- 
Oliver Tonnhofer  | Omniscale GmbH & Co KG  | http://omniscale.com
OpenStreetMap WMS and tile services         | http://maps.omniscale.com



> On 03.03.2015, at 01:38, Pestereva, Anna <apestereva at aerialservicesinc.com> wrote:
> 
> Hello all, 
> 
> I wonder if anyone could share any advise on some more authentication situations:
> 
> 1) we enabled basic authentication for our Mapproxy service and it works great on desktop/server applications. It works as supposed in browsers too, but it would be great to avoid the standard browser prompt and do authentication in the code. Does anyone have successful example or a good reference? 
> We tried sending XMLHTTPRequest with Authorization header before requesting services, but run into two issues: it appears that due to CORS requirements we can only allow one origin in Apache config, which is not acceptable; and also after one successful XMLHTTPRequest Authorization header was not saved by browser and prompt appeared anyway when services were requested later.
> 
> 2) what type of authentication should be used for better usability of browser requests? Is there a method that would work well both in desktop and browser clients? If anyone could share any experience or sources, we will greatly appreciate!
> 
> Thank you!
> 
> On Thu, Mar 13, 2014 at 1:44 PM, Pestereva, Anna <apestereva at aerialservicesinc.com> wrote:
> Thank you, Matt,
> 
> originally I also thought that was the issue, but the 'REMOTE_USER' variable was requested and caused errors even before this condition, so it is unrelated.
> 
> With the help of Oliver Tonnhofer we figured that the issue was in apache config, where only /demo and /service locations were specified. Specifying general <Location /> made 'REMOTE_USER' available for all services.
> 
> Now off to fine tuning my authorization code.
> Thanks again!
> Anna
> 
> 
> On Thu, Mar 13, 2014 at 6:03 AM, Matt Walker <walkermatt at longwayaround.org.uk> wrote:
> Hi Anna,
> 
> I've not used OpenLDAP so I'm not in a position to comment no your first question but I have done some work with the various callbacks. If you are reporting that your auth callback is based on the example and that only requests with a service type of wms are authorised it sounds as though you may simply need to update the sample code to include support for tms etc. There is an explicit condition in the sample that will mean that only wms requests are authorised:
> 
> if service.startswith('wms.'):
> 
> Hope that helps,
> 
> Matt.
> 
> On 12 Mar 2014 22:36, "Pestereva, Anna" <apestereva at aerialservicesinc.com> wrote:
> Hello everybody,
> 
> I have two questions regarding authentication and authorization for Mapproxy.
> 
> We tried enabling basic authentication via OpenLDAP on the directory with Mapproxy configuration files. Without adding any authorization logic it works great for WMS, WMTS and TMS services and capabilities, but for several demo links (e.g. html viewers for WMS, WMS-C and TMS layer capabilities) we still see 401 errors in error logs.
> 
> Q1: is basic authentication on WSGI application configuration folder not sufficient as approach, or are we just missing something in configuration? Could you please point us in a right direction, if this at all is meant to work?
> 
> 
> On authorization side, I attempted a simple version very similar to the sample code on Mapproxy documentation, just using environ['REMOTE_USER'] when comparing to the layers prefixes. This works great for WMS service, but for WMTS and TMS services (and a few demo links) we see errors in error logs related to reading the "remote_user" variable in authorization code: KeyError: 'REMOTE_USER'. 
> 
> Q2: how to make sure that "remote_user" variable is populated and available when accessing all services, not just WMS? Should some other variable be used to catch authenticated user? - again, if it at all makes sense to use basic authentication for mapproxy.
> 
> Thank you very much, I will really appreciate any help with any of the above questions!
> -- 
> Anna Pestereva | Application Developer & Cartographer
> Aerial Services, Inc. (ASI) 
> Office: (319) 277-0436 | Direct: (319) 553-0261 | Mobile: (319) 830-6340 | Fax: (866) 800-4799
> 6315 Chancellor Drive | Cedar Falls, Iowa 50613 
> APestereva at AerialServicesInc.com | LinkedIn
> www.AerialServicesInc.com | Photo{blog}metry
> 
> _______________________________________________
> MapProxy mailing list
> MapProxy at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapproxy
> 
> 
> 
> -- 
> Anna Pestereva | Application Developer & Cartographer
> Aerial Services, Inc. (ASI) 
> Office: (319) 277-0436 | Direct: (319) 553-0261 | Mobile: (319) 830-6340 | Fax: (866) 800-4799
> 6315 Chancellor Drive | Cedar Falls, Iowa 50613 
> APestereva at AerialServicesInc.com | LinkedIn
> www.AerialServicesInc.com | Photo{blog}metry
> 
> 
> 
> -- 
> Anna Pestereva | Application Developer & Cartographer
> Aerial Services, Inc. (ASI) 
> Office: (319) 277-0436 | Direct: (319) 553-0261 | Mobile: (319) 830-6340 | Fax: (866) 800-4799
> 6315 Chancellor Drive | Cedar Falls, Iowa 50613 
> APestereva at AerialServicesInc.com | LinkedIn
> www.AerialServicesInc.com | Photo{blog}metry
> _______________________________________________
> MapProxy mailing list
> MapProxy at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapproxy