Authorization DSL
Here is a tidbit that I worked on yesterday for the DSL book:
operation "/account/login" if Principal.IsInRole("Administrators"): Allow("Administrators can always log in") return if date.Now.Hour < 9 or date.Now.Hour > 17: Deny("Cannot log in outside of business hours, 09:00 - 17:00")
And another one:
if Principal.IsInRole("Managers"): Allow("Managers can always approve orders") return if Entity.TotalCost >= 10_000: Deny("Only managers can approve orders of more than 10,000") Allow("All users can approve orders less than 10,000")
There is no relation to Rhino Security, just to be clear.
I simply wanted a sample for a DSL, and this seems natural enough.
Comments
This looks like normal code to me... apart from the context setting first line. What makes it a DSL?
Rik,
This is normal code. In specific context, using a specific set of scenario.
This is supposed to be an example of a technical DSL.
What you see is the entire file, and you have whole sets of them.
This is probably a good example of why people are flocking to Ruby, writing a DSL for something like this becomes very easy.
IIRC, ADAM/AzMan has a similar capability using VBScript to validate defined Operations, however it requires Active Directory.
I keep having trouble with the operations named like paths or URLs. This sounds logical only if you're developing a web app, and even then it's not always the correct mapping. I'd rather go wilder and do something like:
operation login in account
Also, for a DSL I think I'd rather do something more like "if user in Managers" over "if Prinicpal.IsInRole("Managers")".
Avish,
Yes, that would be much nicer. But I am trying to show a simple DSL, not taking it to the far end.
How do you structure operations if they are free text?
There is a good reason that I like the path approach, they are very easily recognizable, have meaningful names and intrinsically hierarchical.
As this should be DSL I would like a approach like
if Not FormalDate.CurrentHour between 9 And 17:
Deny("Cannot log in outside of business hours, 09:00 - 17:00")
This is actually possible with a patch to Boo :-)
Macro operators
Ayende, qualified names are also meaningful and intrinsically hierarchical without resorting to string parsing. I'm uncomfortable seeing "/account/login", but less so when I see account.login.
Avish,
Paths are my preferences, they are immediately recognizable.
I have no issues, however, with structured strings that uses other delimiters. "account.login" or "order.approve" are just fine.
I actually built a system with that convention, it worked nicely.
Oh, I didn't mean a structured string. I meant a structured identifier. No quotes. I used period as delimiter because Boo's syntax allows qualified names as reference expressions, which is good for this scenario. The delimiter itself isn't important, it's the difference between a string literal that "looks" like a structured identifier (but requires parsing) and a qualified name, which is a structured identifier.
Oh, good point.
I am thinking more about the more general approach, specifically with relation to Rhino Security, which uses that approach
"if Not FormalDate.CurrentHour between 9 And 17:
Deny("Cannot log in outside of business hours, 09:00 - 17:00")"
I wish you could write even in more a bit of an "english":
if now.not.between 09:00 and 17:00
:)
Bunter,
This is actually possible.
Comment preview