CUNY Academic Commons

A summary of progress to date.

For the moment, I"m using the WP OAuth Server plugin to act as a provider. https://wordpress.org/plugins/oauth2-provider It's imperfect, but it is probably workable. I've got a request in with the plugin authors to see if they'll be willing to accept some PRs or patches so that it'll be possible to use without monkey patches.

One of the important mods (I'm putting this here mainly for my own reference) is that the plugin automatically sets the WP current user based on the oAuth access_token. This makes sense in theory, but in practice it is wonky: it means that the client can perform any action that the WP user can perform - creating new posts, updating profile data, etc - regardless of the client 'scope'. The plugin is written in a lousy way that makes it hard to unhook this behavior. One of the main things I'll be asking them for is a simple toggle. We will then write our own endpoints with proper cap checks, or override the relevant parts of WP's permission_check() methods.

The basic flow works like this:
1. You go to a client site (this would eventually be cuny.manifoldapp.org and others) and click the "Log in with the CUNY Academic Commons" button or whatever. authorizationUrl is https://commons.gc.cuny.edu/?oauth=authorize&response_type=code&client_id=[client_id]&client_secret=[client_secret]&redirect_uri=[redirect_uri]
2. A window pops up. For consistency, I've designed it so that it has the same dimensions as the Google oAuth window currently used by Manifold.
3. If you're not logged into the Commons, you'll see the login form. See 'login' screenshot.
4. Once logged in, if you have not yet authorized this client application, you'll be asked to do so. See 'authorization' screenshot. The "scopes" here - email address, etc - are half working, in the sense that the messages you see here are generated based on the scopes that are assigned to the client, but they are not actually attached to the oAuth requests themselves. See the comment above.
5. The client will then be responsible for closing the window, redirecting, etc.

On the Commons side, users can see a list of authorized applications at Settings > Applications. See 'applications' screenshot. Access to them can be revoked on a case-by-case basis. See 'revoke' screenshot.

A technical note that WP oAuth Server stores clients as a WP post type. The client URL and client logo are not natively stored by the plugin. I just added them manually as postmeta. This is fine for the time being, but is another thing I'll need to work with their people to address.

Next steps:
1. Any feedback on this flow would be welcome.
2. I'll continue to work with WP oAuth Server folks to get the necessary improvements.
3. I'll write REST API endpoints that allow applications to fetch items in a way that's sensitive to the scopes of the clients. I think that for the time being this'll be a 'profile' endpoint that gives back email and/or profile data based on the 'email' and 'profile' scope assigned to the client whose key is in use.

Once 3 is done, I'll try to wrap everything up into a set of instructions that can be passed along to the Manifold team.

Tabling this feature, pending additional steps from Cast Iron.