Forums

Home » Liferay Portal » English » 3. Development

Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
Arthur Clement
Authenticator interface problem
February 19, 2008 6:57 AM
Answer

Arthur Clement

Rank: Junior Member

Posts: 34

Join Date: April 17, 2005

Recent Posts

The Authenticator interface is a great way to plugin our own authentications mechanism in a very clean way.
There is one big problem : we do not have access to the request (hence neither the session).
Other people have had the same issue as this thread shows :
http://www.liferay.com/web/guest/community/forums/message_boards/message/117471

But no answer has been given until now.

While I understand why the methods in Authenticator should only return FAILURE or SUCCESS, when you are trying to authenticate on another database (or whatever referential is used) you sometimes receive information that doesn't fit into liferay's user.
You could create another object to store the received info in the db but this isn't always what is needed. In my case, I just need to put the received info in session so my portlets can then access it...

Of course I have already checked the code to see what is done. The LoginAction class calls a service method on UserService that has the following signature :
1
2public int authenticateByEmailAddress(long companyId,
3        java.lang.String emailAddress, java.lang.String password,
4        java.util.Map headerMap, java.util.Map parameterMap)


I understand why someone would be reluctant to pass the request to a service method. Maybe we could pass another custom map that loginAction would then set in the session...

It's just an idea. But the need for this is real.

Arthur
Ray Augé
RE: Authenticator interface problem
February 19, 2008 8:46 AM
Answer

Ray Augé

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1195

Join Date: February 7, 2005

Recent Posts

You can achieve this pretty easily by editting the jsp of the Login/Sign In portlet.

Here is a small patch you could use:

 1Index: html/portlet/login/view.jsp
 2===================================================================
 3--- html/portlet/login/view.jsp (revision 13749)
 4+++ html/portlet/login/view.jsp (working copy)
 5@@ -49,11 +49,13 @@
 6                String login = LoginAction.getLogin(request, "login", company);
 7                String password = StringPool.BLANK;
 8                boolean rememberMe = ParamUtil.getBoolean(request, "rememberMe");
 9+               long groupId = BeanParamUtil.getLong(layout, request, "groupId");
10                %>
11
12                <form action="<portlet:actionURL secure="<%= secure %>"><portlet:param name="struts_action" value="/login/view" /><portlet:param name="<%= Constants.CMD %>" value="<%= Constants.UPDATE %>" /></portlet:actionURL>" method="post" name="<portlet:namespace />fm">
13                <input name="save_last_path" type="hidden" value="0" />
14                <input name="<portlet:namespace />rememberMe" type="hidden" value="<%= rememberMe %>" />
15+               <input name="<portlet:namespace />groupId" type="hidden" value="<%= groupId %>" />
16
17                <liferay-ui:error exception="<%= AuthException.class %>" message="authentication-failed" />
18                <liferay-ui:error exception="<%= CookieNotSupportedException.class %>" message="authentication-failed-please-enable-browser-cookies" />


Notice all I did was add a reference to the current groupId obtained from the layout bean. If the bean doesn't exist (which is impossible with a portlet) you'll get 0, otherwise you'll have the "groupId" accessible from

1java.util.Map parameterMap


Cheers!

PS: Add as many params as you might need in the authenticator. Also, note that this is just a change to the Sign In Portlet.. and not the global sign-in form (/c/portal/login), though that one could definitely use the same trick to inject the "groupId" into the parameterMap.

