2018-12-19
in
3 min read
It’s been almost a week since there’s been an update on the API. I’ve been busy with other things and travel so it didn’t get as much focus as I would have liked to have given it. However there has been some progress. Thanks to Frank ’s help we’ve been able to get all of the side branches merged into the core API branch so that we are now coming down the home stretch on getting it ready for integration. The first order of business for that is getting the OpenID security stuff squared away. I’m still working on understanding that better and the more I go back to it and work with it here the better that looks. There is still the question of the "refresh token" workflow but work has been done on it so if anything it’s a small tweak thing or a documentation thing versus a from scratch development thing. Even in the event that it was a from scratch thing with the code base I have and the examples I mentioned before it shouldn’t be a huge effort to get that working. Most of the security work is therefore integrating in the much more fine grained security scopes which Senya has been working to hone.
In the original incarnation the API essentially had read and write permissions that an application could request. That was universally applied. However a more fine grained approach is what’s really in order. If I’m writing an application that is supposed to just ping you every time a new notification comes in I should only be asking for access to your notifications data. If I’m looking to write something that ingests your public posts data but never post anything for you I should only be looking asking for permissions for that. In OpenID these are managed with things called scopes. The application asks for specific scopes, such as contacts:read or public:modify which the user then is made of aware of when Diaspora prompts the user for permission for the application to connect. At this point all of that is now in the library. There are some more complicated behaviors that now need to be implemented. For example if you didn’t give the application access to “private” data then when the method to get your posts returns it shouldn’t have any of the non-public posts. Similarly if you get another user’s posts without the private data permissions you should only see their public posts as well not posts that were shared explicitly with you.
Once those changes are done, hopefully today, then the next thing is to finally get the whole OpenID workflow with refresh tokens (or some other way to refresh credentials without prompting the user) confirmed. The home stretch is then a final code scrub for consistency and then it’s time to initiate the pull request (PR)
In summary:
- All previous work is now in the API branch
- Fine grained scopes are coded up in all API endpoints
- Private data filtering behaviors underway
You can follow the status dashboard at this Google Sheet as well