►
Description
Ever wanted to connect a device without a browser to GitHub? In this Workshop, we'll build a simple command line tool on a headless server to demonstrate the power of the OAuth device authorization flow. Devices can get user authorization and do cool things on your behalf. Difficulty level = Intermediate (200)
For more from GitHub Universe 2020, visit https://githubuniverse.com
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
B
A
A
A
A
B
Hi
everyone
we're
about
to
start
the
presentation
before
I
hand
it
over
to
the
presenter
there's
a
few
things
I'd
like
to
cover
first
off,
if
you
haven't
already,
please
take
a
peek
at
our
code
of
contact
pasting,
those
that
information.
Now
your
chat
moderators
are
myself
at
jovel,
one
as
jay
pemberty
mark
as
terabyte
and
sean
as
sean
feldman
moderators.
Please
give
a
wave
in
the
slack
channel.
I
hope
all
of
our
attendees
are
in
the
slack
channel
now.
B
Thank
you.
Moderators
moderators
are
here
to
answer
your
questions,
especially
during
the
coding
segment.
Please
register
conversations
if
possible.
I
will
also
post
and
pin
links
in
the
slack
channel
that
the
speakers
mentioned
throughout
the
presentation
for
easy
access
and
if
you
have
any
questions
for
the
speakers
or
would
like
for
the
speakers
to
go
over
something
one
more
time.
Just
mention
me
at
javel
with
your
question
and
I
will
ask
them.
B
I
will
ask
the
speakers
during
breaks
in
the
presentation
next
up
code
spaces,
you
have
the
option
to
do
the
coding
exercises
using
codespace
or
your
local
dev
setup
code.
Spaces
is
currently
in
beta
and
requires
a
sign
up.
So
if
you're
interested
please
dm
sean
feldman
your
github
handle,
and
he
will
try
and
get
you
enabled
during
the
workshop.
B
C
D
And
I'm
jake
wilkins,
I
use
he
him
pronouns
and
I'm
also
an
engineer
on
the
github
apps
team
and
I
know
jovel
just
introduced
him,
but
we
have
a
handful
of
great
moderators
available
in
slack
to
help
you
troubleshoot
any
problems.
You
might
have
answer
any
questions
or
relay
them
on
to
us
to
pass
along
and
just
generally
make
sure
the
whole
workshop
runs
smoothly.
D
Awesome,
hopefully,
you
can
see
my
screen
now
we're
gonna,
really
just
kick
it
off
testing.
All
of
our
luck
with
a
couple
of
live
demos.
The
first
one
I
have
is
cli
that
we're
gonna
authenticate
if
you're
not
familiar
with
the
device
flow,
it's
really
great
for
authenticating
things
that
don't
have
access
ready
access
to
a
browser
or
a
keyboard,
or
something
like
that
from
a
like
a
flow
perspective,
a
technical
flow
perspective.
D
It
begins
with
a
request
to
github,
saying:
hey,
we're
going
to
walk
a
user
through
this
device
flow
and
that's
a
simple
post
request.
It's
looks
like
this.
You
just
have
to
pass
along
the
client
id
and
don't
worry
about
looking
at
any
of
these
requests
or
urls
too
carefully
we're
going
to
be
covering
this
in
the
in
the
workshop
today.
D
So
if
you
make
that
request,
it
gives
you
this
response,
which
gives
you
a
handful
of
things
that
this
device
is
going
to
need
to
walk
through
the
rest
of
the
flow
you
can
see.
We
have
a
device
code
and
user
code
and
the
the
first
thing
that
this
device
needs
to
do
with
this
information
is
set
up
a
like
a
poll.
Loop
saying:
hey
github
has
this
user
walked
through
this
flow
yet
and
we're
gonna
do
that
like
this?
D
It's
just
another
post
request
passing
along
that
device
code,
and
you
can
see
here
that
the
the
response
that
we
initially
get
is
an
error
for
authorization
pending.
That's
because
I
haven't
entered
the
code
yet
so
I'm
going
to
go
ahead
and
do
that
here
in
this
tab,
just
by
copying
and
pasting
for
this
demo
and
click
continue
now
that
we
know
what
app
we're
trying
to
authorize,
github's
going
to
say:
hey
jake,
do
you
want
to
authorize
this
app?
D
D
And
continue,
this
is
a
project.
I've
been
working
on
my
team,
the
apps
team.
We
ship
a
lot
of
code,
which
means
we
review
a
lot
of
code.
This
looks
good,
I'm
going
to
go
ahead
and
authorize
it
and
it
just
it
can
be
sort
of
exhausting
it
says
you
can
see
the
device
says.
I've
authenticated.
We've
got
that
successful
access.
Token
response,
so
I
wanted
to
build
a
button
that
might
make
that
flow
a
little
bit
easier.
D
C
C
D
User
to
server
requests,
they
take
a
cross
section
of
what
the
the
everything
that
the
app
has
access
to
and
everything
that
the
user
has
access
to.
So
what
we
mean
by
access
on
the
left-hand
side,
that
represents
everything
that
the
app
is
installed
on
so
resources
like
repositories
and
issues
and
pr's
associated
to
that
those
required
installation
for
an
app
to
access
it,
and
on
the
other
side,
we
have
everything
that
the
user
is
granted
access
to
through
typical
github
access
controls.
C
Looks
like
we're
good.
So
next,
let's
talk
about
user
authorization
flows
and
now
we
have
two
ways
to
do
this.
We
have
the
traditional
webflow
and
we
get
reducted
to
a
page
like
this,
from
within
your
browser
and
after
authorizing
you
get
redirected
back
to
the
github
app
itself
here,
the
slack
app
by
github.
Once
you
authorize
a
redirect
to
slack.github.com.
D
And
the
next
is
the
newly
released
device
flow
that
we
had
a
demo
of
earlier.
You
saw
earlier
that
it
can
authorize
like
devices
that
don't
have
access
for
keyboard
browser
things
like
that.
It
works
by
using
an
eight-digit
code
to
associate
the
user's
browser
session
to
a
given
device
and
that
screenshot
on
the
next
slide
shows
what
that
looks
like
just
entering
into
that
screen
there
and
in
ietf
terms,
it
looks
like
this.
This
is
what
the
first
demo
was
sort
of
demonstrating
just
sort
of
walking
through
this
whole
process.
D
I'm
not
super
great
with
these
diagrams,
but
you
know
we
saw
in
the
demo
that
it
starts
with
the
step.
A
and
b
is
the
device
reaching
out
to
the
authorization
server
in
this
case
github
saying:
hey:
let's,
let's
get
a
code
and
a
user
code.
The
device
starts
this
polling
loop,
where
we
repeatedly
request
to
github.
Hey,
has
this
user
entered
this
code
and
meanwhile
the
user
enters
this
code
and
authorizes
the
app
to
make
these
requests?
D
D
If
you
have
a
second
a
two
of
a
set,
I
believe
github
will
prompt
you
for
that
during
the
the
authorization
step.
So
when
the
user
gets
to
the
browser
and
they
enter
the
code,
they
that's
where
github
will
request
that.
That's
I
believe
that
to
be
true,
but
our
moderators
are
sort
of
especially
at
terabyte
is
a
subject
matter
expert
in
this
field.
So
if
he
has
a
better
answer,
feel
free
to
chime
in.
D
C
C
C
C
C
This
next
little
box
is
just
a
description
to
tell
users
what
your
github
app
will
be
and
is
very
useful
in
production,
but
we're
going
to
be
skipping
it
for
now
as
we're
keeping
our
app
in
development
mode
for
this
home
page
eol,
I'm
actually
going
to
go
over
to
the
first
tab.
We
have
our
workshop
repository
and
just
copy
that
link.
C
C
This
first
one
is
the
user
authorization
callback
url
and
is
we
use
it
to
solve
our
flows,
but
it's
for
that
first,
traditional
workflow,
that
we
were
mentioning
so
after
the
app
is
authorized.
It'll
be
redirected
back
to
this
url
as
we'll
be
using
the
device
for
today
we
won't
be
needing
this,
so
we
can
uncheck.
This
expire
use
authorization
token
and
keep
going
this
next
url
is
for
post
installation
so,
instead
of
after
authorizing
app,
this
is
after
you
install
the
github
app
in
case.
You
want
your
user
to
complete
additional
setup
again.
C
It
won't
be
something
we're
using
today,
so
we
can
keep
going
this
last
ufl.
The
web,
plug
y'all
is
one
of
my
favorite
features
of
githubs
and
one
I've
used
several
times.
If
you
can
listen
to
anything
on
github
anytime,
an
issue
is
created,
pull
requests
are
open.
Labels
are
added
any
of
those
events.
You
can
be
sent
to
your
app
through
this
url
still,
it
won't
be
something
we're
using
today,
so
you
want
to
uncheck
this
active
checkbox
so
that
this
hook
is
not
triggered.
C
C
These
are
three
of
our
permission
categories.
I
mean
you
can
see
that
there's
a
lot
of
a
lot
of
different
permissions
underneath
these,
because
we
want
these
permissions
to
be
as
fine-grained
as
possible.
So
when
users
install
your
app,
they
know
exactly
what
the
app
has
access
to
today,
we'll
be
creating
an
issue.
C
So
underneath
repository
permissions,
we
want
to
scroll
down
to
issues,
and
we
want
to
change
this
access
level
over
to
read
and
write
so
that
we
can
also
create
issues
on
a
repository
if
you
notice
this
actually
gave
us
a
mandatory
metadata
permission
here.
This
gives
you
basic
repository
information.
That's
super
good
for
any
or
positive
permissions
you
have,
which
is
why
it's
a
mandatory
permission
and
of
anything
within
this
category.
C
C
I'm
going
to
leave
it
on
only
on
this
account,
because
I
don't
particularly
need
anyone
else
installing
my
app
yet
don't
need
anyone
else
using
it
for
themselves,
and
so
it's
fine
to
be
only
on
this
account
again.
Any
of
these
settings
can
be
changed
at
any
point
after
you
create
the
app
these
will
always
be
here
to
change,
but
before
I
move
on
and
actually
create
this
up
are
there
any
questions?
C
C
D
D
So
new
code
space-
and
this
should
start
setting
up
a
code
space
for
me
and
I'm
gonna
pop
this
window
out
into
a
new
window,
because
I
want
to
be
able
to
reference
some
of
our
documentation.
While
we
go
and
I'm
going
to
just
do
a
little
bit
of
window,
tidying
real
quick.
While
our
code
space
is
running.
D
And
the
other
thing
that
I'm
going
to
do
like
I
said
I'm
going
to
go
back
to
our
workshop
repo.
I
want
to
leave
this
open
if
you've
read
through
the
readme
there's
some
really
helpful
links
down
here
for
our
docs
and
we're
actually
going
to
be
following
the
device
flow
docs
pretty
closely.
So
I'm
going
to
pop
that
open.
So
I
have
it
to
reference
while
we're
doing
this
workshop
and
just
sort
of
waiting
for
the
code
space
to
initialize.
D
D
While
that's
still
initializing,
I
think
heather
left
our
installation
off
on
the
installation
settings
page
and
we're
going
to
need
a
value
off
of
the
app
settings.
So
I
can't
see
that
full
with
this
window
size,
I've
made
it
big,
so
you
all
can
read
it,
but
I'll
make
it
the
window
a
little
bigger
for
me
to
navigate.
D
So,
if
you're
on
this
page,
my
I'm
using
my
test
account,
which
is
evil
jake
and
if
you're
on
the
app
installation
settings,
we
want
to
go
back
to
the
app
settings
page
so
that
we
can
copy
a
value
out
of
that,
and
I
also
have
not
logged
in
so
I'm
getting
prompted
with
this
sudo
access.
I'm
going
to
get
logged
in
real,
quick.
D
D
D
D
D
Yeah
cool,
and
so
the
next
thing
that
we
need
to
do
to
proceed.
We've
got
the
help,
docs
open
and
we're
starting
with
a
blank
slate
for
this
workshop.
So
the
first
thing
I
need
to
do
is
create
a
file
for
us
to
code.
Out
of
so
I'm
going
to
touch
a
workshop
and
we
do
want
to
call
it
workshop.
We
have
a
handful
of
scripts
that
can
help
you
out.
If
you
get
stuck
along
the
way
the
diff
checkpoint,
checkout
checkpoint
and
those
all
depend
on
the
file
being
called
workshop.
D
I
need
to
create
a
tmux
session
so
that
I
can
do
a
split
screen
cool.
So
I'm
gonna
open
that
workshop
file
here
and
I'm
going
to
use
vim
and
you
can
use
whatever
editor.
You
want,
hopefully
you're
using
code
spaces
because
it
works
better
for
you
and
the.
What
I
want
to
add
is
now
that
I've
made
it
a
file
made
it
executable.
I
want
to
tell
my
shell
or
whatever
how
to
execute
this
file.
So
I'm
going
to
add
a
shebang
line:
that's
user
bin
e
and
b.
D
You
should
too,
because
that's
what
we're
coding
in
and
now
that
I
have
that
I
I'm
going
to
start
this
project
the
way
every
good
project
should
start
with
hello
world
so
puts
hello
world,
and
then
that
should
work
this
all.
The
hello
world
example
is
great
for
finding
any
bugs
in
our
setup,
so
I'm
going
to
just
run
that
file
awesome.
I
see
hello,
the
hello
world
message.
D
If
you
don't
see
that
hit
up
our
moderators,
they
might
be
able
to
help
troubleshoot
your
setup
a
little
bit,
and
so
with
that
we
have
one
little
one
other
bit
of
housekeeping
like
I
said
we
have
scripts
to
help.
You
like
stay
with
us
during
this
presentation.
If
you
fall
behind
and
those
depend
on
us
having
our
environment
set
up,
so
I'm
going
to
create
another
file,
that's
dot
env
by.
D
However,
you
want
to
create
a
new
file,
I'm
going
to
touch
it
and
then
open
it
in
vim,
and
I
need
two
things
in
here.
The
first
thing
I'm
going
to
need
is
this
client
id
from
the
app
settings
page.
This
is
why
I
had
us
all
go
back
here.
So
I'm
just
going
to
copy
the
client
id
from
the
app
settings
page
and
I'm
going
to
add
it
to
this
file
with
the
line.
Export
clan
underscore
id
all
caps
equal
to
that
client
id
value,
and
I
need
one
other
variable
in
here.
D
We're
gonna,
set
an
environment,
variable
called
repo
and
we're
gonna
set
it
to
the
the
name
with
owner
string
of
the
repo
that
we're
using
to
test
with.
So
I
have
a
repo
vigilant
robot
and
I
want
to
copy
my
username
and
that
repo
name
and
paste
that
over
here,
so
the
repo
environment
variable,
is
equal
to
evil,
jake,
slash,
vigilant,
robot
and
with
that
saved
so
export
both
of
those
environment
variables.
I'm
gonna
source
that
into
my
my
shell,
so
that
I
have
them
available
for
the
script
to
run.
D
C
C
We
want
to
put
something
useful
for
the
user
to
know
what
the
script
does,
and
so
what
we
will
be
building
today
is
we
have
we
want
to
authenticate
with
this
oauth
device
flow
that
we've
mentioned
several
times
now,
so
that
would
be
some
kind
of
login
method,
we'll
want
to
use
this
authorization
to
create
an
issue
on
github.
So
I
want
some
create
issue
method
and
then
we
can
change
this
usage
into
a
help
method.
C
C
That
false
sub
command
and
when
we
pass
in
us
doing
like
help
to
the
script,
we
can
call
this
help
method
now,
for
the
else
case,
we
actually
kind
of
want
to
call
the
help
method
too.
It's
a
little
redundant
in
this
case,
but,
as
we
add
more
methods,
this
will
make
more
sense
now
that
we
have
this
method
and
a
way
to
call
it.
When
we
run
workshop,
we
can
pass
and
help
and
get
that
usage
method
right
there.
D
Cool
thanks,
heather.
I
will
share
my
screen
and
I
want
to
get
caught
up
to
where
you
were
so
I'm
going
to
use
the
script
checkout
checkpoint
of
one
and
check
out
checkpoint,
one
of
eight
I
should
be
here
and
I'm
gonna
just
run
my
script.
To
make
sure
it's
working
awesome
and
I
forgot
to
do
a
setup
here.
I
was
trying
to
troubleshoot
my
code
spaces
issue.
D
D
The
first
thing
to
get
started
with
this
login
is
I'm
going
to
define
a
another
case
called
login
and
inside
that
clause,
I'm
just
going
to
call
a
method
called
login,
and
the
next
thing
I
need
to
do
is
define
that
method.
So
I'm
going
to
go
up
above
and
define
login
and
step.
One
here
is:
we
need
to
make
that
request
to
github,
so
we're
gonna
be
making
an
hd
http
request
and
we
didn't
want
to
introduce
any
dependencies
or
have
any
issues
there.
D
D
What
am
I
going
to
do
while
I'm
up
here
at
the
top
of
the
file,
I'm
going
to
set
a
constant
we're?
The
first?
This
first
request,
like
we
saw
in
the
demo,
needs
the
client
id.
So
I'm
gonna
find
a
constant
up
here
with
our
dot
env
file.
We
exported
that
value
to
our
environment,
so
I'm
gonna
use
env.fetch
to
get
that
out
and
so
all
caps
client
id
equals
env.fetch
client
id
so
that
we
have
that
available.
D
D
D
So
I'm
going
to
start
another
variable
called
entry
params
and
we're
going
to
have
to
because
we're
using
standard
library
and
not
any
helpful
gyms.
That
would
do
this
for
us
we're
going
to
have
to
encode
it
ourselves,
so
I'm
going
to
set
that
variable
to
a
uri
dot
in
code,
www
form
which
will
just
take
it
and
use
the
uri
encoding.
So
it's
the
client
id
underscore
equal.
D
D
This
isn't
strictly
required
for
the
oauth
device
flow,
but
we're
going
to
send
an
accept
header
of
application
json,
because
we're
going
to
be
working
with
this
response
value
and
it's
easier
easier
for
us
to
work
with
json
and
since
we're
going
to
be
requesting
json
we're
going
to
need
something
to
parse
it.
So
I'm
going
to
hop
back
up
to
the
top
of
the
file
again
and
require
the
json
library.
D
So
I'm
going
to
assign
another
variable
to
http
result,
and
I
want
to
set
that
to
the
return
value
of
a
net
http
post
request
just
by
net
http.post
and
pass
in
the
three
things
that
we
just
set
up
so
entry
uri
entry,
params
and
headers.
Those
are
the
three
things
you
need
and
that
should
be
good
to
go
and
the
ruby
standard
library,
net
http,
http
parses,
these
responses
into
different
classes.
D
So
we're
going
to
use
that
to
do
a
little
bit
of
error
handling
here
and
we're
going
to
set
our
response
to
another
case
statement
based
off
of
http
result
and
when
we
get
a
successful
response
from
http
http.post
it'll
be
a
class
of
net
http,
okay
and
in
the
claw,
the
http,
ok
clause.
What
we
want
to
do
is
just
parse
the
json
that
will
be
in
the
respon
that
the
result
body
so
json.parse
net
http
result.
D
Dot
body
will
set
the
value
of
the
response
variable
to
a
hash
with
that
json.
And
then
we
don't
really
expect
there
aren't
any
really
known
failure.
Scenarios
to
this
endpoint,
so
if
we've
gotten
here,
it's
truly
unexpected.
So
I'm
just
going
to
call
an
else,
and
in
that
case
I'm
going
to
give
us
some
helpful
debug
by
putting
http
results
which
will
tell
us
the
class,
which
is
usually
just
the
response
code
and
then
also
the
body
of
that,
so
that
we
can
take
a
peek
at
that.
D
So
I
want
to
put
a
response
and
see
what
we
got
and
I
think
that
should
run
so
I'm
going
to
go
ahead
and
hop
down
and
test
it
and
period
4
workshop
login
is
the
name
of
the
subcommand
and
awesome.
That's
working.
I
have
my
device
code
and
my
user
code
that
we
saw
in
the
demo
before
and
unless
there
are
any
questions
from
the
moderator
I
will
hand
it
over
to
heather.
D
D
C
C
C
C
C
A
C
C
Fun
string
may
seem
a
little
odd,
but
we
built
this
device
flow
to
the
ietf
spec,
and
this
was
part
of
the
spec,
and
so
we
kept
it
in
to
be
consistent
and
say
we
wrote
it
to
this
book,
so
grant
type
is
going
to
be
this
string
that
you
can
just
copy
and
paste
on.
In
with
that,
I
also
need
to
close
this
ending
parenthesis,
but
those
will
be
all
poll
points
now.
The
huddles
can
actually
be
the
same
from
the
first
request.
C
We
did,
but
there's
one
more
thing
I
want
to
do
since
this
is
a
polling
request.
We
want
to
continually
hit
this
endpoint
until
we
get
authorization
notice
and
so
to
be
able
to
pull
consistently
we're
gonna
have
an
interval
and
again
this
is
something
that
we
actually
got
from
the
response
from
that
initial
response
we
have
interval
is
five
which
stands
for
five
seconds,
and
this
means
that
we
are
going
to
pull
this
endpoint
of
leave
five
seconds.
C
We
did
awesome
I'm
going
to
pause
here
for
a
second
because
that's
been
a
little
bit
of
typing
and
the
next
thing
we're
going
to
be
doing
will
be
a
bit
of
rearranging
I'll
wait
see
if
there
are
any
questions,
I'm
getting
a
thumbs
up
from
the
moderator,
so
I
hope
everyone
has
been
following
along,
but
yes,
so
the
next
thing
we're
going
to
be
doing
this
after
this
polozone.
We
want
to
do
the
same
thing
that
we
did
before
we
scroll
up.
C
We
had
this
case
statement
on
http
result
and
we
just
want
to
check
if
it
was
a
successful
request,
and
so
we
want
to
do
the
exact
same
thing.
We're
going
to
do
this
entire
case
statement
pretty
much
exactly
and
one
of
coding
best
practices
is
we
don't
really
want
to
duplicate
code,
so
this
is
going
to
be
time
to
refactor.
C
C
C
C
C
C
C
C
D
D
This
looks
the
same
and
I
will
run
it
with
workshop.
Login
awesome
authorization
pending
and
so
this
thumbs
up
we're
good
to
go.
Everybody's
I'm
gonna
keep
moving
along
we're
in
step
three
of
the
docs,
and
if
we
look
at
the
response
codes,
we
also
have
these
error
codes
for
the
device
flow
and
they're
error
codes,
but
several
of
them
are
not
exceptional
because
we
sort
of
expect
to
get
them
and
the
first
one
that
we
obviously
we're
seeing
it
repeatedly.
So
we
should
expect
to
receive
it.
D
So
we're
going
to
sleep,
the
interval
which
we
received
from
github
in
our
initial
request,
which
defaults
to
five
seconds,
and
we
just
wanna,
you
know,
give
some
breathing
room.
We
don't
wanna,
be
hitting
this
in
point
too
fast,
so
we're
gonna
sleep
for
five
seconds
and
then
I'm
gonna
call
next
just
to
proceed
through
the
next
iteration
of
this
loop.
D
Speaking
of
hitting
this
end
point
too
fast.
If
we
are
hitting
this
endpoint
too
fast,
we'll
get
this
next
error
code,
which
is
slow
down,
and
this
just
says,
for
whatever
reason
this
is
some
point
has
been
you've
been
requesting
it
too
often
too
quickly.
We
need
to
just
slow
down,
and
so
in
this
scenario,
github
actually
sends
the
interval
that
you
should
sleep.
D
So
I'm
going
to
update
the
value
of
our
interval
interval
variable
to
be
the
poll
response,
interval
value,
so
interval
equals
pull
response
brackets
interval,
and
then
I'm
going
to
wait
for
that
amount
of
time
by
sleeping
for
interval
and
call
next
to
proceed
through
the
next
iteration
of
this
loop,
and
those
are
the
only
two
error
codes
that
we're
sort
of
required
to
implement.
We
can
see
that
we
have
several
more.
D
That
would
be
a
good
idea
to
implement
if
we're
implementing
a
device
flow
client,
but
for
the
purposes
of
our
workshop
today,
we're
going
to
skip
those
and
we're
just
going
to
define
an
else
clause
here
that
breaks
us
out
of
this
loop.
If
we
get
that,
so
I'm
going
to
say
else
puts
the
pull
response
so
that
we
get
some
debugging.
D
D
Of
pull
response
access
token
and
run
it,
because
this
is
our
first
successful
trip
through
the
device
flow
with
our
workshop
code.
So
we
can
see
here
that
it
prompts
me
with
the
the
link,
as
we've
seen,
I'm
going
to
copy
my
code
enter
it
in
authorize
the
app,
and
I
should
see
a
code
printed
out
perfect
that
worked.
We've
successfully
gone
through
it,
but
we
don't
really
want
to
be
that's
not
what
we
want
to
do.
D
We
want
to
store
this
token
somewhere,
so
that
was
just
a
fun
like
your
code
works
huzzah.
If
you
didn't
get
that
remember,
you
can
diff
the
checkpoint
to
see
what's
missing,
but
we
do
have
a
little
bit.
We
do
have
a
handful,
a
couple
more
things
we
need
to
do
before
this
checkpoint
wraps.
So
what
we
want
to
do,
instead
of
writing
that
to
standard
out
is
we
want
to
write
this
to
a
file.
D
D
And
that
will
write
it
to
a
file,
but
just
because
this
is
like
we've
said
before.
This
is
a
token
that
you
can
use
throughout
our
apis.
I'm
going
to
change
the
permissions.
The
default
file
permissions
for
that
are
readable
by
everyone,
so
I'm
going
to
change
that
to
readable
only
by
the
user
by
calling
file,
utils
dot,
chmod
period
forward,
slash
dot
token,
just
a
little
nod
to
security
here.
D
If
you're
shipping
this
to
somewhere,
I
think
you
know,
follow
the
best
practices
for
wherever
you're
shipping
it
to
for
how
to
secure
this.
So
with
the
file
utils
mod
that
doesn't
actually
come
preloaded,
so
I'm
going
to
need
to
hop
back
to
the
top
of
the
file
and
require
file
utils
to
be
able
to
change
the
permissions
of
that
file,
so
up
at
the
top
require
file,
utils
and
then
back
down
to
the
body
of
our
loop.
D
D
C
C
C
C
C
C
C
C
C
C
C
So
those
are
all
of
the
variables
we
are
going
to
be
doing
right
now
before
we
create
the
request-
and
this
actually
is
the
end
of
checkpoint
6..
So
if
you
want
to
do
script
check
out
checkpoint
six
to
get
caught
up
to
this
spot,
you
are
welcome
to,
but
I'm
not
going
to,
because
I
have
made
a
tea
on
myself
and
I
thought
we're
going
to
keep
on
going.
I
think-
and
the
next
thing
to
do
is
to
make
these
food
crusts
and
so
like.
C
C
C
However,
one
thing
to
note
is
with
this
response:
we
actually
get
a
status
201
created
because
we
are
making
something
on
github,
so
in
that
case
we
actually
have
to
scroll
back
to
our
pause
response
method.
So
it's
going
back
to
the
top
of
my
file
and
up
here
instead
of
having
just
this
net
http,
okay,
we
also
need
to
add
net
http
created,
because
this
is
also
successful
as
status
code
and
we
want
that
to
be
caught
and
post
as
well.
C
C
Type
this
with
jq.
Let
me
clear
this,
so
you
can
see
that
we
have
bookshop,
create
issue
pipeline
into
jq,
and
we
can
see
this
nicely
printed
response.
We
see
some
things
like
the
phone
via
gif
up.
We
see
this
body
is
all
beautiful
issues
and
if
I
go
over
to
my
repo,
it
does
look
like
we
saw
this,
which
is
fantastic
with
that.
I'm
gonna
hand
it
back
over
to
jake
for
the
last
stretch.
D
D
Looks
like
we're
good
on
questions,
so
I
will
check
out
checkpoint
seven
and
catch
up
to
where
heather
is,
which
we
are
checkpoint.
Eight
is
a
very
small
checkpoint.
The
only
thing
we
really
need
to
do
because
we
have
successfully
authenticated
with
device
flow
and
we've
sort
of
proven
ourselves
by
creating
an
issue
we're
authenticating
with
the
github
api,
I'm
going
to
run
it
just
to
make
sure
I
also
get
a
successful
response,
looks
like
we're
good
to
go.
D
We
just
want
to
make
this
response
a
little
bit
friendlier
so
we're,
instead
of
putting
displaying
all
of
the
json,
we
are
going
to
just
put
a
helpful
friendly
little
message
here
of
you
can
visit
your
issue
here
and
the
response.
Json
has
the
html
url
of
the
issue
we
just
created,
so
we're
going
to
print
the
print
that
out
so
that
the
user
can
just
click
it
from
their
terminal
and
open
it
in
their
browser.
D
D
D
I
don't
think
that
we
have
anything
else
for
that.
I
do
want
to
quickly
walk
you
through
one
last
bit
of
housekeeping
and
just
show
you
all,
since
we
have
made
a
demo
app
and
we
have
written
tokens
to
your
computer,
I
want
to
show
you
how
to
deauthorize
those
just
to
close
up
any
lingering
security
holes
or
that
we
might
have
had.
D
And
then
scroll
down
to
applications,
which
is
the
last
in
the
main
navigation
bar
on
the
left,
you
can
go
ahead
and
under
authorize,
github
apps.
You
can
revoke
the
permission
for
our
presentation
app
and
if
you
do
that,
the
token
that
you've
created
is
no
longer
valid.
If
I
try
to
create
another
issue,
I
get
a
bad
credentials,
obviously
demonstrating
our
good
error
handling
there
that
we
see
we've
got
invalid
credentials.