Custom Login Portlet and Phishing Protection

[William Gosse, modificado 7 Anos atrás.]

Has any one figure out a way to develop a custom login portlet using Liferay APIs where the session.enable.phishing.protection=true ?

It seem that the only way to make a custom login portlet work is by setting session.enable.phishing.protection=false

Is the not possible?

Is the only alternative for having session.enable.phishing.protection=true is to use the Liferay's OOTB login portlet?

[David H Nebinger, modificado 7 Anos atrás.]

Custom login portlets have been challenging for as long as I can remember. For some reason Liferay prefers to hide/protect many of the login mechanisms.

That said, what kind of issues are you seeing trying to access your own portlet when phishing protection is enabled?







Come meet me at the LSNA!

[William Gosse, modificado 7 Anos atrás.]

Again the main issue is using the default session.enable.phishing.protection=true. For some reason the the session regeneration after authentication fails to happen correctly.

I've seen several post on this and the answer is to set session.enable.phishing.protection=false, which does not jive with our corporate security rules. When we set session.enable.phishing.protection=false, in violation of the rules, our custom portlet does works fine because we are maintaining the same session.

Don't get me wrong I had argued for us to use the out-of-the-box login portlet but was shot down by other team members. Now that decision is coming back to haunt us.

[David H Nebinger, modificado 7 Anos atrás.]

But how are you getting there?

I mean, reviewing the code for SP14 I can see that I'd get there if I invoked LoginUtil.login() method or if the AutoLoginFilter invokes LoginUtil.renewSession().

But all of these methods occur even if you use the OOTB portlet since both methods are invoked there anyway.

And if you check out the LoginUtil.renewSession() method, you can see where it invalidates the current session and then creates a new session (it will also save listed attributes across session recreation).

So I'm left with the following questions:

• How is the session not regenerating properly?
• How are you invalidating the session?
• What does "session regeneration after authentication fails to happen correctly" mean?

You can search the source and find every example of invalidate() being used (ignoring caching, finders, non-relevant matches) and see where session invalidation and creation is a fairly clean process, so I'm not sure what might be going on to fail how your login portlet handles login?

Setting the value to false, well that's easy. When phishing protection is disabled the session is not invalidated at key points thus retaining session vars, but when true it's whacking the session at key points to prevent phishing for data in a polluted session.

Eh, enough rambling. Can you share more details William? That way perhaps I can help you find a suitable solution?





Come meet me at the LSNA!

[William Gosse, modificado 7 Anos atrás.]

So this having to set session.enable.phishing.protection=false when using a custom login porlet has been in a lot of forum posts over the past couple of years now. I haven't seen anything that addresses this issue so far in my research. I've even approached Liferay support directly via my enterprise support and didn't really get any kind of satisfactory answer. It seems as soon as you mention custom anything your kind on your own. That said this what we are basically doing with the Liferay API to login:

MethodKey key = new MethodKey(
ClassResolverUtil .resolveByPortalClassLoader("com.liferay.portlet.login.util.LoginUtil"),
"login",
HttpServletRequest.class, HttpServletResponse.class,
String.class, String.class, boolean.class, String.class);

PortalClassInvoker.invoke(false, key,
new Object[] {getHttpServletRequest(actionRequest),
getHttpServletResponse(actionResponse),
authenticationInfo.getUserName(),
authenticationInfo.getPassword(),
Boolean.FALSE, CompanyConstants.AUTH_TYPE_EA });

If no exception occurs we do a few more business specific items then redirect to the appropriate landing page:
actionResponse.sendRedirect(FmcnaPortalConstants.PATIENT_PRIVATE_URL_CONTEXT + fmcnaViewResolverConstants.DASHBOARD);

However again if session.enable.phishing.protection=true is set the redirect fails to occur because there appears to be no session anymore.

I should also add this custom login portlet is written using the Spring MVC framework.

[David H Nebinger, modificado 7 Anos atrás.]

No, Liferay support will not help with "custom" anything. They're not equipped to be a consulting service. With so many clients and developers they would be quickly overcome if they allowed it.

Reflection is the standard method for invoking the LoginUtil class, so that's spot on. However, it's inside the LoginUtil implementation where the session is reset. The session coming back from login is the newly created and fresh session to be used for the login session.

You can actually see that there is a session using getHttpServletRequest(actionRequest).getSession(false) to pull the session.

Do you have something in the session before the call to login()? When the http session is reset, it will discard all portlet sessions, etc. along with it. If your code is dependent upon session objects, they will certainly be gone.

Spring MVC is not a problem for your custom portlet, that shouldn't have an impact on session usage.







Come meet me at the LSNA!

[William Gosse, modificado 7 Anos atrás.]

Added HttpSession session = getHttpServletRequest(actionRequest).getSession(false); right after invoke() is called and then ran in debug mode. I appear to have a valid method after performing the login but it seems to be getting lost after I do the redirect.

[David H Nebinger, modificado 7 Anos atrás.]

So one option you might consider, list all of the key/value pairs that you have in the session and try after the redirect (when you determine you have a failure).

There's a portal-ext.properties setting you can use, session.phishing.protected.attributes, where you can enter a comma-separated list of session keys that should be protected across the session renewal.

If you can find the one that is getting dropped and put it into this list, you can save it across renews and hopefully prevent the erroneous results you're currently seeing. Of course it might be tempting to put all values you find in this property, but that kind of works against the whole phishing protection mechanism.






Come meet me at the LSNA!

[William Gosse, modificado 7 Anos atrás.]

yep I was looking at that yesterday.