Continuing from my last week’s update, this week was originally meant to be the one where I get started with implementing Oz protocol in PHP and then into my module. However, I ran into a severe limitation with the protocol itself that has forced me to reconsider my plan and drop Oz, instead shifting my focus back to my original Hawk module I had been working on during the past few weeks.
Limitation with Oz
As stated, during my previous two week’s updates, Oz is an authorization protocol. However, it misses a critical use case definition of allowing a user to grant an app permission to act on the user’s behalf. Take a case for example, there is a gallery website based on Drupal which also has a mobile app which is a hawk client. Now there is a user of the gallery using the mobile app and the user wants to allow the mobile app to post pictures automatically, for this the user would need to grant permission to the app to act automatically on their behalf. However there is no standardized flow within the Oz protocol which defines such behavior, the lack of this definition defeats the entire purpose of Oz. My mentor decided it is best to skip Oz and focus on the core Hawk module itself.
Going back to the module
Now that we had decided to skip Oz, it was back to the old module. Which, by the way, recently got approved as a full project and is now safely residing at drupal.org/project/hawk_auth. Feel free to read my other post about gaining maintainer access I wrote a short while back.
A couple of improvements I made to the module during this week were:
- Added ability to revoke permissions on a per-key basis.
- Separated the permissions to view and add credentials.
Ability to revoke permissions on a per-key basis
Each user can create multiple keys to go with them. They can use these keys to compartmentalize the credentials they are handing over. For example: A user can have 3 keys, one for their desktop, one for their laptop and one for their phone. A scenario that is entirely possible with me.
The user might want to limit each key’s permission, by default each key get all the permissions the user has but for someone using the key for a limited purpose that becomes an excess. To help this situation, I’ve allowed ability to revoke permissions on an individual key. Users can edit their keys such that they can remove certain permissions from each key restricting the access they would get while using that key. This helps secure their access as well as limit any damage that might occur in case the key gets exposed.
Revoking permissions internally is simple, it’s simply a matter of calling Role::revokePermission for any role which has the permission you want to revoke. However for administrator it becomes tricky, since they are not checked for permissions and by default are granted all. In order to solve this problem, internally I removed the admin status of the user and granted all permissions that exist except the ones we need to revoke. I’m hoping this replicates the same behavior as it would be for an administrator.
There is still one caveat with this approach, currently I only revoke the permissions during run-time, meaning it doesn’t get saved into the DB so that the role’s attributes remain normal during normal usage. However, if some other function saves the role’s data into DB, it can permanently write the revoked permissions into DB. In order to counter this, I revoke the “administer permissions” permission which removes the ability to save roles. Theoretically, a better solution would be to hook into entity hooks but I have yet to take a look into that approach.
Separated the permissions to view and add credentials
Previously it was a single permission which meant anyone with the hawk’s view permission could create the credentials as well, however I have separated the create permission from view. Now administrators can have the users see their credentials but not create them in case they want to restrict or control that aspect of the site.
For the week this is what I’ve done, I’ll continue improving the hawk module throughout the next week as well. There are a few ideas I want to implement to make the module easier and more flexible for general usage.