Demonstration of using Solon auth authentication framework (simpler authentication framework)

I've seen several authentication frameworks recently , what Appache Shiro La 、Sa-Token La 、Spring Security La ... In especial Spring Security, As a benchmark Spring Boot & Cloud Framework Solon What's more, we should have our own biological safety certification framework . So in the adaptation Sa-Token（satoken-solon-plugin） and sureness（sureness-solon-plugin） after , Also developed Solon My son ：Solon Auth （solon.auth）. The goal is to be simpler 、 More direct , At the same time, it provides users with richer and different authentication framework options .

Solon Auth （solon.auth）

Solon Auth The location is , Only do authentication control . Focus on the adaptation of validation results , And the unified control and application based on it . Less functionality , But it doesn't get dizzy .

Solon Auth Support rule control and annotation control , Each has its own advantages and disadvantages , It can also be used in combination ：

• Rule control , It is suitable for the overall macro control in one place
• Annotation control , Easy to grasp in detail

One 、 Start to adapt , complete 2 Step by step

• The first 1 Step , Build an authentication adapter

@Configurationpublic class Config {    @Bean    public AuthAdapter init() {        //        //  Build the adapter         //        return new AuthAdapter()                .loginUrl("/login") // Set the login address , Jump automatically when not logged in （ If you don't set , The output 401 error ）                .addRule(r -> r.include("**").verifyIp().failure((c, t) -> c.output(" Yours IP Not on the white list "))) // Add rules                 .addRule(b -> b.exclude("/login**").exclude("/run/**").verifyPath()) // Add rules                 .processor(new AuthProcessorImpl()) // Set authentication processor                 .failure((ctx, rst) -> { // Set the default validation failure handling                     ctx.render(rst);                });    }}// Rule configuration description //1.include(path)  The path scope of the rule package function , Can be more //2.exclude(path)  The path pool of rule sort , Can be more //3.failure(..)    The treatment after the rule is lost //4.verifyIp()...  The verification scheme to be done by the rule （ There are many different verification schemes ）

• The first 2 Step , Implement an authentication processor

So let's see AuthProcessor The interface of , It connects a series of verification action results . Maybe users have to do more work themselves , But it's intuitive .

// Authentication processor public class AuthProcessorImpl implements AuthProcessor {    @Override    public boolean verifyIp(String ip) {        // verification IP, Have access to     }    @Override    public boolean verifyLogined() {        // Verify login status , Whether the user is logged in     }    @Override    public boolean verifyPath(String path, String method) {        // Verify the path , User accessible     }    @Override    public boolean verifyPermissions(String[] permissions, Logical logical) {        // Verify specific permissions , Users have limited rights     }    @Override    public boolean verifyRoles(String[] roles, Logical logical) {        // Verify specific roles , Whether the user has a role     }}

Now let's do an adaptive combat , Using a production environment code ：

public class GritAuthProcessor implements AuthProcessor {    /**     *  Get the subject Id     * */    protected long getSubjectId() {        return SessionBase.global().getSubjectId();    }    /**     *  Get the main display name      */    protected String getSubjectDisplayName() {        return SessionBase.global().getDisplayName();    }    @Override    public boolean verifyIp(String ip) {        // The installation mode , It ignores         if (Solon.cfg().isSetupMode()) {            return true;        }        long subjectId = getSubjectId();        if (subjectId > 0) {            String subjectDisplayName = getSubjectDisplayName();            Context ctx = Context.current();            if (ctx != null) {                //old                ctx.attrSet("user_puid", String.valueOf(subjectId));                ctx.attrSet("user_name", subjectDisplayName);                //new                ctx.attrSet("user_id", String.valueOf(subjectId));                ctx.attrSet("user_display_name", subjectDisplayName);            }        }        // Non whitelist mode , It ignores         if (Solon.cfg().isWhiteMode() == false) {            return true;        }        return CloudClient.list().inListOfClientAndServerIp(ip);    }    @Override    public boolean verifyLogined() {        // The installation mode , It ignores         if (Solon.cfg().isSetupMode()) {            return true;        }        return getSubjectId() > 0;    }    @Override    public boolean verifyPath(String path, String method) {        // The installation mode , It ignores         if (Solon.cfg().isSetupMode()) {            return true;        }        try {            if (GritClient.global().resource().hasResourceByUri(path) == false) {                return true;            } else {                return GritClient.global().auth().hasUri(getSubjectId(), path);            }        } catch (SQLException e) {            throw new GritException(e);        }    }    @Override    public boolean verifyPermissions(String[] permissions, Logical logical) {        long subjectId = getSubjectId();        try {            if (logical == Logical.AND) {                boolean isOk = true;                for (String p : permissions) {                    isOk = isOk && GritClient.global().auth().hasPermission(subjectId, p);                }                return isOk;            } else {                for (String p : permissions) {                    if (GritClient.global().auth().hasPermission(subjectId, p)) {                        return true;                    }                }                return false;            }        } catch (Exception e) {            throw new RuntimeException(e);        }    }    @Override    public boolean verifyRoles(String[] roles, Logical logical) {        long subjectId = getSubjectId();        try {            if (logical == Logical.AND) {                boolean isOk = true;                for (String r : roles) {                    isOk = isOk && GritClient.global().auth().hasRole(subjectId, r);                }                return isOk;            } else {                for (String r : roles) {                    if (GritClient.global().auth().hasRole(subjectId, r)) {                        return true;                    }                }                return false;            }        } catch (Exception e) {            throw new RuntimeException(e);        }    }}

Two 、2 Applications （ It is generally used in combination ）

Just now, we've adapted , Now it's time to apply .

• The first 1 Kind of , stay AuthAdapter Configure all rules directly , Or part of the rules （ Or not ）

// Refer to the adapter above  addRule(...)

The advantage of configuration is , There is no need to hack into the business code ; At the same time, in a unified place , From the macro perspective ; But it's easy to ignore the details .

• The first 2 Kind of , Do a part based on annotations （ General specific permissions or For a specific role ）

@Mapping("/rock/agroup")@Controllerpublic class AgroupController {    @Mapping("")    public void home() {        //agroup  home page     }    @Mapping("inner")    public void inner() {        // Internal list page     }        @AuthPermissions("agroup:edit") // Specific permissions are required     @Mapping("edit/{id}")    public void edit(int id) {        // Edit the display page , Need edit permission     }    @AuthRoles("admin")  // Need specific roles     @Mapping("edit/{id}/ajax/save")    public void save(int id) {        // Edit processing interface , Administrator privileges required     }}

The advantage of annotation is , Micro visible , On a method, you can see what permissions or roles it needs , It's not easy to ignore .

• Combined use

commonly , use Configuration rules , Control all the addresses you need to log in to ; use annotation , Control specific permissions or roles .

3、 ... and 、 Source code of this case

https://gitee.com/noear/solon_demo/tree/master/demo16.solon_auth

Four 、 Other production project applications

https://gitee.com/noear/water/tree/master/wateradmin

https://gitee.com/noear/sponge/tree/main/spongeadmin

attach ：Solon Project address

• Gitee：https://gitee.com/noear/solon
• Github：https://github.com/noear/solon

attach ：Solon Other introductory examples

• Solon Getting started example ：https://gitee.com/noear/solon_demo
• Solon Rpc Getting started example ：https://gitee.com/noear/solon_rpc_demo
• Solon Cloud Getting started example ：https://gitee.com/noear/solon_cloud_demo
• Solon Advanced tutorial examples ：https://gitee.com/noear/solon_advance_demo