Lack of horizontal programming facilities

[GithubUser8080]

Greetings, i would like to ask if there is a potential support for horizontal concerns in controllers. The lack of facilities to easily register application wide functionality like Spring is making us move to other frameworks, and I would like to see if we can avoid that because play has a lot of good things.

Authentication, authorization, serialization, all of that are usually applied to the entire app and it is discouraging that we have to write the same code in every controller method.

Some examples are

• Injecting values in controllers that come from somehow converting the request. The closest to that is PathBindable but there is no injection and you have to change the dto itself rather than provide a service that does the conversion. Spring has HttpMessageConverters.
• Returning direct objects rather than serializing and returning the result every time. I would like to return a User, not a result. How that user will translate to JSON or XML or another type depending on accept header should be somewhere else in my opinion. Otherwise all my controllers have serializer.serialize(my dto, request) which means i also have to inject serializers in every controller.
• Authenticating means writing code that handles the requests and returns user info in every controller. The closest thing is an action, but then you have to write code to get the principal in the controller.
• Authorization is also hard to implement in a way that does not pollute the controllers.

This are just my own views on what i find hard to do in play, as feedback. Apologies if there are workarounds I do not know about.

[jducoeur]

While that's somewhat true (AFAIK), the usual approach is to just write higher-level controllers and methods.

For example, I pretty much never use the standard methods for defining Actions. Instead, I define my own methods for, eg, AuthenticatedAction vs UnauthenticatedAction vs AdminAction -- stating clearly who is allowed to call what. Ditto for serialization on the outbound side. And I generally have specialized Controllers as well, bundling these specialized Actions together in ways that make sense.

IMO, that's better than having universal one-size-fits-all plugins -- it means the call site is saying exactly what it means (which reduces the risk of security-compromising oversights). But in practice it takes no more call-site code than using such plugins does; if anything, thoughtful factoring usually results in more-concise and readable controller code.

[GithubUser8080]

Could you please provide an example for the first part?

E.g i would like to receive a User in my controller method, and have this be extracted by the request body, depending on the request content-type.

[jducoeur]

Currently away from keyboard, so I can't provide a direct example, but the high concept is that you define a method that does the user authentication and takes a function parameter; your concrete endpoints call that with a function that takes the user as a parameter, and which provides the guts of the endpoint logic. (Admittedly this is easier in Scala than Java, but lambda functions are no longer unknown in Java. Basically, you're writing your own version of the standard Action, on top of the standard one.)

…

On Fri, Aug 2, 2024, 9:56 AM GithubUser8080 ***@***.***> wrote: Could you please provide an example for the first part? E.g i would like to receive a User in my controller method, and have this be injected by the request body, depending on the request content-type — Reply to this email directly, view it on GitHub <#12826 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQVNYNUC25B3UJWSSLTEULZPOFYNAVCNFSM6AAAAABL4HIEKOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMRSGQYTMMA> . You are receiving this because you commented.Message ID: <playframework/playframework/repo-discussions/12826/comments/10224160@ github.com>

[GithubUser8080]

I have done something similar, an action for authentication, but since I need the current principal in controllers, you need to put the principal into a request attribute in the action, then in every controller method you need to do something like

User user = authentication.extractUser(request)

Which means you also need to inject authentication (unless you use a static method) and the request object in every method.

Then considering you also need serialization and deserialization, every controller method ends up having code for authentication, authorization, deserialization, serialization, and various validation errors. It's not difficult, but i would say probably 60% of my controllers are repetition of horizonal concerns.

[rbueker]

I use https://github.com/pac4j/play-pac4j for Authentication and Authorization.

This makes it easy to handle these functions in the Controllers.

You can checkout either Scala or Java examples:
https://github.com/pac4j/play-pac4j-scala-demo
https://github.com/pac4j/play-pac4j-java-demo

[GithubUser8080]

We used that too but due to some compatibility issue we changed it to custom auth. Anyway, notice that you have to do

 public Result getUserProfile() {
        PlayWebContext webContext = new PlayWebContext(ctx())
        ProfileManager profileManager = new ProfileManager(webContext, playSessionStore);
        Optional profile = profileManager.getProfile();
        ....
    }

Instead of

 public Result getUserProfile(Profile profile) {
        ....
    }

When you have many endpoints, and add serialization/deserialization as a custom step, this adds up fast.