2.2.1 Initial Plan

Here I need to go farther back. When you look at AoC you see that the authentication is delegated to either of the following popular services using the OAuth protocol.

Login Options for AoC

I am everything but an expert when it comes to server communication, so I did my research to look for the API specifications to understand the requests which are exchanged in the process of authentication:

• GitHub
• Google
• Twitter
• Reddit

I decided to use my GitHub account for this purpose.

At first with my very superficial understanding, I thought httr::oauth2.0_token would handle the authentication for me. But right after reading the documentation, I realized that I am missing some information (like the client id or even more importantly the client secret). Yet I did not give up. I logged in manually to AoC and was redirected (as per OAuth protocol) to a GitHub login page:

GitHub Login Page

As I knew already from the API docs, the first step was to send a GET request to https://github.com/login/oauth/authorize containing - inter alia - the client_id and a redirect_uri. GET requests mean that the query parameters are simply appended to the URL, so I could simply get the client_id from the navigation bar² and I found the relevant client_id: https://github.com/login?client_id=7bb0a7ec13388aa67963&[…]. With this piece of information and still no deep understanding of the “dance” I simply tried to set up an authentication as per the demo of httr (silently ignoring that I still had no client secret 🙈):

myapp <- oauth_app("github",
  key = "7bb0a7ec13388aa67963"
)
github_token <- oauth2.0_token(oauth_endpoints("github"), myapp)

My first enthusiasm yielded quickly to disillusion. While this approach was properly opening the login page, the redirect did not work and in the GET parameters I also saw why:

URI must match the registerd callback URL

I learned, that I can not redirect the request to my localhost, which would be needed to proceed with the next step (the API told me that I should receive a temporary code). I guess that this safety measure is a good thing such that you cannot simply redirect the process.

Anyways, my interest was sparked and I wanted at least to understand the dance. And of course I still wanted to follow this route to login to AoC. I quickly drafted a StackOverflow question asking for help for the overall goal. Here’s what I did in more detail:

First, I set quickly set up a test OAuth App in my GitHub account:

OAuth App in GitHub

This time I got both the client id and the client secret. Hooray!

OAuth App Credentials

Time to start the “dance”! As a warm-up we can do that easily using httr::oauth2.0_token as per the demo:

client_id <- "f6385d144d7ac17b83df"
client_secret <- keyring::key_get("OAUth_Test_Client-Secret") ## sorry folks ;)
myapp <- oauth_app("test_oauth",
                   key = client_id,
                   secret = client_secret)
github_token <- oauth2.0_token(oauth_endpoints("github"), myapp)
gtoken <- config(token = github_token)
GET("https://api.github.com/rate_limit", gtoken)

## Response [https://api.github.com/rate_limit]
##   Date: 2021-12-04 21:01
##   Status: 200
##   Content-Type: application/json; charset=utf-8
##   Size: 1.07 kB
## {
##   "resources": {
##     "core": {
##       "limit": 5000,
##       "used": 0,
##       "remaining": 5000,
##       "reset": 1638655269
##     },
##     "search": {
##       "limit": 30,
## ...

Worked pretty smooth, didn’t it? Yet I wanted to understand each part of the dance. Thus, instead of relying on the blackbox oauth2.o_token I constructed all the necessary calls separately which helped me to finally understand (or so I think) what is going on under the hood:

base_url <- "https://github.com"
path <- "login/oauth/{end_point}"
## oauth_callback() --> http://localhost:1410/
url <- modify_url(base_url,
                  path = glue(path, end_point = "authorize"),
                  query = list(client_id = client_id,
                               redirect_uri = oauth_callback()))
## This opens a web browser pointing to the url and 
## opens a webserver on port 1410 to listen to the response. 
code <- oauth_listener(url)

## Provide credentials in the spawned browser
access_token <- POST(modify_url(base_url, 
                                path = glue(path, end_point = "access_token")),
                     add_headers(Accept = "application/json"),
                     body = list(client_id = client_id,
                                 client_secret = client_secret,
                                 code = code$code))
GET("https://api.github.com/rate_limit", 
    add_headers(Authorization = paste(content(access_token)$access_token,
                                      "OAUTH-TOKEN")))

## Response [https://api.github.com/rate_limit]
##   Date: 2021-12-04 21:01
##   Status: 200
##   Content-Type: application/json; charset=utf-8
##   Size: 1.03 kB
## {
##   "resources": {
##     "core": {
##       "limit": 60,
##       "used": 0,
##       "remaining": 60,
##       "reset": 1638655279
##     },
##     "search": {
##       "limit": 10,
## ...

Booom! My key take away messages from here:

1. You need a web server to participate in the dance (https://localhost is just fine).
2. You cannot (at least for GitHub authentication) redirect the response form the authorize service but to the callback URL.
3. Because you cannot redirect the response with the code, you can authenticate only at the service defined by the callback URL.
4. Thus, you cannot remotely authenticate via a script. Full stop.³

While this helped tremendously to understand the OAuth protocol it did not help a bit to extract the data via script as I could not log on.

I was just about to give up, when I made a last Google search on how to login curl adventofcode and I found this gem. A python library to download the AoC data. But how the heck did they manage to authenticate? And here’s where the pieces fall into place. I learned that all I have to do is to

1. Log on AoC manually.
2. Get the session cookie.
3. Eventually use the session cookie to authenticate our requests.

Et voilà. Quite some trial and error until I found out that the solution is rather easy. But as always, I learned an awful lot.

2.2.2 Final Solution

session_cookie <- set_cookies(session = keyring::key_get("AoC-GitHub-Cookie"))
puzzle_1 <- GET("https://adventofcode.com/2021/day/1",
                session_cookie) %>% 
  content(encoding = "UTF-8") %>% 
  xml_find_all("///article") %>% 
  lapply(as.character)

data_1 <- GET("https://adventofcode.com/2021/day/1/input",
              session_cookie) %>% 
  content(encoding = "UTF-8") %>% 
  read.table(text = .) %>% 
  as_tibble() %>% 
  set_names("depth")

3.1.1 Description

199
200
208
210
200
207
240
269
260
263

199 (N/A - no previous measurement)
200 (increased)
208 (increased)
210 (increased)
200 (decreased)
207 (increased)
240 (increased)
269 (increased)
260 (decreased)
263 (increased)

3.1.2 Solution

We need to count how often the depth measurement increases, which breaks down to counting the positive signs of the differences of consecutive numbers:

sgn_a <- data_1$depth %>% 
  diff()
sum(sgn_a > 0)

## [1] 1713

3.2.1 Description

199  A      
200  A B    
208  A B C  
210    B C D
200  E   C D
207  E F   D
240  E F G  
269    F G H
260      G H
263        H

A: 607 (N/A - no previous sum)
B: 618 (increased)
C: 618 (no change)
D: 617 (decreased)
E: 647 (increased)
F: 716 (increased)
G: 769 (increased)
H: 792 (increased)

3.2.2 Solution

Now we need to do the same but not for the single measurements, but for the consecutive sum of 3 elements. We can conveniently use zoo::rollsum:

sgn_b <- data_1$depth %>% 
  rollsum(3) %>% 
  diff()
sum(sgn_b > 0)

## [1] 1734