Allow rules take in an actor (which comes from authorization logic) and a resource (which comes from mapping). Sometimes you need some additional context information about the environment to write rules over.
For example, let’s say you have a policy like this:
allow(actor, _action, _resource) if role(actor, "admin");
Here we have a very simple allow rule that allows an actor to access any resource if they are an admin. Maybe we want to also let any actor access any resource when the app is in development mode. A typical way to flag that an app is running in development or production mode would be to set an environment variable, e.g.
How would we read that environment variable from our policy though?
We can use a application class that lets us directly access the environment variables.
The above class exposes a var method that reads the application’s environment variables and returns the value asked for. We can then register the class with
register_class, which will let us instantiate it in the policy.
We can add a new allow rule that allows an actor to access a resource if the application is in development mode.
allow(_actor, _action, _resource) if Env.var("ENV") = "development";
Application classes make it easy to expose any sort of application data to your policy, including environment variables and request context. This simple pattern lets you expose any kind of data you want to use in your policy, not just