Play 2.4 Filter vs Action Composition

[Tianhao Li]

Had a discussion with the team about using Filter vs Action Composition when doing authentication/authorisation in Play 2.4. (Our current code are using the way of action composition)

https://www.playframework.com/documentation/2.4.x/ScalaHttpFilters

https://www.playframework.com/documentation/2.4.x/ScalaActionsComposition

Although both Filter (using some regular expression or similar whitelist to bypass the requests don't need auth stuff. If you used Spring security before, you can imagine the code like pattern /* or similar) and Action Composition achieve the same requirements, but I still prefer the Action composition way of doing that. 

They argue that using Action Composition need to put your customised Action instead of Play Action, and new developer who creates a new endpoint may make the mistake so will be having security hole. But my point is we can prevent this happen by doing some functional tests and automation tests.

Given this doc, https://www.playframework.com/documentation/2.4.x/ScalaHttpFilters, Play clearly recommended using action composition to do that stuff without say why (only saying if you don't want to do for every request).

Just want to know how you guys opinion on that and why?

Thanks

[Greg Methvin]

Hi Tianhao,

Many applications have significant parts that don't require auth. Even for a controller for a specific domain (e.g. UserController) you might want some things (e.g. a user's public profile) to be public and others to require authentication.

Using a special authenticated action builder for the authenticated routes makes it easy to specify and see in the code if auth is required. Using a filter approach, I'm not sure how you would handle that cleanly. If you use patterns to match the specific routes, now you need to check two route expressions every time you add a new action.

If you're going to need a bunch of regexes to check authentication, why not just use Play's router and keep all the logic in one place?

[Tianhao Li]

Yeah I totally agree with you and some of them is my point. Also I have already implemented that way.

However, in our application you need to login first and then use the services. So they said can simply maintain a small whitelist which doesn't need to be authenticated. In addition they keep arguing that when someone writes a new endpoint may easily forget to put customised action and having security hole.

What I really hope is we could have more types of authentication/authorisation for the requirements, so action composition is clearly the winner. But for now, only one.

[Greg Methvin]

Action composition is really helpful is when you want to do different actions depending on whether the user is logged in, or has certain permissions. I'm not sure how you would handle that with a filters approach.

I'm not saying using filters for auth can't work, but as you have more special cases you start working against the framework.

--
You received this message because you are subscribed to a topic in the Google Groups "play-framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/play-framework/_2pbzIayOFs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/2ab4a52f-ea8e-4f05-9f15-b09dde8714a6%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Christian Schmitt]

What we did is, that we combined a Custom Action and Filters.

So if the action needs auth we write:

AuthAction { implicit r =>

}

If the action needs auth and a special permission:

(AuthAction andThen has.perms("open_admin")).async { implicit r =>

}

Filter combined with action. ;)

[Greg Methvin]

How is that a "filter combined with action"? It looks like just action composition to me.

To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/7929deb5-b80b-4524-bbe3-e72bf768a554%40googlegroups.com.