留言板

LoginUtil.login and PortalClassInvoker - or other option?

Ivan Pointer,修改在12 年前。

LoginUtil.login and PortalClassInvoker - or other option?

New Member 帖子: 9 加入日期: 12-2-23 最近的帖子
Hello,

I am working on an enterprise project (We are still in early contract phase, will be getting the EE support when contracting is final) and have a hard requirement that I be able to log into the portal from within our portlet. I have attempted calling LoginUtil.login directly but as many have - I have found that that doesn't work directly.

Background: We have already built a full system for the Oregon DPSST which allows firefighters throughout the state to apply for their fire certifications through the portlet. The portlet is originally a WebSphere Portal portlet and we are being contracted to convert the system to Liferay (WebSphere is so expensive...)

As a result of the nature of the system, the portlet is deeply tied to the authentication system of it's host portal.

Down to the specific problem:

I am trying to authenticate the user using the PortalClassInvoker to call LoginUtil.login. When the code is executed, nothing happens, no errors, no messages, no login: the page refreshes with no change. The code that I am using is as simple as two lines (minus gathering the information such as user name (email) and password):


MethodKey key = new MethodKey(
  "com.liferay.portlet.login.util.LoginUtil",
  "login",
  HttpServletRequest.class,
  HttpServletResponse.class,
  String.class,
  String.class,
  boolean.class,
  String.class);
PortalClassInvoker.invoke(
  false,
  key,
  PortalUtil.getHttpServletRequest(request),
  PortalUtil.getHttpServletResponse(response),
  userName,
  password,
  false,
  CompanyConstants.AUTH_TYPE_EA);


Or, is there another solution that will permit me to login from the portlet without using EXT. I do not want to use EXT because it causes the portal to be much less maintainable, and as you can see from our environment, is not a good solution.

Thank you,
Ivan Pointer
Ivan Pointer,修改在12 年前。

RE: LoginUtil.login and PortalClassInvoker - or other option?

New Member 帖子: 9 加入日期: 12-2-23 最近的帖子
More information:

We are running Liferay 6.0.6 on the Tomcat bundle. I am developing in the Liferay SDK within Eclipse (With the Liferay IDE plugins installed). The portlet has been constructed by creating a new Liferay Plugin Portlet project and pulling the source from the WebSphere portlet over.
thumbnail
Srikanth Reddy Sanivarapu,修改在12 年前。

RE: LoginUtil.login and PortalClassInvoker - or other option?

Regular Member 帖子: 203 加入日期: 08-11-15 最近的帖子
Hi Ivan,

Did you find anything for this? Please update the post with your findings as it helps people like me to solve the issues quickly. Thanks.

Regards,
Srikanth
Ivan Pointer,修改在12 年前。

RE: LoginUtil.login and PortalClassInvoker - or other option?

New Member 帖子: 9 加入日期: 12-2-23 最近的帖子
Hello,

I was never able to find a solution. I like most of the rest, have simply given up.

What I am doing now is using the built in Liferay Sign in portlet. I have used a hook to override the JSP for the sign in portlet to strip certain features out.

I updated the portlet I am working on to recognize when the user is authenticated, and to show a message asking them to sign in to continue.

I do wish there was a solution that didn't require an increase in maintenance considerations. I do understand (if my assumption is correct), the decision to separate the Login API from the portlet scope as a security consideration, as that is one of the main purposes a JSR168/286 portal.
thumbnail
David H Nebinger,修改在12 年前。

RE: LoginUtil.login and PortalClassInvoker - or other option?

Liferay Legend 帖子: 14918 加入日期: 06-9-2 最近的帖子
Ivan Pointer:
I was never able to find a solution. I like most of the rest, have simply given up.


Well, you placed your own restrictions on possible solutions:

Or, is there another solution that will permit me to login from the portlet without using EXT. I do not want to use EXT because it causes the portal to be much less maintainable, and as you can see from our environment, is not a good solution.


