For authentication for remote service calls...screen name or userid, huh??

[David W.，修改在9 年前。]

I've just spend considerable amount of time researching, installing, configuring, and re-configuring our portal configuration for our application, and, now I need to write an external interface to make remote calls for creating sites.

I just read in the Service Security Layer section of the 6.2 Developers Guide this highlighted sentence:

In order for authentication to work for remote service calls, the portal authentication type must be set either to screen name or user ID. Authentication using the email address authentication type is not supported for remote service calls.

What? Huh? So, I can't write external service calls because there's no authentication available if you're using email address? Doesn't every system (except for AOL) use email address for authentication in the year 2015? Maybe I'm misinterpreting this...sorry for being a little raw, but, this makes absolutely no sense to me.

Am I misinterpreting this? Can someone shed light on this for me, please?

Thank you,
David

[Ravi Kumar Gupta，修改在9 年前。]

..implementing a custom portlet which takes email id and password for authentication and in the back.. it actually uses exactly what liferay does for authentication using screenname or id. If this is done, I believe your service calls will be authenticated..

Well.. just a rough idea..

[David H Nebinger，修改在9 年前。]

Won't work, Ravi. Auth for the SB remote services is handled by the portal, not a custom portlet.

[Ravi Kumar Gupta，修改在9 年前。]

True David, that won't work.

What I thought was, LR authenticates using email (known to all users), in this case remote services won't work. If users can login from web services using screen name or user id. Let them login and Let LR interface be same using a custom portlet.

Well.. now when i read again.. i guess this is not what David W. is looking for.

[David H Nebinger，修改在9 年前。]

If I had to guess, David, my guess is that it has something to do with the encoding of '@' (if it really is not supported). That doesn't make a whole lot of sense (as it is easy to encode that for transfer), but why else would you allow screen name but not email address?

[David W.，修改在9 年前。]

Thanks for the responses. My requirement is to create sites externally (through an external Java program), and, this is key to the integration with Liferay.

Not allowing us to use email address as the configuration for the portal seems silly to me. And, a tremendous limiting usability issue.

I guess you could configure to use screen name, and instruct your user's to enter the email address here, but, the posts I've seen haven't indicated this works either. Guess I'll have to try it, but, I'm thinking David H. is correct about something with the "@" character. Surprised this isn't a bigger deal for some. Screen names are such a PIA, I hate when sites use them, as you can NEVER remember your screen name for the hundreds of sites you have a login to, but, I can remember my email address.

Anyway, if anyone has tried using screen name configuration and had email addresses entered here, any info there greatly appreciated. I've tried some of the publicly posted webservice examples on remote connections and they are failing with "authenticated access required" after calling companyService.getCompanyByVirtualHost() methods. I suspect it's because the portal is using email address authentication.

Thanks!
David

[David W.，修改在9 年前。]

Well, just as suspected, email address validator rejects @ sign, and, after reading many posts, I've yet to hear that using the @ (as well as other special characters that are typically used in emails, i.e. period, underscore, etc) will work for both online use and api usage.

It seems that if Liferay wants to limit the external API usage, they should just force all external API usage to use the numeric userId, as, most external api usage will be by one user (i.e. an admin level user), and, this will not change. Or, simply do a better job at parsing during the login process. Please.

Sorry to vent, but, I must have read through over 100 posts just today on developers frustrated with this type of limitation, trying to work around it. Discouraging stuff, reconsidering using LRP. Again, who uses "screen names" for their sites?

And, what's the purpose of all that wonderful JSON/SOAP/Rest api work if it eliminates the primary way users prefer to setup their userid in today's portals/web sites?

[David H Nebinger，修改在9 年前。]

I wonder if it wouldn't be possible to create a servlet filter that gets invoked before the web service itself gets control. Takes the incoming email/password and does a preliminary validation and, if passed, replaces the email address with the looked up screen name.

By injecting a filter you would get to keep using email address yet coerce it into the form that would be expected by the web service handler... I mean, it is all based on basic auth so it should be a header manipulation...

[David W.，修改在9 年前。]

That sounds like an excellent idea David, I'm guessing the filter could be pretty simple to look up the screen name. Haven't written any servlet filters, but, this sounds feasible.

And, actually, I'd always be using the same userid to do this work, could put in some simple validation, check where the request comes from (will always come from same location on my source server), then do the substitution.

Thanks for the suggestion, I'll give it a try!

Also, just curious, I've just re-entered the LRP world after a few years break, assuming the Community Feature area is where to suggest external interfaces be changed to support portal email address configuration, maybe it's already there.

David

[Jesse Rao，修改在8 年前。]

Hi guys,

Sorry for the confusion. Authentication by email address for Liferay web service invocations *is* supported. The documentation was wrong. I've created a ticket (https://issues.liferay.com/browse/LRDOCS-1779) and submitted a fix: https://github.com/sez11a/liferay-docs/pull/1314

Two additional relevant points:

1. If the `@` symbol is used in a URL path, it must be URL encoded. E.g., [e-mail] becomes test%40liferay.com.

2. For security reasons, Liferay no longer allows authentication by supplying credentials in a URL when the request comes from a browser. (This worked in previous versions of Liferay.) Instead, the invoking user must be signed in to Liferay and an authentication token (p_auth) must accompany the request. E.g., consider the getUserByEmailAddress(long companyId, String emailAddress) method.

The following does not work:

http://test%40liferay.com:test@localhost:8080/api/jsonws/user/get-user-by-email-address/company-id/20154/email-address/test%40liferay.com

The following would work if the p_auth parameter was valid:

http://localhost:8080/api/jsonws/user/get-user-by-email-address/company-id/20154/email-address/test%40liferay.com?p_auth=dBf8pxjc

Credentials can still be used to authenticate Liferay web service invocations that come from non-browser clients, e.g. curl.

For example:

curl http://localhost:8080/api/jsonws/user/get-user-by-email-address \
-u [e-mail]:test \
-d companyId=20154 \
-d emailAddress='[e-mail]'

Thanks for bringing the documentation issue to our attention. Hope this helps.