1
00:00:00,170 --> 00:00:03,480
Hi and welcome. In this video we're gonna

2
00:00:03,480 --> 00:00:06,210
talk about testing PUT calls. So testing

3
00:00:06,210 --> 00:00:07,649
PUT calls are similar in a lot of ways

4
00:00:07,649 --> 00:00:09,900
to testing a POST call, the difference is

5
00:00:09,900 --> 00:00:11,519
that I PUT calls meant to edit an

6
00:00:11,519 --> 00:00:13,740
existing object, rather than creating a

7
00:00:13,740 --> 00:00:15,540
new one. For example things like what

8
00:00:15,540 --> 00:00:17,340
kinds of data you might try to send, or

9
00:00:17,340 --> 00:00:18,779
how you would authenticate the calls

10
00:00:18,779 --> 00:00:20,760
might be the same between PUT and POST.

11
00:00:20,760 --> 00:00:22,500
But there are a few things that we

12
00:00:22,500 --> 00:00:23,970
should consider that are specific to

13
00:00:23,970 --> 00:00:25,890
doing PUT calls. One of the most

14
00:00:25,890 --> 00:00:27,449
important things is looking at which

15
00:00:27,449 --> 00:00:29,699
fields we are allowed to change. Most

16
00:00:29,699 --> 00:00:31,830
databases have an ID field, for example

17
00:00:31,830 --> 00:00:33,660
that's used as a reference point for

18
00:00:33,660 --> 00:00:35,550
building all queries, and so we often

19
00:00:35,550 --> 00:00:37,469
don't want to be able to change that

20
00:00:37,469 --> 00:00:39,329
once it's been created. Let's take a look

21
00:00:39,329 --> 00:00:41,190
at our sample application and see if we

22
00:00:41,190 --> 00:00:42,390
can understand what we're talking about

23
00:00:42,390 --> 00:00:44,910
here. So we'll take a look again at blog

24
00:00:44,910 --> 00:00:48,059
posts - one, let's send that so we can

25
00:00:48,059 --> 00:00:51,989
get the data, we'll copy this, we'll

26
00:00:51,989 --> 00:00:55,050
change our method here to PUT and we'll

27
00:00:55,050 --> 00:00:59,840
go to the body, again we'll do raw JSON,

28
00:00:59,840 --> 00:01:04,049
put this in here, and you can see we're

29
00:01:04,049 --> 00:01:07,110
posting two blog posts slash one. But

30
00:01:07,110 --> 00:01:08,760
let's try to change the ID, let's change

31
00:01:08,760 --> 00:01:11,250
it to two and see what happens. So when

32
00:01:11,250 --> 00:01:14,369
we post two blog post one is it going to

33
00:01:14,369 --> 00:01:16,950
let us change the ID of that post to be

34
00:01:16,950 --> 00:01:20,369
two? So let's send this and see what

35
00:01:20,369 --> 00:01:24,540
happens. Now if we look down here it did

36
00:01:24,540 --> 00:01:26,700
not modify the ID four, so it just

37
00:01:26,700 --> 00:01:28,409
ignored that, which is good, we don't want

38
00:01:28,409 --> 00:01:31,680
it to allow us to modify the ID. So

39
00:01:31,680 --> 00:01:32,939
that's something we want to check with

40
00:01:32,939 --> 00:01:35,549
POST calls or PUT calls, is to make sure

41
00:01:35,549 --> 00:01:39,780
that when we put data it only lets us

42
00:01:39,780 --> 00:01:42,150
modify the kind of data that we should

43
00:01:42,150 --> 00:01:45,540
be allowed to modify. Another thing that

44
00:01:45,540 --> 00:01:46,680
we might want to consider is how

45
00:01:46,680 --> 00:01:48,810
associated data might change when we

46
00:01:48,810 --> 00:01:50,880
modify an object. Again let's take a look

47
00:01:50,880 --> 00:01:53,100
at an example to understand that. So

48
00:01:53,100 --> 00:01:55,950
let's change this back to GET, and we'll

49
00:01:55,950 --> 00:01:59,430
add a parameter here, so a question mark

50
00:01:59,430 --> 00:02:05,399
underscore embed. And will embed comments

51
00:02:05,399 --> 00:02:09,270
and send that request, and so we can see

52
00:02:09,270 --> 00:02:10,739
that we've got our comments embedded

53
00:02:10,739 --> 00:02:13,979
here in this. But this common

54
00:02:13,979 --> 00:02:16,980
is associated with this blog post. So

55
00:02:16,980 --> 00:02:19,680
what happens if we modify this comment?

56
00:02:19,680 --> 00:02:21,989
So let's copy the body of this, let's

57
00:02:21,989 --> 00:02:29,010
change the URL here to be comments / 1

58
00:02:29,010 --> 00:02:32,510
because the comment ID here is 1, and

59
00:02:32,510 --> 00:02:36,450
we'll put to that, so let's go here and

60
00:02:36,450 --> 00:02:42,420
let's paste in the comment JSON that we

61
00:02:42,420 --> 00:02:45,480
had, ok and then let's change something

62
00:02:45,480 --> 00:02:49,470
here so we'll say changed, so we changed

63
00:02:49,470 --> 00:02:53,610
the text of our comment, and let's go

64
00:02:53,610 --> 00:02:56,760
ahead and send that. So we send that

65
00:02:56,760 --> 00:02:59,400
request, you can see down here everything

66
00:02:59,400 --> 00:03:02,370
went ok, it's changed. But now what

67
00:03:02,370 --> 00:03:07,500
happens if we go back to that request we

