SecueSocial for PlayFramework >2.3 with UserPasswordProvider and REST (client on another domain)

[michael...@googlemail.com]

Hi,

After lots of research i still wonder how to use SecureSocial with the UsernamePasswordProvider via REST. 

I need to get an auth token from SecureSocial after login so that i can put this token in the X-Auth-Header for future requests to secured actions.

Following this answer I'm now able to login with curl but the answer from the server is empty (instead of the expected access token).

I'm using SecureSocial 3.0-M4 and PlayFramework 2.4 with Java. Unfortunately the docs for SecureSocial 3.0-M4 are not up to date, so I have no idea if this version supports such a scenario.

Is there a possibility to get SecureSocial working with X-Auth-Tokens? Does SecureSocial provide such functionality?

Thanks in advance!

[Jorge Aliss]

That should work. Can you provide the output from curl? What status code are you getting? 

[michael...@googlemail.com]

The CURL output is:

$ curl -v --data "username=xxxx...@googlemail.com&password=test123" http://localhost:9000/authenticate/userpass

* STATE: INIT => CONNECT handle 0x600057870; line 1397 (connection #-5000)

* Added connection 0. The cache now contains 1 members

*   Trying ::1...

* TCP_NODELAY set

* STATE: CONNECT => WAITCONNECT handle 0x600057870; line 1450 (connection #0)

* Connected to localhost (::1) port 9000 (#0)

* STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x600057870; line 1557 (connection #0)

* Marked for [keep alive]: HTTP default

* STATE: SENDPROTOCONNECT => DO handle 0x600057870; line 1575 (connection #0)

> POST /authenticate/userpass HTTP/1.1

> Host: localhost:9000

> User-Agent: curl/7.50.3

> Accept: */*

> Content-Length: 55

> Content-Type: application/x-www-form-urlencoded

>

* upload completely sent off: 55 out of 55 bytes

* STATE: DO => DO_DONE handle 0x600057870; line 1654 (connection #0)

* STATE: DO_DONE => WAITPERFORM handle 0x600057870; line 1781 (connection #0)

* STATE: WAITPERFORM => PERFORM handle 0x600057870; line 1791 (connection #0)

* HTTP 1.1 or later with persistent connection, pipelining supported

< HTTP/1.1 303 See Other

< Location: /loggedin

< Set-Cookie: PLAY_SESSION=; Max-Age=0; Expires=Sun, 29 Jan 2017 12:01:21 GMT; Path=/; HTTPOnly

< Set-Cookie: authid=4062ccb849b05263d6a8a5c35212336e15918bb5976a97e05118a80d73ed77f6951df7fd2fe9654f26365904c9473e10525af5004c1e35f932bab545bd7f3b093897e7ec2e651f023dd9324ec0ea306fa1f8b386f7ea497635a54d1ea83c5947d8acd610952a738e00f2e69a1ff323e49dc7faec319275971b7928cbd9af0fc2; Path=/

< Date: Sun, 29 Jan 2017 12:01:21 GMT

< Content-Length: 0

<

* STATE: PERFORM => DONE handle 0x600057870; line 1955 (connection #0)

* multi_done

* Curl_http_done: called premature == 0

* Connection #0 to host localhost left intact

* Expire cleared

A Cookie is set with the authentication information, is that what you meant by providing an auth token? I hoped for a non-cookie based solution. I expected a return value like:

{
"email": “so...@email.com”,
"info": {
    "accessToken": “an_access_token”,
    "expiresIn": a_number_with_expiration_in_seconds
 }
}

[Jorge Aliss]

You need to POST to auth/api/authenticate/userpass.

On Sunday, January 29, 2017 at 9:09:11 AM UTC-3, michael...@googlemail.com wrote:

The CURL output is:

$ curl -v --data "username=xxxxxxxx@googlemail.com&password=test123" http://localhost:9000/authenticate/userpass

[michael...@googlemail.com]

That works perfectly.

Thank you for the quick responses!

Am Montag, 30. Januar 2017 16:42:02 UTC+1 schrieb Jorge Aliss:

You need to POST to auth/api/authenticate/userpass.

On Sunday, January 29, 2017 at 9:09:11 AM UTC-3, michael...@googlemail.com wrote:

The CURL output is:

$ curl -v --data "username=xxxx...@googlemail.com&password=test123" http://localhost:9000/authenticate/userpass