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
You can pass these files to
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 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
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.
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:
login-withredirects to the Twitter authentication API. Something like the following:
If you authorize the application, you get redirected back to
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-withthen redirects you to the URL you specified in the
successquery 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
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.