The good bit of code is because there's mix of a REST client with something to parse the results. If I'm not mistaken, I think it doesn't use any sort of separate XML parser, which just adds more lines of code.

I'd rather not rewrite things that don't need rewriting, though. I think it should be pretty simple to change the authentication method that it uses. The authentication happens exclusively in FamilySearchProxy.php in FamilySearchProxy->authenticate().

The main failing on my part is I don't know how to implement OAuth, so I'm not sure how simple it would be to plug in OAuth-style authentication. From what I understand, I think we should be able to have the admin authenticate for the site separately. Then the FamilySearchProxy can make use of the OAuth key to connect and do it's magic.

> The FamilySearch Identity API is a collection of web services that allow applications to authenticate and identify users of the FamilySearch system. Version 2 of the Identity API provides these capabilities in conformance to the OAuth specification, ensuring that third parties can authenticate users without requesting or handling the user's credentials.
> For details of what OAuth is and how it works, we defer to the primary references. (Note that the Identity API conforms to the OAuth 1.0a specification.)
> Content Location
Details of OAuth and its specification http://oauth.net/
The OAuth specification (Core 1.0a)

http://oauth.net/core/1.0a

Libraries for most languages to help implement the oauth protocol http://oauth.net/code
A good diagram and description of the OAuth flow http://developer.yahoo.com/oauth/guide/oauth-auth-flow.html

Comments

davad’s picture

davad commented
Assigned: Unassigned » davad

I've pushed some almost functional code to https://github.com/davad/fsapi.

The OAuth stuff is implemented and working, but it's implemented in the drupal admin page, so the nonfunctional part right now is that the PHP-FamilySearchAPI that we're wrapping around doesn't know how to make use of the OAuth access token yet. That should be simple to implement, but I'm getting a little braindead now, so I'm stopping for the afternoon.

A brief rundown on how OAuth works:
Step 1: The drupal site gets a request token from the OAuth server
Step 2: The user visits the authorize URL (http://www.dev.usys.org/identity/v2/authorize?oauth_token=REQUEST_TOKEN)
Step 3: If the user authenticates correctly, he is redirected back to the callback page (specified by drupal when getting the request token). The redirect includes a verifier token as a GET parameter.
Step 4: The drupal site uses the verifier token to get an access token.
Step 5: The access token acts the same way that session IDs did in v1 of the identity module.

According to the docs, sessions expire after 20 minutes of inactivity. I'm not sure if OAuth access tokens are treated differently than normal session IDs or if that isn't the right expiry time, but I was able to use an access token after a good 40 minutes of inactivity. I'll try again tomorrow to see if it's still valid.

kyle_mathews’s picture

kyle_mathews commented

I looked through the code and things look pretty good. I pulled the changes and the admin page worked just fine but I couldn't test the actual authentication as I don't have an API key yet (I just applied) OAuth authentication is more straightforward than I thought to implement. One question then. What does the PHP OAuth library above and beyond this?

davad’s picture

davad commented

I'm not really sure.

davad’s picture

davad commented

I just tried to reuse the old session id, and it had expired.

davad’s picture

davad commented
Status: Active » Needs review

I've modified the external familysearch api library to use the oauth-supplied access token. The reference API server is down right now for maintenance. As soon as it's back up, we need to test that the api library is using the access token correctly.

davad’s picture

davad commented

Need to look into letting users other than the site admin do OAuth authentication in order to get biographical data for persons referenced in newly added stories.

davad’s picture

davad commented
Priority: Normal » Minor
Status: Needs review » Postponed

Kyle, Ben and I met with Gordon Clarke, a product coordinator for FamilySearch Web Services. He was very excited for what we're working to build, but explained that many of the genealogical records on FamilySearch are mired in uncertain legality when it comes to publicly viewing them on the web.

Many were acquired from various organizations before the internet become the pervasive force it now is. Gordon said that he hopes to make a public facing service available for use cases like ours, but can't hazard a guess about when it would be possible to do so.

In the mean time, the fsapi module I built intending to use with this family history distro works pretty nicely. It connects using oAuth and can currently be used to retrieve person records by unique identifier or can be used to search for people by name. FamilySearch has no problem with people using it, but the site it's implemented on will need to have each user interested in viewing FamilySearch records authenticate via oAuth (which will require a little tweaking from the current setup).