Blogs
Lauri Hiltunen
2 Minute Read
Liferay offers extensive set of features regarding user accounts and signing in to your portal out of the box. Many of the features are made configurable through portal properties, enabling the developer to concentrate more on the core features clients want from their portals.
These options include, among others, the “remember me” feature, login by openid and whether you want your users to authenticate using their email address or screen name. And this is just the tip of the iceberg, there are numerous possibilities to configure the login process.
Yet sometimes what Liferay offers as a default might not be enough. Luckily there’s more. In a blog post from the past, Mika Koivisto describes how to override and add struts actions from hook plugins. This feature is really neat and makes it possible to do some Liferay Magic™.
Earlier on I mentioned that it was possible to choose the authentication method used by your portal by changing a property. What if you wanted to enable both logging in by screen name and by email address? You could create two different pages with login portlet and, as the authentication method is configurable also on portlet-by-portlet basis, change the method used by the other portlet. But what if I told you that you could use Struts portlet actions to enable both, or even create some custom authentication methods?
We’ll achieve this by creating new hook, called login-hook. Within the hook, we’ll override the default struts action for login. In our own custom action we can wrap the original ActionRequest with a custom LoginParamWrapper and forward the processing of the login to the original action given as a parameter to your custom action.
Override the default login action with a custom class which extends BaseStrutsPortletAction
The magic happens in the LoginParamWrapper, where we override the getParameter method. When ever a request parameter is queried, we’ll check if the login name was requested. If that is the case and user has supplied us with an email address, we’ll secretly fetch the screen name of the user and, if found, return it instead. And voilà, user has logged in with their email even though it was login by screen name that was enabled.
LoginParameterWrapper class extends ActionRequestWrapper, the derived class applies a bit of magic when the login parameter is queried.
Of course, now we’ve left with some minor hooking of the login page itself to reflect on this change and tell the user they can login by screen name or email, which ever they prefer. And to make the feature complete, don’t forget to override the forgot password action to create similar feature when users have forgotten their passwords.
Override login.jsp to reflect the changes made.
Some things to note, however. You’re extending the BaseStrutsPortletAction class and not the LoginAction. This is why you need to override the render and serveResource methods as well. It is a bit of a nuisance, but you can just forward the handling to the original action which is included as a parameter on your methods.
And to tell you that this is not just a show-off, this is a pattern we’ve successfully used in production environments. We at Ambientia have done some magic similar to this for instance in The Finnish Business School Graduates Liferay Portal to enable customised methods of logging in.
So there you have it, overriding Liferay's default struts actions is a powerful tool. Use it with care.
Related Assets...
No Results Found
More Blog Entries...
Tibor Lipusz
October 27, 2025
Community
Company
Feedback