This statement really makes no sense. There is no problem using the EXT plugin (as long as it's used correctly) and does not impact maintainability at all. And I didn't see anything in the original post which indicated it was not a good solution.

But with your restriction in place, your options are limited. It is not easy to cross the class loader boundary between web apps. That boundary is there to ensure web apps don't interfere w/ each other. Service Builder has a way of getting around the boundary, but it is still something the developer needs to be aware of.
Ivan Pointer,修改在12 年前。

RE: LoginUtil.login and PortalClassInvoker - or other option?

New Member 帖子: 9 加入日期: 12-2-23 最近的帖子
Before deciding to use an Ext plugin it's important to understand the costs of using such a powerful tool. The main one is the cost in terms of maintenance. Because Ext plugins allow using internal APIs or even overwriting files provided in the Liferay core, it's necessary to review all the changes done when updating to a new version of Liferay (even if it's a maintenance version or a service pack). Also, unlike the other types of plugins, Ext plugins require the server to be restarted after deployment, as well as requiring additional steps when deploying or redeploying to production systems.

--second paragraph of intro:
http://www.liferay.com/community/wiki/-/wiki/Main/Ext+Plugin
thumbnail
David H Nebinger,修改在12 年前。

RE: LoginUtil.login and PortalClassInvoker - or other option?

Liferay Legend 帖子: 14918 加入日期: 06-9-2 最近的帖子
Sure, I know the manual, but you also have to balance that against what you're trying to accomplish and determine if the goal outweighs the cost...

For example, you want to plug into the login() method of LoginUtil. The only clean way to do this is through an EXT plugin.

The cost of this goal is the EXT plugin. Now let's compare this w/ the hypothetical situation that the 6.2 release changes the login() method signature.

So here the comment from the manual definitely applies. Your EXT plugin would need to be updated to address the new method signature.

The reality is that represents the same cost that you would expend to fix this other broken code; if the API changed, you have to address the change regardless of where the API method call was.

I should point out that we're talking about the login() method of LoginUtil, a fairly stable method at this point. The chance of an upcoming API change here is very minor, unlike building something using the social or document library APIs (which tend to see most of the changes from release to release).

Finally, you should be aware of the history of the whole extension thing. In versions of Liferay up through version 5, Liferay had what it called an extension environment. Plugin support in the SDKs was there but a little weak, and Liferay developers in general would fall back to the extension environment. The extension environment was like the EXT plugin, but on steroids. When you built the extension environment, you were basically building a modified source version of Liferay that you'd deploy as ROOT.war.

With version 6 and onwards, the extension environment is gone. But developers, being somewhat lazy (I'm in this camp too, so I'm not throwing stones at anyone) would probably have seen the EXT plugin as a replacement for the extension environment, and would have done all of their work in there. Unfortunately the name is about the only thing shared w/ the extension environment (at least in the terms of usage), and Liferay wants to discourage the use of the EXT plugin altogether and promote the use of hooks instead.

Hence you get the blurb in the manual. It's meant to be a gentle push away from the EXT plugin and to the hook plugins. But the reality is that the EXT plugin is still the only way to do certain things within Liferay. The costs are actually insignificant when compared to being able to solve certain problems.
Ivan Pointer,修改在12 年前。

RE: LoginUtil.login and PortalClassInvoker - or other option?

New Member 帖子: 9 加入日期: 12-2-23 最近的帖子
This is much clearer than anything else I have read. Thank you very much. Is it possible to get this explanation somewhere in the documentation?
thumbnail
David H Nebinger,修改在12 年前。

RE: LoginUtil.login and PortalClassInvoker - or other option?

Liferay Legend 帖子: 14918 加入日期: 06-9-2 最近的帖子
Unfortunately not...

Basically I don't think there is one hard and fast rule to apply to the determination of when to use EXT and when not to. The EXT is definitely necessary for many situations (these I'm sure are covered elsewhere). The only real rule that should apply is that if something can be done outside of an EXT, then it should be. That said, I don't think it's necessarily a good thing to create a hook that relies upon something that you've had to do within the EXT plugin, it's okay to keep the related code together.

The EXT plugin is nothing to fear, however, and is definitely supported within Liferay. It does have some restrictions that the other plugin types do not, but they are just restrictions you need to be aware of for deployment and aren't meant to put you off of using the EXT plugin when necessary.
divya goyal,修改在7 年前。

RE: LoginUtil.login and PortalClassInvoker - or other option?

New Member 帖子: 7 加入日期: 14-11-11 最近的帖子
Hi David,

Sorry for replying on a very old post, I am trying to build the sign in portlet which is used for sign in into liferay portlet, And i am facing one issue of security.

For sign-in into Liferay portal, i need to redirect to the liferay and need to add some session variable before login into portal and then used it after login into portal. But cause of phishing protection attribute property the session is getting invalidated for protecting from phishing.

But the session.phishing.protected.attributes is not working properly and after login into portal it is giving the null values for the attributes which should have been copied over to the new session which is being created.

I am using liferay 6.2 EE edition. Please advise on this scenario.

Regards
Divya
Ivan Pointer,修改在12 年前。

RE: LoginUtil.login and PortalClassInvoker - or other option?

New Member 帖子: 9 加入日期: 12-2-23 最近的帖子
Let me agree with David,

While EXT was not a viable solution for me, it is, in my opinion, your best, maybe only, option to getting access to the login API within a portlet. Many of the other APIs can be accessed without using the EXT enviornment. (Leading me to beileve it is a security consideration). It may be a viable solution for you. Keep in mind however, the maintenance costs of using EXT. Read the wiki article I posted above to get more information about the EXT environment.

For further information, it is not our team that will be maintaining this solution, but another who is unfamiliar with this technology. Therefore, it is a goal to keep maintainability at it's highest for the sake of the other party. If your team is going to be the team supporting the portal, then the maintenance considerations wouldn't be as... bloated?... as in my situation.

Thank you David for helping clarify, and I appologize for letting a hint of irritation show through in my response. This ate many an hour of my time and left me a little sour over the subject.

P.S. My opinions are my own and are not representative of any entity I am affiliated with.
thumbnail
Rajeev K,修改在10 年前。

RE: LoginUtil.login and PortalClassInvoker - or other option?

Regular Member 帖子: 214 加入日期: 09-6-19 最近的帖子
Hi,

I want to call LoginUtil.login(...) from my custom portlet.

But seems this method cannot be used inside my code as it will not compile -- "The import com.liferay.portlet.login cannot be resolved"

What can be done if I want to call login() so that the user is logged in?
thumbnail
Anil T,修改在9 年前。

RE: LoginUtil.login and PortalClassInvoker - or other option?

Expert 帖子: 313 加入日期: 12-1-14 最近的帖子
Hi,

i have the same problem with PortalClassInvoker and am not getting any errors. I have created a portlet and using portalClassInvoker in controller for login method. Can anyone help me to find out solution with this class.

Thanks,
Anil T