[OSM-dev] Setting up editing interface on www.openstreetmap.org

Christopher Schmidt crschmidt at metacarta.com
Tue Nov 28 03:40:45 GMT 2006


On Tue, Nov 28, 2006 at 01:27:23AM +0000, Nick Hill wrote:
> Hello Christopher.
> 
> 
> Christopher Schmidt wrote:
> >I have an existing Python CGI script which makes it simple for me to do
> >editing via the OSM API with my username. In order to have edits be
> >attributed to the user who made them, I need some access to the user
> >credentials such that I can reuse them. Unfortunately, it seems like
> >this access is not possible via anything that is currently set up.
> 
> I don't understand why the script will need access to OSM credentials. I 
> would presume the user will provide credentials which can be cached 
> client-side and passed to the CGI script.

Essentially, I don't want my code to have to touch usernames or
passwords. My phrasing in this email was probably off, so I'm probably
being less clear than I could be. I'll try and rephrase where
appropriate.

> >I can modify my Python CGI script so that it will PUT data via an
> >XMLHttpRequest -- this will ask the user for the login name/passfor
> >the OSM API when the PUT is committed. This is the minimal effort for
> >me: I could convert my Python CGI script to do this in something like an
> >hour. This means putting a small Python script (which would mostly look
> >like http://labs.metacarta.com/osm/edit.txt) on the OSM server, under
> >the www.openstreetmap.org domain.
> 
> 
> >
> >Alternatively, I could modify the script to use the database directly,
> >rather than the API. Since I don't know Ruby, this would probably be
> >high cost for relatively little gain, comparitively. (If I had to
> >rewrite my code to ruby, it would probably simply never happen.)
> 
> Again, I think I am missing something; the OSM API is accessible through 
> http. 

Yes, but if I only have access to the OSM User cookie, I can't use the
OSM API, because the cookie can't be used to lookup a username and
password with which the OSM API can be used. This means that the only
way to do it is to: 
 
 * Have a second entry form for username/password (which I'm trying to
   avoid)  or
 * use the OSM DAO DB access directly


> The only layer which AIUI is ruby-specific is the data access object, 
> a layer below the API containing a collection of SQL queries. Below the 
> DAO, we have the raw MySQL connection.

> >Essentially, the edit.txt above is a simple attribute editor. It would
> >let anyone edit the attributes of a way by going to edit.cgi?way=43245,
> >which I think would be a useful tool to have in general, but I'm not
> >sure how you feel about putting it under the OSM domain. (Obviously, it
> >would be placed into SVN and under OSM's control, not mine.)
> 
> I would characterise this as an extension of the API, with a paradigm shift.
> 
> In the same way as the API requires http auth, the intermediate script 
> could require auth (whether plain text or cyphered) which in turn 
> percolates to the OSM API. Am I on the right track, or am I 
> misunderstanding?

I'd prefer not to do that. Having three places where I have to enter a
password doesn't make sense (one to login on the site, one to login to
the API, one to login to the editing script). So, I can combine the last
two, assuming that I can put the script on www.openstreetmap.org, cause
I can make all the requests to the API go directly *to* the API, via
XMLHttpRequest.

> Assuming I am on the right track, could you look at whether credentials can 
> percolate from the client, through your script to the OSM http API? I may 
> be able to help with this if you find a blocker.

The only way to get from the client to the script is adding another
username/password form. If we're running under www.openstreetmap.org,
then I don't need to do that -- if we're not, then I'm not willing to
add a username/password entry field. I just don't think it's a good idea
to ask users to enter their username and password into a remote website.

Regards,
-- 
Christopher Schmidt
MetaCarta




More information about the dev mailing list