Wednesday, December 9, 2015

The light at the end of the tunnel

So, we are now approaching a quite useful state when it comes to OSM editing of POIs in GNOME Maps.
Since my last blog post in Novemeber we now have a working sign-up using OAuth 1.0a.


 Sign in with e-mail address and password


 A verification form will be shown (this differs from the OAuth 1.0 protocol used by JOSM, by the way, which does this using only the login name and password, but OAuth 1.0a is the recommended protocol to use for OSM, as I understand it there has been security issues with the 1.0 protocol).

After entering the correct verification code the account will be signed in:




And now, for the first time in my entire life, I've implemented a circular button (for the edit button) :-)

The rest of the editing UI looks just like before:




Worth noting is that just like in the mockups, if you click on the edit button without first having signed in, the account setup dialog will show up, and on successful log in will proceed to the editing dialog automatically.

There has been some hair-pulling during this phase for getting the OAuth negotiation going.
Furthermore OSM is using a REST API with PUT (and DELETE, but we don't currently support deleting objects) HTTP request with data in the request body of the HTTP message. As it turned out, librest (which we use now for doing OAuth-authenticated calls, doesn't support setting the response body directly.
Luckily there is an overridable virtual function for serializing the request in the RestProxyCall class, so it was possible to write a custom proxy call class inheriting OAuthProxyCall (which in turns inherits RestProxyCall, and handles the OAuth authorization headers) with a serialization function to upload the OSM objects. Thanks to Christophe Fergeau for pointing me in this direction by the way!

And ofcourse the OAuth access token and token secret are stored in the keyring (using libsecret, so I think it should work with other implementations, such as KDE's kwallet, but I have only tested against gnome-keyring).

So, we are in a pretty decent state for the upcoming 3.19.3 development release next week. Will probably add some additional editable fields.
I guess you could see this as an early christmas gift.

Oh, and by the way, the earlier work-around with giving the credential via environment variables is history now :-)

2 comments:

  1. I have no idea how feasible it is but it would be nice to share login info with Epiphany so that you only have to log in once.

    ReplyDelete
    Replies
    1. Not sure how feasible this would be.
      Also, I'm not sure if would be a good idea to share OAuth tokens with the iD editor (which is how I think it would need to work then) is really what you want to do, since they are separate applications.

      Delete