As discussed in the Access Control Overview, each of the generated services end-points is assigned a name which is used as an Authorization object by the router middleware.
Standard CRUD end-points for entity Library are generated as follows:
// ====================== Library protected routes for standard CRUD access ======================
a.router.HandleFunc("/librarys", requireUserMw.ApplyFn(a.libraryC.GetLibrarys)).Methods("GET").Name("library.GET_SET")
a.router.HandleFunc("/library", requireUserMw.ApplyFn(a.libraryC.Create)).Methods("POST").Name("library.CREATE")
a.router.HandleFunc("/library/{id:[0-9]+}", requireUserMw.ApplyFn(a.libraryC.Get)).Methods("GET").Name("library.GET_ID")
a.router.HandleFunc("/library/{id:[0-9]+}", requireUserMw.ApplyFn(a.libraryC.Update)).Methods("PUT").Name("library.UPDATE")
a.router.HandleFunc("/library/{id:[0-9]+}", requireUserMw.ApplyFn(a.libraryC.Delete)).Methods("DELETE").Name("library.DELETE")
Notice that each end-point handler is assigned a name via the gorilla.mux.Route.Name(“string”) method. The generated end-point names follow the standard shown here, but in practice it is safe to change them to whatever works best for your implementation. Duplicate names in the same router will cause the existing name-route combination to be overwritten by the latest name-route addition as per the gorilla API docs. Avoid the use of duplicate names. The set of generated Authorizations for the Library entitys CRUD end-points are:
Static Filter end-points for entity Library follow the same rules as mentioned above and are generated as follows:
//=================================== Library Static Filters ===================================
// http://127.0.0.1:<port>/librarys/name(EQ '<sel_string>')
a.router.HandleFunc("/librarys/name{name:[(]+(?:EQ|eq|LIKE|like)+[ ']+[a-zA-Z0-9_]+[')]+}",
requireUserMw.ApplyFn(a.libraryC.GetLibrarysByName)).Methods("GET").Name("library.STATICFLTR_ByName")
// http://127.0.0.1:<port>/librarys/city(EQ '<sel_string>')
a.router.HandleFunc("/librarys/city{city:[(]+(?:EQ|eq)+[ ']+[a-zA-Z0-9_]+[')]+}",
requireUserMw.ApplyFn(a.libraryC.GetLibrarysByCity)).Methods("GET").Name("library.STATICFLTR_ByCity")
The set of generated Authorizations for the Library entity’s static filter end-points are:
Relation end-points for entity Library follow the same rules as mentioned above and are generated as follows:
//====================================== Library Relations ======================================
// hasMany relation ToBooks for Library
a.router.HandleFunc("/library/{library_id:[0-9]+}/tobooks",
requireUserMw.ApplyFn(a.libraryC.GetLibraryToBooks)).Methods("GET").Name("library.REL_tobooks")
a.router.HandleFunc("/library/{library_id:[0-9]+}/tobooks/{book_id:[0-9]+}",
requireUserMw.ApplyFn(a.libraryC.GetLibraryToBooks)).Methods("GET").Name("library.REL_tobooks_id")
The set of generated Authorizations for the Library entity’s relation end-points are:
Authorizations are assigned to end-points in the route declarations as described in the preceding sections. They are also added to a table (auth) in the backing database, as are the User Groups (table usrgroup) and the assignment of Authorizations to the same (via table groupauth).
At application start-up, a walk of the router is performed in order to obtain a complete list of Authorizations. This is necessary, as changes may have been made to the application since the last time it was run. For example, a new entity may have been added; the Authorizations for the corresponding end-points need to be made available via the creation of new entries in the auth table. The creation of the new Authorizations in the auth table does not add them to any User Groups, but simply makes them available for use.
The end-points related to Authorization, User Group and User maintenance are protected by default. This means that in order to perform any activities (such as create Users) in the generated application, an initial User belonging to a User Group with sufficient Authorizations is required. To this end, a User called ‘admin’ and a User Group called ‘Super’ are created by default the first time the application is run. This unfolds as follows:
It is possible to force a rebuild of the ‘Super’ User Group’s Authorization allocations by starting the generated application with the -rs (rebuild super) flag. This will force the application to run through the preceding list of steps, resulting in a ‘Super’ User Group that contains a complete list of the Authorizations needed to access all end-points, as well as removing any end-point Authorizations that may no longer exist. Only the ‘Super’ User Group may be updated in this manner. Changes to existing User Groups must be carried out manually by an authorized user via the end-points related to User, User Group and Authorization maintenance.