[Tilecache] Tilecache Authentication

[Attila Csipa]

On Thursday 17 January 2008 15:16:26 Christopher Schmidt wrote:
> I don't think that's entirely true. For some use cases ,it is -- but for
> example, with Mapnik -- or for OpenAerialMap -- it's the *only* Server
> for the tiles. It caches as well, but there is no seperate server on the
> backend: TileCache has logic built into it, which uses mapscript to
> actually generate the tiles.

I'd argue on this point a bit. While it is convenient to have such 
functionality there, it's only because the underlying data (providers) do not 
have such functionality. Think about it this way - if you are using squid (a 
web proxy/caching software for the casual readers), it is convenient to 
authenticate your users since they are already going through it. Is maybe 
tilecache turning into a smart proxy/load balancer instead of just being a 
cache ? I'm asking this as I mostly use tilecache just as a cache, so it's a 
drop in replacement for my WMS layers - I use those for development, and 
public clients use the tilecache version.

> I think that most WMS Services don't provide authentication -- in part,

> to TileCache: TileCache is the 'public' face of the 'private' internal
> service. The patch to add username/password support to WMS requests
> takes this into account: you set up auth to the backend service, but
> this isn't the same as the auth your users will use to get into
> TileCache.

Yep, that's hat I presumed above - then IMO we are talking more about a proxy 
than a cache. Maybe the tilecache name has mostly historical reasons (which I 
mistakenly then thought to have caching as the core service), but if it IS to 
be treated as a proxy in fact, then I agree with you for the same reasons ;) 
(and still think auth should be outside, just like squid has external 
authenticators, whether they rely on PAM, or some mysql wrapper). 

> That said, if there's some scheme for which passing through
> authentication makes sense, I'm willing to put in a patch, so long as it
> doesn't negatively affect other users. (The WMS password one is
> something I'll get in this weekend, for example.)

Well, HTTP_AUTH is the first choice that should be passed through (the problem 
with HTTP_AUTH being on the client side). As for mapscript (and for directly 
using images), it's not nearly as clear. I have, for convenience reasons, 
used HTTP_AUTH for these too - having htpasswd-d the .map files in question 
(or .jpg, doesn't matter) even though they weren't in webspace - so I can 
just say 'if you have rights to the .map file you have rights to whatever 
image comes out of it'. This is not perfect so I wouldn't recommend it as a 
patch instantly, but it will hopefully pop out an idea or two from the people 
here.