68
00:03:07,500 --> 00:03:10,620
had where we embedded the comments under

69
00:03:10,620 --> 00:03:12,989
the blog posts. So we'll do a GET call

70
00:03:12,989 --> 00:03:16,380
here, we'll send that, and we can see that

71
00:03:16,380 --> 00:03:18,780
indeed the embedded comment has changed.

72
00:03:18,780 --> 00:03:20,609
So that's good, that's what we wanted to

73
00:03:20,609 --> 00:03:22,920
see, we wanted to see those changes to

74
00:03:22,920 --> 00:03:26,069
the comment propagate into the blog post

75
00:03:26,069 --> 00:03:29,130
and associated posts as well. And before

76
00:03:29,130 --> 00:03:30,720
we leave this section I'm PUT testing,

77
00:03:30,720 --> 00:03:31,859
let's take a look at just one more

78
00:03:31,859 --> 00:03:33,359
example the kind of things you might

79
00:03:33,359 --> 00:03:35,940
consider when doing this. Now this one's

80
00:03:35,940 --> 00:03:37,920
sort of security related, and although

81
00:03:37,920 --> 00:03:39,810
this course doesn't get into the details

82
00:03:39,810 --> 00:03:42,090
of security testing on an API, there are

83
00:03:42,090 --> 00:03:43,410
some basic things that we can think

84
00:03:43,410 --> 00:03:45,780
about and and could check for. So in this

85
00:03:45,780 --> 00:03:47,940
case what we want to check is what

86
00:03:47,940 --> 00:03:50,519
happens when we try to PUT onto a blog

87
00:03:50,519 --> 00:03:52,440
post that were not authenticated for, or

88
00:03:52,440 --> 00:03:54,120
a comment that we're not entik ated for.

89
00:03:54,120 --> 00:03:57,530
So in this example here I've got a

90
00:03:57,530 --> 00:04:00,599
comment that the current user is not

91
00:04:00,599 --> 00:04:01,709
allowed to see.

92
00:04:01,709 --> 00:04:06,900
So we'll go change this to be comments /

93
00:04:06,900 --> 00:04:12,720
-, and let's do a GET on there, and that

94
00:04:12,720 --> 00:04:15,450
works okay. But now let's try to do a PUT

95
00:04:15,450 --> 00:04:19,700
on it. So we'll change this to be a PUT,

96
00:04:19,700 --> 00:04:26,579
let's take this and we'll put this here,

97
00:04:26,579 --> 00:04:27,690
and let's

98
00:04:27,690 --> 00:04:32,550
try changing this comment. So change it,

99
00:04:32,550 --> 00:04:37,260
and now let's send this request. And if

100
00:04:37,260 --> 00:04:38,780
we scroll down here we're unauthorized,

101
00:04:38,780 --> 00:04:42,030
so we are not allowed to write to this

102
00:04:42,030 --> 00:04:44,070
comment, maybe it was put there by

103
00:04:44,070 --> 00:04:46,380
someone else and as this user we're not

104
00:04:46,380 --> 00:04:48,420
allowed to write to it. Now this seems

105
00:04:48,420 --> 00:04:50,490
good right, we got back a 401

106
00:04:50,490 --> 00:04:54,450
unauthorized status, makes sense. But this

107
00:04:54,450 --> 00:04:56,700
is actually a very minor security flaw,

108
00:04:56,700 --> 00:04:59,250
by returning a 401 we've actually given

109
00:04:59,250 --> 00:05:00,870
the user some information about the

110
00:05:00,870 --> 00:05:03,030
system that they might not need to know.

111
00:05:03,030 --> 00:05:05,190
So we've told them that this resource

112
00:05:05,190 --> 00:05:07,530
exists. Now if you're a bad actor trying

113
00:05:07,530 --> 00:05:09,000
to figure out some way to get into the

114
00:05:09,000 --> 00:05:10,770
system that can be valuable information.

115
00:05:10,770 --> 00:05:13,170
In this particular context is probably

116
00:05:13,170 --> 00:05:15,450
not a big deal, but in some systems you

117
00:05:15,450 --> 00:05:17,550
want to be careful that you're not

118
00:05:17,550 --> 00:05:19,470
telling people that certain resources

119
00:05:19,470 --> 00:05:21,830
exist by giving back this unauthorized.

120
00:05:21,830 --> 00:05:24,500
Instead if someone is not allowed to

121
00:05:24,500 --> 00:05:27,360
perform that action, it's usually better

122
00:05:27,360 --> 00:05:30,300
to return a 404 or object doesn't exist

123
00:05:30,300 --> 00:05:34,169
error. It's strictly speaking not the

124
00:05:34,169 --> 00:05:35,820
right error, but from a security

125
00:05:35,820 --> 00:05:38,520
perspective it makes more sense. And as

126
00:05:38,520 --> 00:05:39,810
always there's a lot to learn and

127
00:05:39,810 --> 00:05:41,550
explore in this area, but we'll wrap it

128
00:05:41,550 --> 00:05:42,480
up here for now.

129
00:05:42,480 --> 00:05:44,490
So feel free to keep exploring, trying

130
00:05:44,490 --> 00:05:46,500
out new things, build out your own set of

131
00:05:46,500 --> 00:05:49,230
testing ideas for PUT requests. In the

132
00:05:49,230 --> 00:05:51,570
next video we'll dig into testing DELETE

133
00:05:51,570 --> 00:05:53,220
calls, and we'll take a look at those,

134
00:05:53,220 --> 00:05:58,220
hope to see you there.