Here are some notes for playing around with login-with locally.
login-with
assumes that it will be accessed over https. Since we are just playing around with it, we want to run it locally. We don't want to mess with setting up nginx as a reverse proxy.
We can use socat
as a quick reverse proxy.
First, we need to create a certificate socat can use. (Ideally, socat would create a certificate for us every time it runs, but it doesn't look like that functionality exists...) openssl
is used to create the ceritificate:
$ openssl req -new -x509 -days 365 -nodes -out cert.pem -keyout cert.key
This creates the files cert.pem
and cert.key
.
You can pass these files to socat
:
socat -vv openssl-listen:3433,reuseaddr,fork tcp4:localhost:3000
This sets up socat
so it listens on port 3433 for SSL connections, unwraps the SSL, and forwards the connection to localhost
port 3000.
Now, we need to make sure that login-with
is listening on port 3000. Run it with docker
:
$ docker run -i -t --rm -p 3000:3000 \
-e NODE_ENV=production \
-e LW_SUBDOMAIN=192.168.56.22:3433 \
-e LW_SESSION_SECRET=foobar \
-e LW_JWT_SECRET=foobarbaz \
-e LW_TWITTER_CONSUMERKEY=lTxxxxxxxxxxxxxxxxxxxUhC \
-e LW_TWITTER_CONSUMERSECRET=q0dXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXWK \
lipp/login-with
The above assumes that we are actually running on a machine with IP address 192.168.56.22
. It is also making docker
expose port 3000 on the local machine. (We saw this earlier in the socat
command.)
The LW_TWITTER_* values come from creating an application on Twitter. You need to go to Twitter's developer console to create these. LW_SUBDOMAIN is normally the subdomain where login-with
is running from.
Now that socat
and login-with
are both running, we can try accessing login-with
in the browser:
$ firefox 'http://192.168.56.22:3000/twitter?success=http://192.168.56.22:5000&failure=http://192.168.56.22:5000'
Here is the application flow:
-
Connect to
login-with
. -
login-with
redirects to the Twitter authentication API. Something like the following:https://api.twitter.com/oauth/authenticate?oauth_token=_aZgXXXXXXXXXXXXXXXXXXXXXE
. -
If you authorize the application, you get redirected back to
login-with
(well, actuallysocat
).The request looks something like the following:
GET /twitter/callback?oauth_token=P6XXXXXXXXXXXXXXXXXXXXXXX78U&oauth_verifier=sdwqxxxxxxxxxxxxxxxxxxxxxxxxxPi HTTP/1.1 Host: 192.168.56.22:3433 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Cookie: connect.sid=s%3AxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxtB9I Upgrade-Insecure-Requests: 1
-
login-with
then redirects you to the URL you specified in thesuccess
query parameter. The repsonse looks like this:HTTP/1.1 302 Found Set-Cookie: jwt=eyJ...Fso; Max-Age=864000; Domain=.168.56.22:3433; Path=/; Expires=Sun, 22 Apr 2018 07:09:27 GMT; HttpOnly; Secure Set-Cookie: profile=%7B%22username%22%3A%22mytwitteruser%22%2C%22provider%22%3A%22twitter%22%2C%22photo%22%3A%22https%3A%2F%2Fabs.twimg.com%2Fsticky%2Fdefault_profile_images%2Fdefault_profile_normal.png%22%2C%22name%22%3A%22mytwitteruser%22%7D; Max-Age=864000; Domain=.168.56.22:3433; Path=/; Expires=Sun, 22 Apr 2018 07:09:27 GMT; Secure Location: http://192.168.56.22:5000 Vary: Accept\r Content-Type: text/html; charset=utf-8\r Content-Length: 94\r Date: Thu, 12 Apr 2018 07:09:27 GMT\r Connection: keep-alive\r
You can see in this last step that login-with
adds two cookies. One is called jwt
and the other is called profile
.
The information in the jwt
cookie is as follows:
token: 314...g3
tokenSecret: gdU7...5Y
profile.username: mytwitteruser
profile.provider: twitter
profile.photo: https://pbs.twimg.com/profile_images/378811111179434342443432/8324323435r235235225dddddd_normal.png
profile.name: mytwitteruser
iat: 1523577889
This is only available over HTTPS.
The profile
cookie is JSON-encoded. It lists simple things like the username, etc. This can be accessed from JavaScript.