<snusnu>
also i haven't yet really evaluated those, looked into the code etc
<mbj>
snusnu: I prefer not to use rack based middlewares these days.
<mbj>
snusnu: Building middlewares on top of the request and response libs is very easy. I need to factor out an middleware builder.
<snusnu>
yeah, that'd be cool, then again, i'm not familiar with all the details, so rolling my own at this point isn't exactly a great idea either
<snusnu>
(re ssl support ie)
<snusnu>
however, it seems that the code i use now has lots of features/options i don't use, so i might switch to josh/rack-ssl which seems really small
<mbj>
snusnu: yeah
<snusnu>
what about cranking out that middleware builder concept now?
<snusnu>
;)
<snusnu>
mbj: that reminds me, what about merging my PR's to request/response now?
<mbj>
snusnu: hehe, I'm on some unparser/mutant stuff.
<mbj>
snusnu: I'll look into them "soon".
<snusnu>
hehe ok
<snusnu>
i was just suggesting because you said you're trying to find some oss task :)
<mbj>
snusnu: If you are okay with them: Just merge. You have access to the repos, and I trust your judgement.
<snusnu>
btw, i'm thinking about using morpher for my authorization needs
<snusnu>
basically, i have a few rules, and i need to reuse and combine them for differerent actions
<mbj>
snusnu: Thats interesting.
<mbj>
snusnu: Also it would allow you to "review" authentication errors that way.
<mbj>
snusnu: I have some thoughts about shortening evaluation trees.
<snusnu>
in my architecture, i have a dedicated substation handler registered when entering the "core app", which performs authorization (it gets the (sanitized) params, the actor and the env injected)
<mbj>
snusnu: *reporting of failed evaluation trees.
<snusnu>
yeah, that'd be cool, in fact, cooler probably than unparser stuff :p
<mbj>
snusnu: Are there stateful components of the ENV? Deeper inside the processors I sometimes miss to access some precomputed stuff.
<snusnu>
storage is a leftover it seems, can be accessed via the model
<snusnu>
anyways, i don't really know what you mean by stateful components, what's in the env, is immutable, and stuff that can be set up at app boot
<mbj>
snusnu: I'll explain that another day.
<snusnu>
re precomputed stuff, one thing i do, is load all user groups and their according privileges at boot, so that i can perform fast "initial authorization"
<snusnu>
by initial authorization, i mean if an actor is allowed to call a specific (named) usecase in the firstplace
<snusnu>
i call that concept (substation handler) "guard"
<snusnu>
it's called as one of the first things, rejecting any requests an actor definitely isn't allowed to do
<snusnu>
real authorization happens deeper in the core app (so that it also happens when not used on the web)
<mbj>
snusnu: interesting
<snusnu>
it checks wether the given params are within the user's logical privileges
<snusnu>
and i have a few rules, like, is some params[:company_id] the same as the actor.company_id as assigned by session
<snusnu>
and a few others
<snusnu>
and i need to combine those in different ways for different actions
<snusnu>
so i was thinking about building a morpher predicate evaluator
<snusnu>
with custom transformers (my auth rules)
<mbj>
snusnu: nice idea.
<snusnu>
obviously, #inverse makes no sense, but it should provide nice insight into what was passed in and why it was rejected .. but mostly, i'm looking after the declarative way of combining the rules with (mostly) AND and OR
<mbj>
snusnu: I expect that a morpher predicate like this is not inversible.
<mbj>
snusnu: Morpher has nice support to model unbijective transformations.
<mbj>
snusnu: Evaluator#transitive? tells you if #inverse makes any sense.
<mbj>
snusnu: Never call #inverse without knowing #transitive? is true. I'd probably test for #transitive? => true when registring evaluators.
solnic has joined #rom-rb
<mbj>
snusnu: s(:primitive, String) will return #transitive => true, becaue its not inversible.