Open ckarle opened 11 years ago
Play is great for development because it has a very good productivity: hot reloading, compiled templates, ... But, for business world, it lacks a legacy deployment target: common but heavy application servers.
So Play2War has been designed to package Play applications into standard JavaEE WAR files, for production environments. You shouldn't use it in development (or just for testing purpose). More, you shouldn't use any JavaEE APIs (servlet, ...) that will slow down your development tasks (redeployment in Tomcat is very bad for example, due to class loading memory leaks in Play dependencies).
So if you need authentification in Play, use the standard way: http://www.playframework.com/documentation/2.1.0/JavaGuide4
Those are great points, and we frequently run straight out of Play as we develop because of those hot compile/reload features. However, the choice of Tomcat and Spring security is already made by the team that will receive our work, and whatever my team delivers must play nicely there.
Our main need is to capture the id of the authenticated user (just id String, not any more complex object) and pass it along to other systems -- REST services that our Play/Play2War app is calling.
Is it a bad idea for us to explore the possibility of creating our own custom build of Play2War that propagates that ID string -- for example, is it something you've already looked at and found impossible or problematic? I'm also assuming when I ask this that the license and spirit of the project promote such a thing (if not we'd never pursue it).
Thanks for your responses and for this project -- it's working brilliantly and could be everything we need for other projects...
the choice of Tomcat and Spring security is already made
Grails may fit exactly your needs :)
Anyway, how this could be solved with Play or/and Play2War ?
It is already possible to integrate Spring Security with Play2 applications. See this sample: https://github.com/JuanManuelCarballo/play-spring-security This is interesting, because it works with Play deployment model, so it will work with WAR packaging too.
You could also integrate Spring security thanks to a servlet filter. But then, what do you expect ? HttpServletRequest#getRemoteUser()
or HttpServletRequest#getUserPrincipal()#getName()
filled in this your username ?
Hi Damien
what do you expect ? HttpServletRequest#getRemoteUser() or HttpServletRequest#getUserPrincipal()#getName() filled in this your username ?
Yes, that is what I'm after -- request().username() returns the value from getRemoteUser... I'm very new to Play, so if I'm missing something please be blunt :-) I was assuming I'd need to grab that value and push it into place in play2war code (right?)
Is it a bad idea for us to explore the possibility of creating our own custom build of Play2War that propagates that ID string
It's a good idea to find the best way to propagate that ID string (I don't have the test case), and then do a pull-request instead of building your own build of Play2War.
@ckarle Any news ?
Has any progress been made on this? I'm hitting the exact same issue:
request().username() == null;
Running servlet v2.5, Play 2.2.4, and play2war 1.2.
My playframework 2.1.1 Java application is successfully deployed to Tomcat 7 using play2war 0.9. Our next step is securing the app, at first using basic authentication but we'll need to support any scheme Tomcat supports (say possibly leveraging Spring security). I hoped the play2war would push the username into request().username(), but it's coming up null -- is there configuration detail we're missing? Browsing the play2war source for RequestHandler.scala looks like username isn't handled... maybe some different approach?