Filters - not what you're thinking

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Filters - not what you're thinking

Dustin Whitney
Hey all,

What strategies do you guys use when something needs to run before/after each case statement in your intents?  For example, what if you need to make sure a user is authenticated.  I have been doing something like this

case Path("/foo/bar.html", IsAuthenticated(user)) => ...
case Path("/foo/bar.html", _) => //redirect to login page

That's not too bad, but it's a little smelly if I need the authentication check on every url.   I've also thought of doing something like

//doesn't need authentication
server.filter(someEndpoint)
...
//authenticaticator
server.filter(authFilter)
//needs authentication
server.filter(someEndpointThatNeedsAuthentication)

The problem with this strategy is I add Plans dynamically at runtime depending on different config values, and coordinating the order of filters gets out of control.

What do you think about adding "before" and "after" methods to Plan that are called before and after invocation of intent?

Dustin
Reply | Threaded
Open this post in threaded view
|

Re: Filters - not what you're thinking

n8han
Administrator
On 12/21/2010 10:08 AM, Dustin Whitney [via Databinder] wrote:
> The problem with this strategy is I add Plans dynamically at runtime
> depending on different config values, and coordinating the order of
> filters gets out of control.
>
> What do you think about adding "before" and "after" methods to Plan
> that are called before and after invocation of intent?

That sounds a lot like the filter spec to me. Maybe our jetty server
builder should just be better. :\

I think there are probably good solutions for this inside the app too,
though I haven't tried it myself. Something like:

val top = unfiltered.filter.Planify {
     case IsAuthenticated(user, req) => Authed(user)(req)
     case Path("/foo/bar.html", _) => //redirect to login page
}

object Authed {
     def apply(user: User): unfiltered.filter.Plan.Intent = {
         case Path("/foo/bar.html", _) => ...
         case Path("/foo/other.html", _) => ...
     }
}

I guess you would want to check that the intent returned by Auth.apply
is defined.

val top = unfiltered.filter.Planify {
     case IsAuthenticated(user, req) if Authed(user).isDefinedAt(req) => ...
}

That needs some work obviously but it seems like it could be a
profitable direction, and maybe yield some kind of intent-chaining
extractor that we could put in the library.

By the way, are you in New York or something Dustin? I noticed you
rsvp'd to tueday's meetup!

Nathan
Reply | Threaded
Open this post in threaded view
|

Re: Filters - not what you're thinking

soft_props
I like where this is going. This sounds like a better solution than my maybe failed attempt and at around filter unfiltered.response.PassAndThen (in filter module).

Look forward to seeing what you've been up to Dustin!
Reply | Threaded
Open this post in threaded view
|

Re: Filters - not what you're thinking

Dustin Whitney
Yeah, I like Nathan's suggestions.  I'll try them out and give some feedback if I find it doesn't work for me, but it looks pretty good.

Yes, I'm in NYC this week, and fortunately there's a Scala meetup!

D

On Sun, Jan 2, 2011 at 5:46 PM, soft_props [via Databinder] <[hidden email]> wrote:
I like where this is going. This sounds like a better solution than my maybe failed attempt and at around filter unfiltered.response.PassAndThen (in filter module).

Look forward to seeing what you've been up to Dustin!


View message @ http://databinder.3617998.n2.nabble.com/Filters-not-what-you-re-thinking-tp5855561p5880044.html

To start a new topic under Unfiltered, email [hidden email]
To unsubscribe from Unfiltered, click here.