mirror of
https://github.com/go-admin-team/go-admin.git
synced 2026-09-22 10:33:13 +00:00
DemoEvn decided by HTTP method: GET and OPTIONS through, everything else refused. Three of the code generator's routes are registered as GET and write anyway - two emit Go source files onto the server's filesystem, and the third inserts menus, APIs and casbin rules into the database. They sit in a group whose own name says it does no role check, and a demo deployment lets anybody log in. So on the demo host any visitor could write to the machine and to the database, and the one that writes menus had in fact been used: three generated SysCasbinRule entries is how this was noticed. The guard now also looks at the matched route. The method cannot answer the question - whether a request changes anything is not something the verb reports truthfully here - so the three are named, as gin route patterns, which is what Context.FullPath returns and how CasbinExclude already spells them. Changing them to POST would be the better shape and is not this change. sys_api records an endpoint by method and path and the casbin policy follows it, so flipping the verb needs a migration and a policy resync; until both land, every existing deployment would start answering 403 to a role that could use the generator the day before. The read-only half stays reachable: preview, the table tree, and the two database listings. A demo host that cannot demonstrate the generator is as broken as one that lets visitors write to it - refusing too much is the same defect facing the other way, and there is a test for that direction too. Half of the general hole is closed and the other half is written down. The closed half is a test beside the route registrations: it builds the generator's routes, enumerates them, and fails if any entry in the guard has stopped being a real route, so renaming one turns the list red instead of quietly making it match nothing. It lives there because common/ may not import app/ - which is also why the guard cannot check its own list from where it is. The open half is that no static check can tell a handler that writes from one that reads, so the next GET that writes has to be added by hand. The comment says that rather than leaving the impression the class is covered. application.demomsg was configuration nothing read. The message was hard-coded in the middleware, and the demo host's configured string happened to be identical, so the setting looked like it worked and never had. It is read now, with the old string kept verbatim as the fallback, so a deployment that never set it is answered exactly as before. This covers demo mode only. On a deployment that is not a demo those three routes remain in CasbinExclude and stay reachable by any authenticated user whatever their role; that is a separate decision and is not touched here.