►
From YouTube: API Fuzzing Configuration Brainstorm
Description
A technical brainstorm on how to create the API Fuzzing Configuration screens.
Related issue: https://gitlab.com/gitlab-org/gitlab/-/issues/239088
A
A
A
So
in
the
agenda
here
you
can
see
this
is
a
sample
yaml
file,
and
this
is
actually
windowed
down
quite
a
bit.
You
can
actually
have
a
yaml
file,
that's
much
more
complicated
and
there's
a
lot
of
different
data
points
to
this
everything
from
just
some
basic
configuration
like
ssl
keys
and
then
what
we've
got
is
routes
which
is
different
web
paths
and
then
essentially
different
assertions
and
checks,
and
these
are
essentially
different
rules
that
you
can
run
in
api
fuzzing.
A
A
So
I
think
one
of
the
things
that
I
was
thinking
about
is
this
could
be
primarily
a
front
end
essentially
like
a
web
ide,
and
the
idea
that
I
had
was
that
we
have
an
api
fuzzing
configuration
web-based
ide.
So
whatever
this
looks
like
whether
it's
a
text
area,
a
text
box
with
you
know
autocomplete
or
what
I
was
thinking
is
more
likely,
it
would
be
a
form
type
interface
and
having
that
essentially
100
in
the
browser
and
the
browser
would
be
able
to
render
that
out.
A
Based
on
the
schema
that
it's
going
to
get
from
from
gitlab,
so
gitlab
would
send
over.
You
know
the
grammar
and
the
schema
and
everything
like
that.
The
api
fuzzing
configuration
web
interface
would
render
out
a
form,
allow
a
user
to
change
all
the
settings
and
then,
ultimately,
when
it's
done
it
would
validate
it
in
the
browser
to
make
sure
whatever
it
was.
A
Creating
is
correct,
send
that
to
the
server
and
then
the
server
would
also
just
do
another
validation
to
make
sure
that
the
data's,
accurate
and
then
save
that
into
either
the
repo
or
the
database
or
some
method
there.
But
the
idea
is
that
most
of
the
heavy
lifting
is
going
to
be
done
in
the
the
web
interface.
B
It
sounds
like
we'd
be
creating
a
more
generic.
You
know,
yaml
generator
ide
right.
So,
ideally,
if
you're
past
the
scheme
of
anything,
you
know
just
to
specify
the
fields
and
what
are
possible
options
for
that
and
generate
a
yaml
files.
End
result
I
mean,
I
think
we
could
leverage
this
to
generate
any
type
of
camel,
so
just
to
think
about
it,
we
should
maybe
accommodate
just.
B
A
Yeah
absolutely
yeah,
there's
no
reason
why,
whatever
the
schema
looks
like
right,
you
could
write
that
for
any
other
for
any
other
document
that
you're
trying
to
create.
I
don't
know
enough
about,
and
this
is
one
of
the
reasons
I
want
to
get
so
many
people
on
this
call
was,
I
don't
know
enough
about
the
schema
format
to
know
whether
we're
going
to
have
to
extend
it,
whether
we're
going
to
have
to
put
in
dictionaries
and
grammars
and
things
of
that
sort
to
be
able
to
generate
the
document
on
the
front
end.
B
A
A
D
For
example,
you
know
there's
just
descriptions
of
fields
that
would
hopefully
need
to
go
into
the
schema,
so
we
could
display
it
in
the
ui.
That's
we'd
want
to
make
sure
whatever
format
we
pick
had.
You
know
if
there
was
better
support
for
one
and
one
that
might
have
an
impact,
I
think
from
the
code
level.
C
A
B
A
A
A
A
B
A
A
A
So
this
is
nice
if
you're
a
programmer-
and
you
know
what
you're
putting
in
and
all
that
kind
of
stuff.
I
think
the
challenge
that
we
have
with
our
yaml
file
is
customers
are
not
going
to
know
any
of
these
names
right.
These
are
essentially
arbitrary,
they're
they're
specific
to
our
software,
and
so
we
want
to
provide
a
tool
that
gives
them
these
values
up
front
so
that
they
don't
have
to
kind
of
guess,
and
then
you
know
correct
themselves
all
the
time.
E
E
A
D
E
C
E
Yep
and
then
also
so
we
we
just
completed
a
project
for
sassed
that
allows
you
to
configure
sas
and
set
it
up
from
scratch
for
the
first
time.
This
feels
really
similar
and
we've
had
very
similar
conversations
as
well.
So
this
schema
based
editor
yaml
editor
that
seth
justin
would
for
us
didn't
exist
when
we
started
that
project,
and
then
we
had
similar
con
considerations
throughout
in
terms
of
should
we
adopt
it.
It
just
felt
like
it's
not
holding
my
user's
hand
enough
right.
E
I
I'm
happy
to
showcase
her
yeah
cool,
so
yeah.
This
is
the
the
figma
stuff.
Camille
has
been
working
on
and
then
I
think
it'd
be
worthwhile
to
look
at
what
we've
done
for
sas
and
what's
in
production,
because
it's
a
very
similar
initiative.
The
the
big
difference
is
when
you
create
sas
configuration
changes,
they
go
right
into
our
main
ciemo
file,
which
is
a
I
don't
know.
What
to
call
it
the
hodgepodge
right,
there's
so
much
going
on.
We
have
very
tight
control
over
the
cmo
file
that
this
would
populate.
A
E
A
D
A
Okay,
yeah.
That
was
one
of
the
questions
on
the
agendas.
Whether
because
I
think
the
other
option
and
we're
playing
around
with
this
on
on
das
is
instead
of
having
the
configuration
in
the
repo
actually
having
it
in
the
database
and
then
using
a
key
in
your
gitlab
ci
yaml
file
to
refer
to
the
database,
because
you
know
the
challenge
with
this
is
that
you
do
have
to
open
up
the
mr
and
then
someone
has
to
approve
the
mr
to
go
into
the
repo.
C
D
C
A
Yeah,
I
mean,
I
think,
for
the
design
that
camellia
has
got,
there's
there's
a
little
bit
of
they're
blended
right.
We
have
the
values
that
are
on
a
per
run
basis,
and
then
we
have
the
configuration
files
like.
The
second
part
is
the
the
profiles
and
that's
what
I
was
thinking.
Our
discussion
is
around
not
necessarily
if
you
scroll
up
neil
or
mike.
A
So
I
think,
for
example,
the
options
up
top
the
target
url.
These
are
on
a
per
scan
basis,
which
could
live
independently
of
these
different
profiles,
so
that
you
could
have
just
this
whole
library
of
profiles
in
in
your
repo
and
then
this
target
information,
the
scan
mode
authentication,
that's
on
a
per
per
scan
basis.
A
D
D
So
one
of
the
things
that's
going
to
be
captured
inside
the
configuration
is
in
these
profiles.
You
might
also
come
in
and
start
changing
the
ammo
configuration
to
adapt
to
new
technology
stacks
in
in
terms
of
removing
false
positives,
turning
on
and
off
headers
or
adding
routes
that
you
know
enable
or
disable
testing
for
certain
components.
D
D
A
C
D
Meaning
there'd
be
one
central
deployed
component
that
had
this
configuration
in
it
that
everyone
would
basically
use
as
they
ran
jobs,
so
it
was
global.
So
any
change
would
affect
every
job
in
historical
jobs
as
well,
unless
they,
unless
they
use
the
option
to
put
this
configuration
file
into
their
repo,
which
is
something
that
we
added
based
on
customer
requests.
Customers
really
seemed
to
like
the
idea
of
having
the
configuration
file
checked
in
the
repo
and
being
in
synchronized
in
sync,
with
exactly
how
their
project
looked
that
day.
A
D
Yeah-
and
certainly
one
thing
we
could
do
is
we
could,
which
would
also
make
it
easier
for
the
user
to
start
using
the
tool
is
we
could
default
using
using
if
there
wasn't
a
local
configuration
file
provided
we
could
default
to
using
one
stored
in
our
private
repo
or
whatever?
That
might
look
like,
I
would
say
that
I
think
pretty
much.
All
of
our
customers
really
wanted
to
have
a
configuration
file.
They
could
stick
in
their
repo
was
was
whatever
we
kind
of
geared
towards.
A
I
I
think
that
makes
sense,
as
you
start
to
fine-tune
your
scanners.
You
realize,
like
some
of
these
things
are
false
positive.
Some
of
them
are
noise.
It
makes
sense
that
once
you
get
beyond
like
hey
I'm
just
I
just
want
to
try
this
out
real
quick
and
once
you
really
start
wanna
wanna
start
using
it
that
people
would
wanna
tweak
these
configurations.
B
E
E
E
D
Essential
ui
point
and
essential
configuration
and
then
yeah.
We
then
we
we
ended
up
getting
a
lot
of
requests
to
have
that
stored
locally.
So
then
we
that's
where
this
yaml
file
originated.
Was
us
serializing,
our
configuration
out
to
be
put
into
a
repo
and
the
way
it
ended
up
working
is
because
you
know
our
ammo
file
can
be
complex
and
have
a
lot
of
you
know
unknowns
in
it.
The
usage
we
kind
of
ended
up
having
for
the
customer
is
they
could
they
would
take
their
configuration
file?
D
E
And
so
by
integrating
into
git
lab,
I
guess
we're
one
step
closer.
Now
the
configuration
is
specific
to
a
project
to
a
code
base
right
right,
so
we've
kind
of
doing
that,
but
then
you've
you
had
a
proposal
that
extends
that
further,
that
we
have
separate
configurations
like
in
a
feature
branch.
Could
you
extend
on
the
with
the
use
cases
grabbing
separate.
D
D
I
think
the
only
time
that
you'd
have
that
you
change
in
a
feature
branch
is,
if
you
know
I
created
a
feature
branch
to
change,
something
in
the
technology
stack
that
then
created
false
positives
in
my
fuzzed
orion
and
then
as
part
of
that
work.
Maybe
I
would
go
and
update
the
fuzzing
configuration,
but
the
ultimate
goal
there
is
that
it
would
merge
back
into
master
and
be
used.
D
What
I
would
expect
is
that
you
might
have
a
profile
in
the
configuration
file
that
might
only
apply
to
future
branches.
That's
something
that
definitely
could
occur,
but
it
wouldn't
be
as
a
separate
configuration
file
itself
would
just
be
a
separate
entry
in
the
configuration
file
which
is
kind
of
which
are
these
profiles
that
we
have
in
here
you
might
have
a
profile.
That
was
something
that
would
run
on
a
feature
branch
versus
a
master
branch,
but
it
would
be
in
the
same
configuration
file.
A
So
stepping
back
from
where
and
how
we
store
this,
I
guess
one
of
my
my
big
questions
today
is
how
do
we,
edit
this,
this
black
area
and
neil
you
mentioned
and
and
sas
has
kind
of
a
a
form-based
tool?
Now
I'm
curious
if
that
tool
that
sas
is
using,
if
that
is
100
custom
to
the
values
that
they
are
supporting,
or
whether
there's
some
kind
of
schema
and-
and
I
guess,
architecture
that
we
would
be
able
to
leverage
to
make
this
black
area
editable.
E
So
it
just
seemed
too
complex
to
to
try
to
attempt
this
black
area
for
sast.
We
wanted
it
to
be
way
more
intuitive
with
his
user.
There
were
also
a
certain
order
of
events
like
that.
You
would
start
with
the
main.
I
think
it
might
make
sense
and
it
actually
mimics
the
top
part
of
the
screen
that
mike's
showing
very
well.
I
don't
know
if
mike,
if
you
wouldn't
mind,
just
going
back
to
the
agenda
doc
since
you're,
scaring
sharing
your
screen
cell.
We
can
look
at
an
example
of
this
asked.
D
D
I
imagine
what
would
have
to
do
is
generate
the
schema
and
hopefully
have
fields
in
the
scheme.
We
can
put
that
into
you.
So,
for
example,
when
you're
in
that
editor-
and
it
told
you
what
the
field
did
and
they
gave
you
the
values,
maybe
we
could
put
the
metadata
into
those
description
fields
to
be
shown.
A
Yeah,
I
guess
what
I'm
trying
to
understand
is
making
sure
that
the
forms
that
are
on
peach
right
now
are
not
like
custom
forms
where
you've
written
a
bunch
of
custom
logic
for
each
field,
and
then
the
next
field
has
custom
logic.
It
sounds
like
that's
coming
out
of
the
metadata,
so
we
would
be
able
to
use
a
similar
type
of
approach
potentially
for
rebuilding
the
cingulate
lab.
E
So
this
is
our
entry
point
to
the
security
and
configurations
and
compliance
configuration
page.
You
can
see
we
have
the
api
fuzzing
row
here.
What
we've
done
for
sas
is
it
used
to
mimic
the
same
experience
but
we've
since
added
this
configure
button,
and
this
jumps
right
into
this
this
web
form
that
very
similarly,
you
know
is
what
we're
looking
at
for
api
fuzzing.
So
it's
a
really
straightforward
form
right
now.
It's
all
just
text
boxes.
One
thing
we
did
to
make
it
a
little
bit
more
friendly
was
the
width
of
the
text.
E
Boxes
is
configurable
based
on
the
type
of
data
we're
expecting,
so
it
just
doesn't
look
like
some
weird
platform
that
has
some
lifeblood
to
it.
We
and
then
there's
not
much
going
on
here.
It's
all
just
linear,
but
you
can
see
there's
some
main
headings.
We
have
this
configuration
area,
but
then
we
also
have
an
analyzer
section
and
that's
where
trying
to
match
a
schema
became
more
challenging.
E
We
just
had
some
and
our
original
design
had
like
side-by-side
areas
too,
and
it
just
felt
we
were
getting
into
the
weeds
way
too
much
for
the
problem.
We
were
trying
to
solve
this
is,
I
would
say
this
is
the
most
schema.
Probably
based
approach
is
we're
not
following
a
scheme
on
the
front
end?
What
we're
doing
is
heavily
leveraging
the
graphql
data
that
comes
back
so
everything's
in
order.
It's
telling
us
display
breakman
here's
the
text
for
breakman
and
then
here's
the
the
input
values.
So
what
type
of
data
are
we
expecting?
E
What's
the
name
of
the
field
and
then
eventually,
maybe
some
sort
of
validation?
So
if
you
can
envision
that
the
back
end
informs
a
lot
about
what
this
page
does
similar
to,
what
a
schema
would
do
if
I
were
to
create
at
the
end,
just
to
show
you
the
workflow
here
it
ends
up
creating
a
brand
new,
mr,
which
applies
changes
to
our
main
gitlab.cieml
file.
E
What
it
doesn't
do-
and
so
I
didn't
make
any
changes,
and
so
it
purposely
excludes
anything
anything
that
was
defaulted,
that
I
didn't
change,
there's
no
reason
because
it's
already,
including
the
main
sas
template
here.
So
we
don't
want
to
include
all
this
extra
data
points
you
know
because
it
just
causes
confusion.
It
makes
this
more
messy,
so
you'll
notice
that
if
I
were
to
click
back
and
make
a
change
and
hit
submit
again,
you'll
see
the
new
numbers
in
here
to
extend
on
this
really
quick.
We
do
have.
I
don't.
B
E
B
From
the
front,
end
too
is
like
to
make
it
look
like
that
editable
inline
text
editor
is
sort
of
we're
trying
to
implement
the
id
and
that
little
widget
component,
which
perversion
one
of
mvc,
would
be
very
ambitious
and
I
it'd
be
very
hard.
Well,
I
don't
know,
I
mean
technically
seem
like
it'd,
be
much
more
difficult
to
do
then
for
version
one.
I
think
for
like
what
neil
just
demoed
is.
B
We
just
have
a
bunch
of
form
inputs
and
what
we
get
back
for
the
for
some
of
the
data
that
is
dynamic
like
we're
defining
the
data
field
type.
It
is
if
it's
a
form
input
like
a
text
area
or
a
string
or
if
it's
a
number
to
kind
of
help
guide.
What
that
form
looks
like,
but
we're
very
much
relying
on
html
forms
to
populate
what
we
send
to
the
server
to
generate.
I
think
the
yaml
or
the
changes
that
are
in
the
merge
request
that
gets
dynamically.
E
Yeah,
it's
deconstructing
the
yaml
and
then
regenerating
it.
Okay,
so
there's
a
loss
of
lots
of
loss
of
fidelity
in
this
yaml
file.
Unfortunately,
like
things
like
comments,
so
we
have
a
lot
of
known
bugs
if
you
want
to
call
them
that
but
like,
if
there's
any
sort
of
comments,
because
we're
parsing
that
that
yaml
file
those
get
lost,
they're
not
preserved
the
order
of
the
ammo
file
as
well.
The
sas
generation
has
a
very
specific
order
that
it
cares
about,
so
it
might
rearrange
some
things
and
cause
unexpected
results.
E
A
Yeah
I
mean
certainly
if
we're
reorganizing
our
fi,
I
mean,
if
we're
generating
the
file
in
the
first
place,
then
theoretically,
the
changes
will
be
in
the
same
order.
You
don't
have
that
case
in
the
gitlab
yaml
file,
which
a
user
may
be
doing,
and
also
we
don't
have
other
stuff
that
the
user
is
putting
in
there
right.
So
it's
a
hundred
percent
just
for
fuzzing.
So
I
think,
even
if
there's
a
big
change,
it's
all
managed
by
our
our
tool,
not
other
stuff,
that
people
are
putting
into
the
file.
E
Yeah
I'll
extend
one
more
thought
I
had
so.
I
mentioned
we're
using
graphql
and
it
comes
back
with
this
very
nice
structure
that
we're
essentially
looking
for
the
right
pieces
in
the
top
section,
but
then
in
the
bottom
section
analyzers
we're
just
kind
of
iterating
through
and
building
that
out.
So,
as
we
add,
more
analyzers
we
front
end
might
not
have
to
do
any
work.
That's
the
idea!
E
So
that's
very
nice
and
then
the
way
we
submit
that
information
back
is
a
very,
very
similar
format
to
the
query.
It's
just
it's
a
reduced
set
of
things.
It's
just
the
field
and
the
value
in
like
an
array
format,
and
so
the
back
end
is,
is
doing
a
ton
of
work
to
you
know
iterate
back
through
that
and
generate
a
file.
E
B
I
think
for
me,
from
the
front-end
perspective,
the
notion
of
having
like
an
inline
tech
center.
This
is
a
little
bit
more
complex
than
just
like
you
don't
get
loud.
You
know
how
we
have
like
the
comment
section
where
you
can
do
markdown
and
then
we
could
like
render
the
thing.
I
think
it's
a
little
bit
more
than
just
a
text
area
because
I
I
think
or
like
if
you
want
stuff
like
auto,
complete
or
like
suggested
suggestive
like
variables
that
are
based
off
the
schema.
B
That's
provided
that's
getting
in
the
realm
of
like
a
full-blown
ide,
which
I
mean
open
source
projects
they
have
like
electron,
which
lets
you
build
like
client,
like
you
know,
but
there
are
a
lot
of
ids
built
like
vs
code
is
built
in
on
electron,
but
we
don't
want
to
ship
a
giant
ide
package.
You
know
just
to
generate
a
yaml
file
so
like
there's
like
a
lot
of
dependencies,
pulling
that
in
like
if
that's
the
route
I'm
unsure
like.
B
If,
if
we're
going
for
high
fidelity
like
interactive
yaml
generation
with
like
where
you
have
a
ide
feeling
in
the
thing
or
if
our
end
goal
is
just
to
generate
a
yaml,
do
something
like
like
along
the
lines
of
what
neil
had
already
demoed,
it's
not
going
to
look
pretty
it'll
kind
of
kind
of
work.
The
other
option
is,
maybe
are
we
really
just
trying
to
create
a
tool
that
allows
you
to
generate
yaml
files,
independent
of
like
how
they're
used
like
you?
B
You
could
you
know
you
paste
the
existing
one
or
you
could
use
one
that's
based
off
of
schema
to
just,
like
you
know,
as
a
tool
like
a
standalone
tool.
So
I
don't
know
there
are
different
options,
but
in
terms
of
making
it
look,
can
act
like
an
ide.
It
would
be.
I
don't
know
if
it's
worth
the
effort
for
what
we
get
and
if
it
would
be
something
that
we
would
be
able
to
be
able
to
accomplish
within
a
reasonable
time
frame.
D
D
You
know
profiles
have
a
list
of
checks,
checks
have
asserts
and
then,
within
those
things
are
dynamic,
meaning
that
you
know
we
have
a
view
for
profiles
that
you
can
drill
down
into
that.
Then
dynamically
builds
list
of
checks
and
those
checks
build
a
list
of
asserts.
All
those
things
are
kind
of
known,
so
maybe
an
in-between
that
would
be
more
comfortable.
D
Then
you
know
a
purely
schema-driven
ui
would
be
kind
of
an
in-between
where
we
say
hey.
We
can
have
this
idea
of
a
fixed
ui
layout
that
we
dynamically
populate
from
the
schema
metadata
to
say
how
many
things
there
are
and
what
fields
are
are
in
those,
and
that
seems
like
something
that
would
be.
You
know
reasonable
to
accomplish.
E
Very
much,
let
me
show
you
one
more
screen.
I
just
came
to
mind
so
again:
we've
very.
We
simplified
this
approach
a
lot,
so
this
is.
This
is
kind
of
messy
right.
It's
really
straightforward
check
boxes
all
over
the
place,
the
original
design-
and
there
was
a
lot
of
us
ux
conversation
around
this,
which
is
another
reason
we
avoided
it
for
now,
but
you
could
actually
expand
and
collapse.
Sorry,
if
I'm
scrolling
too
fast.
This
is
an
example
of
some
collapsed
and
then
I
think
the
lower
one
is
all
of
them
expanded.
E
I
put
this
link
in
our
doc,
but
I
think
this
actually
starts
to
mimic
what
I'm
seeing
over
here,
the
black
area.
I
want
to
keep
calling
it
that
where
we
we
have
some
top
level
but
then
otherwise,
there's
a
ton
of
repetition
where
we
have
the
name
of
the
check,
as
well
as
what
its
configuration
values
are
and
that
you
can
see
like
in
this
case,
we've
enabled
it
so,
therefore,
it's
going
to
get
included
in
the
yaml
and
then
what
its
configuration,
values
or
properties
would
be.
B
How
does
this
work
if
you
need
like
multiple
entries?
So
let's
say,
for
example,
if
you
have
a
type
of
configuration
like
within
the
sub
level,
but
you
need
to
repeat
that
four
or
five
times
with
the
for
each
version
like
for
each
time
you
list
it
it's
slightly
different.
So
I
can't
it's
kind
of
small
but
like.
B
Look
like
you
scroll
in
all
right,
let's
say
bandit.
Let's
say
you
could
define
bandit
multiple
times
with
you
wanted
to
define
it
multiple
times.
Let's
say
it
wouldn't
make
sense.
In
this
case.
Let's
say
you
wanted
to
duplicate
banded
three
or
four
times,
but
the
only
difference
was
excluded
paths
or
something
like
that
or
a
form
field
where
it
makes
sense
to
have
that
multiple
times,
but
only
one
field
is
different
in
the
ui.
B
E
B
Like
checks,
what's
that
level
is
checks
right
so
well,
I
guess
the
names
would
be
different,
but
in
the
ui
right
there
it's
n
number
of
checks
right
or
is
that
a
finite
set?
Because
if
it's
variable,
where
the
user
can
define
multiple
checks
in
the
ui,
we'd
have
to
have
some
way
to
allow
them
to
add
an
array
of
checks,
not
just
one
or
two
or
a
half
a
finite
set.
B
So,
and
I
think
that
could
be
achieved
by
having
like
the
default
category
there
like
one
instance
of
it
and
it's
default
like
empty
or
default
values,
but
then
having
like
a
plus
mark
or
something
in
the
ui.
We're
just
duplicating
that
input
over
like
that
empty
input
with
the
default
values
over
and
over.
So
the
user
can
then
adjust
them
if
they
wanted
to.
Would
that.
C
D
E
D
D
Things
like
you
can
include
testing
on
include
it.
Configure
which
headers
would
be
included
in
testing,
you
can
list
different
api
token
names
that
might
get
tested
by
one
of
our
modules
and
things,
but
where
this
starts,
adding
a
lot
of
complexity
is
when
we
get
more
over
to
the
profiles
of
testing,
where
you
can
have
a
profile
as
different
settings
for
each
of
the
routes
that
you
might
have
configured.
D
D
D
I
drew
these
profiles
you're
going
to
have
an
associate
a
route.
So
if
I
start
adding
more
and
more
routes,
I
can
have
this
configuration
specified
for
many
different
routes,
and
so
that's
one
of
the
repetitive
complexities
that
shows
up
in
that
yaml
file
is.
If
I
had
three
routes,
I
could
have
a
configuration
file
for
a
profile
that
checks
area
array
is
basically
you.
Turning
on
or
off.
One
of
our
checks
are
built
into
the
tool.
D
Oh,
my
internet
is
being
said.
It's
unstable.
Hopefully
this
doesn't
I
don't
drop
off,
but
one
of
the
things
you're
going
to
do
in
your
profile
is
say
I
want
to
use
one
or
more
of
these
testing
modules
right
now
for
fuzzing
we're
only
turning
on
these
kind
of
fuzzing
tracks
in
there
and
then,
if
one
of
these
checks,
I
can
have
configuration
for
that
check.
I
can
configure
the
assertions
that
run
that
detect
when
a
failure
has
occurred.
D
It
only
for
this
very
specific
route
and
profile
that
we're
currently
in
and
then,
as
you
do,
that
you
know
the
ammo
file
for
that
section
expands
out
to
include
the
non-default
settings
that
you've
changed
here
and
so
the
way
our
ui
works
is.
You
know
we
have
static
screens
up
until
we
get
to
the
listing
of
checks.
So
like
this
listing
of
checks
is
dynamically
generated,
and
then
you
know
what's
configured
inside
that
check
is
dynamically
generated.
D
D
D
D
One
thing
that
I
you
know
that
isn't
done
in
this
configuration
and
could
happen
is
underneath
one
of
these
checks.
I
could
then
have
a
list
of
assertions
and
then
inside
the
list
of
assertions
I
can
have
the
assertions
configuration
done,
so
this
section
can
start
getting
bigger
and
bigger
and
then
you'll
notice
here
we
have
the
configurations
are
per
route.
D
E
So
it
looks
like
that
what
the
peach
product
is
doing
is
very
similar
to
what
we
came
up
with
for
sas
it's
just
instead
of
having
multiple
tabs
or
pages
it's
just
one
page
that
keeps
growing
so
it
seems
like
yeah.
We
could
follow
a
similar
pattern.
I
mean
it
made
front,
end
development,
easy
and,
like
I
said
it
puts
a
lot
of
that
data
structure.
E
E
So
there's
a
big
disconnect.
Can
you
can
you
tap
back
to
the
design,
real,
quick
to
camille's
yeah?
Now
that
I'm
looking
at
this?
I
know
we're
brainstorming
and
we're
talking
about
the
end
game
and
being
able
to
dynamically
modify
a
yaml
file.
But
I
guess
I
didn't.
I
haven't
looked
at
this
enough
because
it
just
came
into
our
inbox
a
day
or
so
ago.
It
looks
like
the
intent
here
is
that
we
have
a
couple
templates.
E
A
C
D
C
E
A
So
we've
got
a
couple
minutes
left
here,
so
I'm
just
would
love
to
get
everyone's
thoughts
on
on
the
next
steps
on
how
we
move
forward,
and
I
I
think,
there's
a
little
bit
of
back
and
forth
between
what
we
can
do
technically
and
what
makes
a
lot
of
sense
from
an
mvc
with
then
handing
some
of
that
over
to
design
and
design,
giving
us
some
ideas.
So
there's
we've
got
to
figure
out
that
process.
B
Like
to
have
all
that
plaster
on
one
page
and
then
like,
I
don't
know
how
many
levels
like
you
know
how
many
levels
deep
it
could
go
for
the
configurations
now,
organizing
that,
like
nested
layers
underneath
can
like
from
a
ui
perspective,
can
get
a
little
overwhelming
to
do
it
all
on
one
page.
So
I
don't
know
that's
right,
design
question,
but
something
to
think
about.
A
A
If
that's
the
case,
what
I
could
see
doing
is
potentially
taking
the
screenshots
that
mike
has
and
figuring
out
okay.
How
do
we
take
those
put
them
into
a
gitlab
design
so
that
we
get
all
the
data
in
there
and
then
and
then
I
think,
that's
a
conversation
once
we
have
that
design,
then
there's
a
conversation
of
okay.
What
data
are
we
going
to
send
to
the
front
end,
you
know?
Is
it
a
json
schema?
Is
it
a
an
array
whatever?
Is
it
graphql?
A
What
data
do
we
send
to
the
front
end
so
that
it
can
populate
the
list
of
asserts?
You
know
what
data
will
the
front
end
know
because
it's
hard
coded
and
every
document
just
has
to
follow
the
structure
and
we
can
break
up
those
components
based
on
kind
of
the
design
that
would
come
out
of
modifying
the
screenshots.
That
mike
has.
A
E
Well,
yeah
thinking
about
the
sas
project.
If
we
were
to
go
with
that
super
fluid
schema
driven,
it
would
have
been
multiple
iterations
and
highly
complex
or
we
were
able
to
get.
Our
nbc
was
crazy,
simple.
We
just
created
that,
mr
off
the
bat
there
was
no
ui
to
manipulate
the
values
and
then
we
followed
up
within
one
or
two
milestones,
afterward
with
that
full
experience.
So
it's
very
iterative
and
we
learned
a
lot
through
that
process
as
well.
E
B
Yeah,
so
I
actually
had
been
kind
of
glancing
here
while
we
were
in
this
meeting.
So
I
mean
it
depends
what
like
like,
how
full
featured
a
lot
of
the
editors,
but
if
you
google,
for
stuff
a
lot
of
them
that
are
coming
out
of
open
source
projects
so
electron,
I
guess
it's
like
via-
is
like
the
framework
that
yes
code
is
built
on
and
that's
a
full
blown
text
editor.
So
my
concerns
there
is
like,
maybe
that
it's
going
to
be
too
much
for
what
we
need.
B
It's
going
to
be
overkill
and
it
would
add
a
significant
amount
of
load
to
our.
You
know
the
assets
we're
serving
over
gitlab.com
for
a
little
thing.
I
don't
even
know
how
big
it
would
be,
because
vs
code
is
an
entirely
multi-megabyte
download.
If
we
go
the
route
like
you
know,
we're
trying
to
work
with
like
a
text
area
like
fundamentally
html
text
area
and
have
you
know
some
view,
logic
to
kind
of
manipulate
that
form
that
form
input
field
with
text
areas.
We
won't
get
the
formatting
that
we
want
for
that
gray
area.
B
So
it'd
be
a
lot
of.
I
don't
know
it's
kind
of
just
a
big
rabbit
hole,
not
that
it's
impossible.
It's
just
kind
of
that.
It's
its
own,
entirely
different
thing,
just
to
write
a
yaml
editor
in
line
in
that
with
like
a
lot
of
stuff
we're
looking
for,
but
I
mean
I
could
spend
some
time
researching
it.
But
I,
in
terms
of
priorities,
I
need
guidance
from
neon,
how
much
time
we
want
to
spend
if
we
want
to
do
a
research
spike
or
where
we
are
in
the
process.
E
Meant
like
we
can
dive
right
into
mimicking
what
we
did
for
sas
as
a
starting
point
versus
all
this
analysis,
and
I
added
a
link
to
the
doc
near
the
end.
I
think
it's
in
the
right
spot,
but
it's
a
technical
discovery
that
mark
did.
He
evaluated
three.
I
think
separate
javascript
libraries
that
parse
schema
and
I
think
one
summer
and
yaml
summer,
json
schemas,
and
then
it
generates
a
ui,
a
form.
Essentially
from
that.
E
So
there's
a
lot
of
great
analysis
and,
like
I
mentioned,
ultimately,
we
decided
it
was
just
too
complex
and
too
rigid
for
what
we
needed
for
this
project
and
we
might
see
something
similar,
maybe
that
we
have
another
opportunity
here
with
api
fuzzing,
that
it
is
more.
The
data
is
a
different
style
and
like
the
demo
that
mike
provided
showed
us
that,
it's
very
you
know
hierarchical
we're
sas
not
so.
D
Much,
I
think,
for
me
the
drawback
for
doing
a
pure
schema
approach.
Is
you
know
one?
We
don't
really
need
a
pure
schema
approach,
because
the
we
have
very
specific
areas,
we're
going
to
add
where
things
might
change
or
get
extended,
and
it
wouldn't
be
that
new
thing
so
much
as
just
additional
things
we
already
know
and
then
also
the
impact
that
would
have
on
having
a
rich
nice
ui
for
the
user.
A
Cool
okay,
so
in
terms
of
next
steps,
I
think
a
couple
of
things.
One
is
mike
I'd
love
to
get
just
some
screenshots
of
each
of
those
screens,
so
we
can
put
those
together
for
camilla
to
work
on
and
then
neil,
maybe
you
and
I
talked
to
camilla
about
those
screens
and
then
kind
of
what
we're
thinking
of
how
those
would
get
translated
over
into
the
gitlab
interface.
A
A
So
if
that
works
mike
we'll
get
screenshots
and
then
neil
you-
and
I
can
schedule
some
time
with
camellia
to
go
through
that
and
then
maybe
after
after
kind
of
an
initial
design,
we
can
have
a
little
bit
of
a
follow-up
technical
discussion
as
to
what
data
would
go
to
the
front
end.
You
know
if
we're
dynamically,
writing
out
the
checks
and
asserts
just
we
need
to
figure
out.
You
know
if
that's
coming
from
through
graphql
or
static
file
or
figure
out
the
best
way
to
do
that.