(I'll backref the other thread to this one.)

Hope that helps!
Arthur Clement
RE: Authenticator interface problem
February 22, 2008 1:46 AM
Answer

Arthur Clement

Rank: Junior Member

Posts: 34

Join Date: April 17, 2005

Recent Posts

Ok, your solution is pretty good when you want to use a parameter that is already present in liferay. Thanks for this.

But this doesn't solve my problem. Maybe my description wasn't clear so I'll try again :
To be a bit more precise, I'll use a concrete example.

I hooked in my own Authenticator interface implementation that calls a webservice to authenticate the user.
In case of success, several params are sent back by the webservice that I would like to put in session. One of these param is the 'institution code' of the user.
What I was trying to do is pass this institution code from my custom auth class to a hooked in loginPostAction where I could put it in session. I tried to do this with a threadLocal, but I have faced undetermined behavior and I think this is due to a res.sendRedirect at the end of the login, hence the thread in loginPostAction might not always be the same than the one of the login.

Now I only see 2 ways of getting my institution in my loginPostAction : either store it in db during authentication phase, or call the WS again in LoginPostAction.
Neither of the solutions look neat to me, but I guess I'll go with the first one because calling twice a webservice would cost too much in terms of performance.

Arthur CLEMENT
Erik R Hermansen
RE: Authenticator interface problem
June 26, 2008 2:13 PM
Answer

Erik R Hermansen

Rank: Junior Member

Posts: 60

Join Date: May 15, 2008

Recent Posts

I think it is probably better for me to resurrect this old thread than ask in a fresh post. Arthur's question and the distinction made here is the same as mine. My situation is, well... same thing he said:
aclement aclement:

I hooked in my own Authenticator interface implementation that calls a webservice to authenticate the user.
In case of success, several params are sent back by the webservice that I would like to put in session. One of these param is the 'institution code' of the user.


Like Arthur, I need to store a piece of information returned from a webservice during authentication, and ideally, store that piece information with Liferay's session. Is there a neat way to do this?

-Erik
Erik R Hermansen
RE: Authenticator interface problem
December 1, 2008 6:58 PM
Answer

Erik R Hermansen

Rank: Junior Member

Posts: 60

Join Date: May 15, 2008

Recent Posts

Would you believe I'm still working on this problem a half-year later? Well, I did do one or two other things in that time. emoticon

So I implemented Ray's solution. I learned that I can create new variables and pass them to the custom Authenticator-derived class. For some reason, I thought I'd be confined to using preexisting variables defined someplace. The trouble I have is getting a value back from the custom Authenticator. I was naive enough to try this:

 1
 2public class MyCustomAuthenticator implements Authenticator {
 3   
 4    public int authenticateByEmailAddress(
 5            long companyId, String emailAddress, String password,
 6            Map<String, String[]> headerMap, Map<String, String[]> parameterMap)
 7            throws AuthException {
 8        parameterMap.put( "MySpecialVariable", new String[]{"12345"} );
 9        return SUCCESS;
10    }
11
12        /* ...The other two authenticateBy*() methods here... */
13}


...but this doesn't get written back to the request or anywhere. From walking through code in LoginAction.login() and callees, I think headerMap and parameterMap are just intended to be read-only params to the authenticate methods. So I can pass anything I want to authenticateBy*() methods. I just don't know how to return anything back.

Well, I do have two junky solutions:
* Use expando APIs to store the value in my custom authenticator. But the persistence layer really shouldn't be involved for this.
* Add code to LoginAction.java to store modified parameterMap values in the portlet session if their prefixes match the known session shared variables prefixes in portal-ext.properties. But I like to avoid changing the Liferay wars to avoid upgrading problems.

There is hopefully some simpler way to accomplish this.

-Erik
Erik R Hermansen
RE: Authenticator interface problem
December 8, 2008 11:31 AM
Answer

Erik R Hermansen

Rank: Junior Member

Posts: 60

Join Date: May 15, 2008

Recent Posts

One more junky solution, the one I ended up using for now...

* Pick a member of the User object that isn't being used by my website and use it to pass back information. In my case, candidates were the open ID and welcome message fields, since my site uses neither. So I kludged this into my authenticator class:

1
2User user = UserLocalServiceUtil.getUserById(userId);
3user.setOpenId(valueIWantToPassBackToJsp);


I am hoping that my primitive solutions will be so embarrassingly shoddy, that someone will feel compelled to scream the Right Way to do it into my ear. Other than that, I am documenting my painful thought process in case my boss wants to know how I ended up slapping this junk code together.

-Erik
Andrew Jardine
RE: Authenticator interface problem
November 1, 2013 2:12 PM
Answer

Andrew Jardine

Community Moderator

Rank: Liferay Legend

Posts: 1080

Join Date: December 22, 2010

Recent Posts

Worth noting -- if you want to use the expando attribute for this (during a custom authenticator) then you need to make sure that the UPDATE permission on the field is checked for a guest. Technically, at this stage the user has not actually logged in yet and is still considered a guest. Perhaps not the most elegant option if you are working with something secret but there aren't many other choices.

Another option I have used is to create a service builder project and then set a deployment context dependency for it. You can then write a record while in the authenticator, but again, not necessarily the best option if you are trying to avoid persistence layer access. In my case I also used it to record invalid logins for reporting so it served a dual purpose.