Thoughs on Gorbac

This is a creation in Article, where the information may have evolved or changed.

Code refactoring is a easy job, but it had to be do in most of the times. I just completed the lightweight role based access control Library:gorbac ' s refactoring. There is some feedbacks and questions about the design and usage. I think it would be better writing something to share some design ideas and practice principles which would make things EAS Ier.

The master branch of current Gorbac ' s source code was intended to be Version 2. While the previous version have been tagged as version 1 with the V1.dev branch on Github. And this article would only discuss Version 2 (the Master branch).

The new design separates Gorbac into 3 Parts:core, interfaces & implements, and helper functions.

The core is the major part of Gorbac and manages inheritance relationship of roles. It contains only one struct ' RBAC ' with 8 methods. It's easy-to-understand and use. What's need is reading the document.

' Role ' is the only interface communicating directly with ' RBAC '. It has both methods: ' Id ' returns the identity of a role and ' Permit ' checks if the permission is permitted to a role. For example, you can implement a Role named ' God ' and have all permissions as the God.

Type God struct {}func (g *god) Id () string {    return "God"}func (g *god) Permit (P Permission) bool {    return True}

For making things easier, GORBAC have a built-in role ' stdrole ' which can be used in a real-life application and also be a Good example for anyone the want to write their own ' Role ' implementation. Moreover, when you implement your own ' Role ', struct embedding can your good friend.

Eg.,

Type myownrole struct {    Gorbac. Stdrole    //extra fields}//extra functions

Another important interface is ' Permission ' which are only communicating with ' Role '. It also has a methods: ' Id ' and ' Match '. ' Id ' is the identity of a permission. ' Match ' is used-detect if current permission matches another one.

The library also supplies and built-in structs for ' Permission '.

First one is ' stdpermission ' which uses ' Id ' to detect if both permissions is matching.

Another one is ' layerpermission ' which supports multi-layers matching and can being very useful to design something like ACCE SS management of Control panels. To is exact, permission "admin" matches "admin:article" and "Admin:article:delete"; "Admin:article" matches "Admin:article:delete", but you'll get a negative result by reversing matching.

If you had some "hard mode" access control, implementing your own ' Permission ' was a good idea.

Eg.,

Type fuzzpermission struct {    idstr string}func (f *fuzzpermission) Id () string {    return F.idstr}func (f * fuzzpermission) Permit (P Permission) bool {    if f.idstr = = P.id () {//exactly matched        return true    }    Q, OK : = P. (*fuzzpermission)    if!ok {//not same type        return False    }    return strings. Contains (F.idstr, P.id ())//Well, I ' m not sure what circumstance can use this kind of permissions}

To be Continued ...