1
00:00:01,080 --> 00:00:03,000
Speaker 1: How'd you like to listen to dot net rocks with

2
00:00:03,040 --> 00:00:07,879
no ads? Easy? Become a patron for just five dollars

3
00:00:07,919 --> 00:00:10,800
a month. You get access to a private RSS feed

4
00:00:10,839 --> 00:00:14,240
where all the shows have no ads. Twenty dollars a month,

5
00:00:14,279 --> 00:00:16,879
we'll get you that and a special dot net Rocks

6
00:00:16,960 --> 00:00:21,000
patron mug. Sign up now at Patreon dot dot NetRocks

7
00:00:21,120 --> 00:00:36,640
dot com. Hey, it's dot net rocks one more time.

8
00:00:36,840 --> 00:00:39,960
I'm Carl Franklin, an amateur camp and man, we are

9
00:00:40,000 --> 00:00:42,240
getting ready to go to build, aren't we getting there? Yeah?

10
00:00:42,320 --> 00:00:43,799
Now that's just about that time.

11
00:00:44,600 --> 00:00:46,439
Speaker 2: There's a lot of you know, for me, I'm organizing

12
00:00:46,640 --> 00:00:50,520
a dozen podcasters so right, and a bunch of different teams.

13
00:00:50,679 --> 00:00:52,799
Speaker 1: So it's an adventure. This is something that we did

14
00:00:52,799 --> 00:00:54,640
in the past together and then you sort of just

15
00:00:54,679 --> 00:00:59,119
took it over, which is fine because you've got all

16
00:00:59,200 --> 00:01:02,399
of the podcasts wrangled from not just dot net, right,

17
00:01:02,520 --> 00:01:05,640
and not just Microsoft, yeah, specifically not just dot net. Yeah.

18
00:01:05,680 --> 00:01:08,480
Speaker 2: We got a bunch of YouTubers well coming out this time,

19
00:01:08,519 --> 00:01:10,359
Tim Corey, who has been on the show not.

20
00:01:10,280 --> 00:01:11,239
Speaker 1: In a long time anyway.

21
00:01:11,439 --> 00:01:14,040
Speaker 2: I love Tim Corey and Derek co Martin, which we

22
00:01:14,079 --> 00:01:16,480
had on recently coming as well. We got one video

23
00:01:17,040 --> 00:01:19,799
studio as well as a few audios do. Yeah, very cool.

24
00:01:20,680 --> 00:01:23,760
So here's the deal, listeners. If you are going to

25
00:01:23,799 --> 00:01:25,120
be at build, find us.

26
00:01:25,280 --> 00:01:27,920
Speaker 1: Yeah. Do you have any idea physically where we're going

27
00:01:28,000 --> 00:01:28,120
to be.

28
00:01:28,200 --> 00:01:30,719
Speaker 2: Yeah, we're on the fourth floor, okay, which is the

29
00:01:30,799 --> 00:01:33,359
community area. We're off on one side there. You'll find

30
00:01:33,400 --> 00:01:34,319
us easy enough. We're there.

31
00:01:34,400 --> 00:01:36,519
Speaker 1: Yeah, stop in and say hi. Yep. All right, let's

32
00:01:36,560 --> 00:01:47,480
get busy with better know a framework. Awesome? All right,

33
00:01:47,680 --> 00:01:50,840
what do you got? So? I'm having a lot of

34
00:01:50,879 --> 00:01:55,560
fun with a sister podcast Security this week, which is myself,

35
00:01:55,599 --> 00:01:57,799
Patrick Hines and Dwayne Laflatte. And if you don't know

36
00:01:57,799 --> 00:02:01,120
who these guys are, Patrick Hines was actually our first guests.

37
00:02:01,480 --> 00:02:03,959
Speaker 2: Well he's now our lucky charm, right, he's the first

38
00:02:03,959 --> 00:02:06,480
guest on all shows we make it seems that's right.

39
00:02:06,519 --> 00:02:08,520
Speaker 1: He was your first guest on run As and I

40
00:02:08,560 --> 00:02:10,960
think he was the first guest on Mondays too. I'm

41
00:02:10,960 --> 00:02:15,000
not sure, but anyway, Patrick is a veteran and a

42
00:02:15,039 --> 00:02:20,599
security expert, and Dwayne is his Red team leader. They

43
00:02:20,599 --> 00:02:26,319
basically do penetration tests for customers. You know, customer says

44
00:02:26,319 --> 00:02:28,840
go ahead, try to hack us and you know, try

45
00:02:28,840 --> 00:02:32,960
to be all clever, and Dwayne was like, okay, done.

46
00:02:33,560 --> 00:02:37,879
So it's just and here's the thing about Security this Week,

47
00:02:37,919 --> 00:02:40,560
which is just the podcast name and Security this Week

48
00:02:40,639 --> 00:02:44,840
dot Com is the page we laugh far more than

49
00:02:44,919 --> 00:02:48,520
we should be laughing while talking about hacks that have

50
00:02:48,599 --> 00:02:51,439
happened at the end of the universe. Yeah, because what

51
00:02:51,479 --> 00:02:55,039
we're talking about is fundamentally scary, you know. Yeah. Sure,

52
00:02:55,319 --> 00:02:58,319
security can be very frightening. Yeah, if you think your

53
00:02:58,360 --> 00:03:03,159
passwords are safe. Mmm. So we have, you know, a

54
00:03:03,199 --> 00:03:05,919
lot of mantras that we say over and over again,

55
00:03:06,000 --> 00:03:09,039
like use a password manager and patch and update your

56
00:03:09,039 --> 00:03:12,319
firmware on your Wi Fi, you know thing whatever all

57
00:03:12,360 --> 00:03:14,919
the time. But I just wanted to mention we also

58
00:03:15,000 --> 00:03:17,400
have a Discord server and it's getting a lot of

59
00:03:17,439 --> 00:03:23,840
traction and we're even handing out swag which are lock

60
00:03:23,919 --> 00:03:27,120
pick sets. Oh yeah, with the Security this Week logo

61
00:03:27,240 --> 00:03:30,479
on them lock pick sets. Yeah. So, so if you

62
00:03:30,520 --> 00:03:33,840
go to Discord dot Security this Week dot com and

63
00:03:33,919 --> 00:03:37,199
don't put hddps in front of it or because it's

64
00:03:37,240 --> 00:03:42,439
a URL DNS router, so just go on your browser

65
00:03:42,520 --> 00:03:45,319
type Discord dot Security this week dot com. You'll get

66
00:03:45,319 --> 00:03:48,039
to our discord server and if you, you know, engage

67
00:03:48,080 --> 00:03:50,039
us and give us some things to think about, we'll

68
00:03:50,039 --> 00:03:52,520
send you a lock pick set cool and that's my

69
00:03:52,639 --> 00:03:54,680
better no framework, that's what you get. Who's talking to

70
00:03:54,719 --> 00:03:56,960
us today? Richard Grab a comment off for show nineteen

71
00:03:57,080 --> 00:03:58,879
forty eight. This is the one which is just a

72
00:03:58,919 --> 00:04:01,639
couple of weeks ago with Rob talking about his open

73
00:04:01,719 --> 00:04:06,319
source maintenance fee and Jimmy Scott had this comment back.

74
00:04:06,360 --> 00:04:07,520
He said, thanks for your time. Rob.

75
00:04:07,560 --> 00:04:10,000
Speaker 2: We are users of wis, which is a product that

76
00:04:10,520 --> 00:04:13,280
Rob maintains, and I was concerned that wicks was going commercial.

77
00:04:13,560 --> 00:04:17,079
Like many others, we use numerous OS projects and I've

78
00:04:17,079 --> 00:04:18,759
suscribed to several of them. The fee is more than

79
00:04:18,800 --> 00:04:21,079
reasonable and we will be subscribing today.

80
00:04:21,160 --> 00:04:21,560
Speaker 1: Awesome.

81
00:04:21,639 --> 00:04:24,240
Speaker 2: Yeah, it was great, great news, and I was very

82
00:04:24,480 --> 00:04:27,680
you know, we've been battling with this problem talking about

83
00:04:27,879 --> 00:04:29,839
how we're going to create sustainable open source on it

84
00:04:29,920 --> 00:04:33,600
for years now. So yeah, Rob's approach, you know, and

85
00:04:33,920 --> 00:04:36,519
again I appreciate it. He's not just postulating. He set

86
00:04:36,560 --> 00:04:38,040
it up. He set it up how to do it

87
00:04:38,040 --> 00:04:40,000
through githubs so you can learn everything you need to

88
00:04:40,040 --> 00:04:42,720
do about it, and clearly Jimmy's taking advantage that. So Jimmy,

89
00:04:43,240 --> 00:04:44,800
thank you so much for your comment. And a copy

90
00:04:44,839 --> 00:04:46,360
of music Goby is on its way to you. And

91
00:04:46,360 --> 00:04:47,839
if you'd like a copy of music Go Buy, I

92
00:04:47,879 --> 00:04:50,319
write a comment on the website dot NetRocks dot com

93
00:04:50,399 --> 00:04:52,000
or on the facebooks. We publish every show there and

94
00:04:52,040 --> 00:04:53,720
if you comment there and a reading the show will

95
00:04:53,759 --> 00:04:54,959
send you copy Music to Go Buy.

96
00:04:55,079 --> 00:04:58,160
Speaker 1: Yeah, And I just wanted to say I'm standing by

97
00:04:58,360 --> 00:05:01,079
sort of watching how it unfolds with other people other

98
00:05:01,160 --> 00:05:03,079
than Rob and this guy or through the only two

99
00:05:03,120 --> 00:05:06,160
people that I know who are using is systems. So

100
00:05:06,199 --> 00:05:08,480
but I plan on jumping in as soon as I

101
00:05:08,519 --> 00:05:15,160
see happy customers. So also a reminder that Music to

102
00:05:15,240 --> 00:05:18,480
Code By is still going strong with twenty two tracks

103
00:05:18,720 --> 00:05:20,879
and you can download the whole collection in MP three

104
00:05:21,000 --> 00:05:24,720
flak or wave at music tocode by dot net. Awesome. Yeah,

105
00:05:24,759 --> 00:05:26,879
and with that, do you want to do the history thing?

106
00:05:27,000 --> 00:05:29,560
Are we done with it? Oh? That's a great idea.

107
00:05:29,680 --> 00:05:32,680
I didn't. I didn't have time to assemble anything. But

108
00:05:32,839 --> 00:05:35,199
it's nineteen fifty. I mean, what can we say, yes

109
00:05:35,240 --> 00:05:37,920
besides el Wells or beginning of the Korean War.

110
00:05:38,920 --> 00:05:42,360
Speaker 2: Oh that that would be one.

111
00:05:42,519 --> 00:05:45,800
Speaker 1: There was that, yeah, yeah, okay.

112
00:05:46,040 --> 00:05:48,839
Speaker 2: But also the very first credit card, the Diner's Card,

113
00:05:49,000 --> 00:05:52,839
no kidding, is nineteen fifty yeah, I said, sort of famous.

114
00:05:53,120 --> 00:05:55,600
It's it's not an apocryphal story, but it's supposed to

115
00:05:55,639 --> 00:05:58,800
be true that Frank McNamara. It was this sales guy

116
00:06:00,079 --> 00:06:03,120
got his wallet in a different suit, took out his clients,

117
00:06:03,480 --> 00:06:06,000
and his wife had to pay. He didn't have any

118
00:06:06,000 --> 00:06:07,879
money on him, and thought, well, it's got to be

119
00:06:07,920 --> 00:06:10,720
a better way and work with a group of folks,

120
00:06:10,720 --> 00:06:14,199
including Alfred Bloomingdale, who was the heir to the Bloomingdale

121
00:06:14,399 --> 00:06:17,560
d department store. So got it into Bloomingdale's right away

122
00:06:17,600 --> 00:06:19,279
and it kicked that whole thing off. Of course, the

123
00:06:19,319 --> 00:06:21,920
big card, what became Visa, comes along later in nineteen

124
00:06:21,920 --> 00:06:22,439
towty eight.

125
00:06:23,120 --> 00:06:24,959
Speaker 1: So did you say it was the diners Club.

126
00:06:25,360 --> 00:06:27,079
Speaker 2: That's what became Diner's Club, but at the time it

127
00:06:27,120 --> 00:06:27,959
was called Diner's Card.

128
00:06:28,040 --> 00:06:28,879
Speaker 1: The Diner's Card.

129
00:06:29,079 --> 00:06:32,199
Speaker 2: Interesting, and it was again focused on restaurants initially, although

130
00:06:32,480 --> 00:06:33,920
rapidly branched into retail.

131
00:06:34,040 --> 00:06:36,839
Speaker 1: So you know, we're getting out of like the war

132
00:06:36,959 --> 00:06:39,439
as well, we're getting into via the not the Vietnam,

133
00:06:39,519 --> 00:06:43,480
the Korean War, but and more interesting things are happening

134
00:06:43,480 --> 00:06:47,600
in compute around this time. Do you have any computer

135
00:06:48,079 --> 00:06:49,360
kind of history.

136
00:06:49,480 --> 00:06:51,399
Speaker 2: The only comput story that's like a lot of things

137
00:06:51,439 --> 00:06:53,319
will happen in the fifties but in fifty is not

138
00:06:53,680 --> 00:06:56,800
a bunch except that at the Canadian World Exposition in

139
00:06:56,920 --> 00:07:00,839
nineteen fifty they had a computer they called Birdie the

140
00:07:01,040 --> 00:07:04,759
Brain and it played tic tac toe. Wow, And apparently

141
00:07:04,800 --> 00:07:07,040
there was huge cues of people to play tic tac

142
00:07:07,160 --> 00:07:09,480
toe against Berdie the Brain.

143
00:07:09,839 --> 00:07:13,480
Speaker 1: Wow. That's cool. Silly but yeah, no, that was silly

144
00:07:13,480 --> 00:07:13,920
but cool.

145
00:07:14,040 --> 00:07:16,319
Speaker 2: And you know that all the write ups talk about

146
00:07:16,360 --> 00:07:19,199
it being artificial intelligence, but none of the stuff at

147
00:07:19,240 --> 00:07:22,759
the time called it artificial intelligence. Yeah, which is Bertie

148
00:07:22,759 --> 00:07:27,319
the Brain. They just called it tic tac toe. Okay,

149
00:07:27,480 --> 00:07:31,399
So with that, I'm going to introduce Erwin. Erwin van

150
00:07:31,399 --> 00:07:34,639
der Walk is an experienced software engineer with the passion

151
00:07:34,720 --> 00:07:39,879
for software design, development practices and web security. He works

152
00:07:39,879 --> 00:07:42,360
as a principal engineer at Dwende Software and is the

153
00:07:42,399 --> 00:07:46,199
product owner for the Dwende BFF That's not Best Friends Forever,

154
00:07:46,319 --> 00:07:49,839
That's back in for front End Security Library and the

155
00:07:49,879 --> 00:07:54,360
popular open source library dwende access token management. In his

156
00:07:54,399 --> 00:07:56,639
spare time, he tries to learn as much as possible

157
00:07:56,680 --> 00:08:00,560
about pretty much anything and everything tech, science, history, and

158
00:08:00,600 --> 00:08:06,360
all things metal, listening, playing guitar, and fighting with historically

159
00:08:06,519 --> 00:08:08,360
accurate long's words.

160
00:08:08,560 --> 00:08:09,759
Speaker 1: Well there's a hobby for you.

161
00:08:09,959 --> 00:08:10,160
Speaker 3: Yeah.

162
00:08:10,279 --> 00:08:14,120
Speaker 1: I don't even know what that means, but uh, welcome, Irwin.

163
00:08:14,199 --> 00:08:18,639
I recently learned what dwen day is. Like, I'm not

164
00:08:18,720 --> 00:08:24,199
the company, but the word. It's a Spanish word that means,

165
00:08:24,920 --> 00:08:28,560
you know, it's sort of what do they what do

166
00:08:28,600 --> 00:08:30,439
they call it? It's it's it's sort of a way

167
00:08:30,480 --> 00:08:33,879
of life, right day. You would call something dwende if

168
00:08:33,919 --> 00:08:39,559
it's amazing, if it's awesome, Yeah, that's the idea. Yeah,

169
00:08:39,600 --> 00:08:41,440
so welcome, Well, thank you very much.

170
00:08:41,480 --> 00:08:43,200
Speaker 3: I'm super excited to be on the show. A long

171
00:08:43,240 --> 00:08:44,080
time listener, so.

172
00:08:44,600 --> 00:08:49,799
Speaker 1: Yeah, we're super excited to have you BFF. Back End

173
00:08:49,879 --> 00:08:53,759
for front end. Yeah, and why why is it back

174
00:08:53,879 --> 00:08:55,679
end for front end and not just back end?

175
00:08:55,919 --> 00:08:59,519
Speaker 3: Well, they call it back and for front end because

176
00:09:00,960 --> 00:09:04,879
tied to a particular front end, you have to have

177
00:09:05,440 --> 00:09:08,320
one back end if you have a micro services or

178
00:09:08,399 --> 00:09:11,240
just an appropriately sized services architecture, behind it. You can

179
00:09:11,279 --> 00:09:13,759
have many services behind your front end, but in this

180
00:09:13,799 --> 00:09:16,360
particular case, you only have one back end for that

181
00:09:16,399 --> 00:09:19,799
front end. And you know, the back end for front

182
00:09:19,879 --> 00:09:23,440
end pattern itself has been also around for quite a

183
00:09:23,440 --> 00:09:26,639
long time, and in this particular case, we're explicitly talking

184
00:09:26,679 --> 00:09:29,480
about adding the security layer on top of that. That's

185
00:09:29,519 --> 00:09:33,559
also how the if the Internet Engineering Task Force defined

186
00:09:33,600 --> 00:09:37,960
it now, but originally it was just if you have

187
00:09:38,080 --> 00:09:41,000
multiple different types of front ends, maybe a mobile, maybe

188
00:09:41,039 --> 00:09:44,000
a web application, you would build a specific back end

189
00:09:44,120 --> 00:09:47,639
for that one front end. And in this particular case,

190
00:09:48,000 --> 00:09:51,480
it's kind of similar, but you have a back end

191
00:09:51,840 --> 00:09:54,519
for a particular front end, but also to provide it

192
00:09:54,639 --> 00:09:56,240
with the authentication services.

193
00:09:56,600 --> 00:10:00,320
Speaker 1: So with MVC fall into that category, and MVC server

194
00:10:00,480 --> 00:10:03,639
because if you think about it, it's serving up hdmun

195
00:10:03,879 --> 00:10:06,240
JavaScript and front end stuff.

196
00:10:06,480 --> 00:10:09,279
Speaker 3: I think the primary goal is to look at what

197
00:10:09,360 --> 00:10:11,679
we call browser based application. So it's a little bit

198
00:10:11,720 --> 00:10:16,480
more like you know, spas applications built with React Angular Blazer,

199
00:10:16,559 --> 00:10:19,679
those type of applications that live primarily in the browser.

200
00:10:20,240 --> 00:10:25,000
They don't necessarily need a one single backhand for them.

201
00:10:25,039 --> 00:10:26,919
I mean, they could use any types of back ends,

202
00:10:27,240 --> 00:10:31,120
but in this particular case, and yeah, maybe it's good

203
00:10:31,120 --> 00:10:33,399
to dive into why we need that thing in the

204
00:10:33,440 --> 00:10:37,759
first place. It is to prevent you from using access

205
00:10:37,799 --> 00:10:40,279
tokens in the browser. Now why would you want that,

206
00:10:40,360 --> 00:10:42,600
Because for a long time, using access tokens in the

207
00:10:42,639 --> 00:10:45,480
browser has been a recommended practice. Right, There's all these

208
00:10:45,480 --> 00:10:49,279
libraries that are out there to handle those in JavaScript.

209
00:10:50,600 --> 00:10:54,600
And that's because the field of security is constantly evolving, right.

210
00:10:54,879 --> 00:10:57,399
I mean, things that were just completely valid in the

211
00:10:57,440 --> 00:11:02,360
past of implicit grand flow for example, is now totally

212
00:11:02,399 --> 00:11:07,519
not recommended anymore because you know, just clear security vulnerabilities

213
00:11:07,559 --> 00:11:08,440
have been discovered in.

214
00:11:08,559 --> 00:11:13,440
Speaker 1: Yeah, you're increasing the surface, the attack surface by allowing

215
00:11:13,960 --> 00:11:17,000
hackers to get in there and mess with the tokens

216
00:11:17,039 --> 00:11:19,279
and try to spoof your back end and all of that,

217
00:11:19,360 --> 00:11:20,600
all the things that hackers do.

218
00:11:21,000 --> 00:11:24,840
Speaker 3: Absolutely And there's the problem, right because within a browser

219
00:11:24,879 --> 00:11:28,759
based application, all the code for that one application is

220
00:11:28,799 --> 00:11:32,080
just mashed together in the same sandbox this week. So

221
00:11:32,159 --> 00:11:35,039
if a hacker is able to inject code in there,

222
00:11:35,240 --> 00:11:38,879
and unfortunately they do. Injection attacks are still the opity

223
00:11:39,159 --> 00:11:44,559
top three absolutely issue. It just happens a lot. Then

224
00:11:45,039 --> 00:11:47,759
an attacker can do exactly what your application is able

225
00:11:47,799 --> 00:11:51,240
to do as well. Now, if that is just impersonating

226
00:11:51,240 --> 00:11:54,679
you while you have your browser online, that's already a problem.

227
00:11:54,759 --> 00:11:56,960
And sure there are ways that you can limit the

228
00:11:57,000 --> 00:12:00,000
attack surface. Then, but if the attacker is able to

229
00:12:00,759 --> 00:12:03,639
take an access token and take that offline, even when

230
00:12:03,679 --> 00:12:06,320
you close down your browser, he's still able to impersonate you,

231
00:12:06,799 --> 00:12:09,480
or even worse right, take what we call a refresh

232
00:12:09,519 --> 00:12:12,320
token and be able to get more and more access

233
00:12:12,360 --> 00:12:14,960
tokens all the time, then you really have a problem

234
00:12:15,360 --> 00:12:16,080
if that happens.

235
00:12:17,039 --> 00:12:19,879
Speaker 1: But these things are require like a sort of a

236
00:12:19,919 --> 00:12:22,960
man in the middle attack, right, This isn't something that

237
00:12:23,000 --> 00:12:25,279
you're going to pick up some malware and somebody's going

238
00:12:25,360 --> 00:12:27,679
to steal your tokens and whatever. Somebody has to really

239
00:12:27,679 --> 00:12:28,639
target you, don't they.

240
00:12:28,840 --> 00:12:32,200
Speaker 3: Well, it is so easy to make a small mistake

241
00:12:32,559 --> 00:12:35,679
while building your web application that opens you up to

242
00:12:35,960 --> 00:12:40,480
cross side scripting attacks. Yeah, I myself not too long

243
00:12:40,519 --> 00:12:44,519
ago found out that if you have a URL and

244
00:12:44,559 --> 00:12:47,799
you add that URL into an image tag all of us,

245
00:12:47,840 --> 00:12:51,919
and that URL comes from another source, that URL could

246
00:12:52,000 --> 00:12:55,799
contain script and that will immediately be executed. So immediately

247
00:12:55,919 --> 00:12:59,279
that turns it into a cross side scripting attack. I

248
00:12:59,320 --> 00:13:02,639
didn't know that, and the library at the time React

249
00:13:03,120 --> 00:13:06,399
doesn't handle that particular case. It does when you bind

250
00:13:06,879 --> 00:13:10,720
a textbox to some data, but it doesn't handle that

251
00:13:10,759 --> 00:13:11,639
particular problem.

252
00:13:11,759 --> 00:13:13,919
Speaker 1: So so you're saying that I could have you know,

253
00:13:14,480 --> 00:13:21,000
IMG source equals HTDP Joe's discount, sharkcages dot com, slashcage

254
00:13:21,000 --> 00:13:26,039
one dot jpeg, and that jpeg could no a jpeg

255
00:13:26,080 --> 00:13:28,480
could contain a script or is it more like a

256
00:13:28,600 --> 00:13:33,879
script tag that loads a JavaScript file from some other site.

257
00:13:33,919 --> 00:13:38,600
Speaker 3: This particular example is a URL that contains script itself.

258
00:13:38,600 --> 00:13:40,559
So it's not necessarily even a URL. It doesn't even

259
00:13:40,600 --> 00:13:45,000
start with htps or something, but it just contains script.

260
00:13:45,080 --> 00:13:47,000
And if you put that into an image tag, it

261
00:13:47,039 --> 00:13:49,120
gets executed and you have a vulnerability.

262
00:13:49,200 --> 00:13:51,080
Speaker 1: Oh if you put it into an image to ic.

263
00:13:51,440 --> 00:13:53,240
So if you set the source for an image tag

264
00:13:53,279 --> 00:13:55,840
to a script file, the script is going to get executed.

265
00:13:56,039 --> 00:13:59,679
Speaker 3: Yes, And this is just one tiny example. I mean,

266
00:14:00,120 --> 00:14:03,600
when you build a browser based application using React or something,

267
00:14:03,840 --> 00:14:06,759
you get a million node files. How do you know

268
00:14:06,840 --> 00:14:09,240
that not one of those tiny node files has a problem.

269
00:14:09,480 --> 00:14:12,080
Speaker 2: I wish you were exaggerating that it was a million

270
00:14:12,159 --> 00:14:15,279
node files, because you're right, so it's so many.

271
00:14:16,159 --> 00:14:18,679
Speaker 3: So here's the point, right, I mean, if you do

272
00:14:18,799 --> 00:14:23,360
everything perfect, then doing what we call public client public

273
00:14:23,440 --> 00:14:29,120
client authorization code flow works and it's secure. But as

274
00:14:29,120 --> 00:14:32,360
soon as you have a tiny little hole in your

275
00:14:32,360 --> 00:14:36,360
browser based security, then what you want to do is

276
00:14:37,000 --> 00:14:39,960
put layers in there. Security is all about adding more

277
00:14:40,039 --> 00:14:43,840
layers and reducing the blast radius if something goes wrong.

278
00:14:43,960 --> 00:14:45,799
Speaker 1: Right, and before you go down that rabbit hole, let

279
00:14:45,879 --> 00:14:48,200
me just say that it's not just a mistake that

280
00:14:48,240 --> 00:14:51,759
you could make. But in your software bill of materials,

281
00:14:51,759 --> 00:14:56,480
which you have right everybody listening, yes, all right, that

282
00:14:56,679 --> 00:14:59,600
is all of the dependencies that you are taking on

283
00:14:59,759 --> 00:15:03,120
in that list, and that list, as Richard said, could

284
00:15:03,159 --> 00:15:08,720
be millions of JavaScript files down the line. And there's

285
00:15:08,720 --> 00:15:11,720
been examples of these where we've depended on a particular

286
00:15:11,759 --> 00:15:15,279
JavaScript library and that library contained a bug and everything crashed.

287
00:15:16,120 --> 00:15:18,759
You're depending on those things, and how are you going

288
00:15:18,840 --> 00:15:23,480
to know if somebody gets in there maliciously does a

289
00:15:23,519 --> 00:15:27,320
pull request and approves it and absolutely Bob's your uncle,

290
00:15:27,559 --> 00:15:28,559
and you won't know.

291
00:15:28,759 --> 00:15:31,840
Speaker 3: Exactly so, and it doesn't even have to be that right,

292
00:15:32,120 --> 00:15:34,799
script injection attacks is just one of the vectors. I mean,

293
00:15:34,840 --> 00:15:37,600
not too long ago, we had Spector. Right, Spector was

294
00:15:37,639 --> 00:15:41,600
a processor based issue. There's a proof of concept that.

295
00:15:41,799 --> 00:15:45,399
Speaker 1: It was a vulnerability in the micro code of Intel processors.

296
00:15:45,639 --> 00:15:48,639
Speaker 3: Exactly. There was a proof of concept out there that

297
00:15:48,759 --> 00:15:53,320
proved that by somehow from one browser window to another

298
00:15:53,360 --> 00:15:56,519
browser window, they could find poke into the memory of

299
00:15:56,639 --> 00:15:59,279
the other browser window. Now that's scary as well, right,

300
00:16:00,000 --> 00:16:02,480
I mean, the point that I'm making is that you

301
00:16:02,600 --> 00:16:05,759
have code running that you know, comes from all kinds

302
00:16:05,759 --> 00:16:10,000
of sources, maybe even you know, add links or whatever. Right,

303
00:16:10,039 --> 00:16:13,679
it comes from all kinds of sources, just execute together,

304
00:16:13,879 --> 00:16:16,600
and anything that that code does, it will you know

305
00:16:17,120 --> 00:16:19,360
that the code can do, you know it might do.

306
00:16:19,720 --> 00:16:24,360
And that's that's a problem. So the BFF pattern comes

307
00:16:24,360 --> 00:16:27,159
in to try and help that. Now, like I mentioned,

308
00:16:27,240 --> 00:16:30,919
the i ETF Enginet Engineering Task Force. That's the group

309
00:16:30,960 --> 00:16:33,480
that's responsible for creating all of these standards in the

310
00:16:33,480 --> 00:16:37,360
first place. Right, they created the OALTH to specification, open

311
00:16:37,360 --> 00:16:41,000
and deconnect all of that, and every now and then

312
00:16:41,080 --> 00:16:43,919
they come out with what they call a best current

313
00:16:43,960 --> 00:16:47,240
Practice document and in there they try to document well,

314
00:16:47,279 --> 00:16:49,759
you know, looking at the landscape, looking at what we

315
00:16:49,799 --> 00:16:53,320
know right now, what is what do we recommend and

316
00:16:53,360 --> 00:16:55,480
what don't we recommend. And one of the things that

317
00:16:55,480 --> 00:16:59,440
they're recommending is to use the BFF pattern. If you

318
00:16:59,519 --> 00:17:02,159
look at it, the BFF pattern consists of a couple

319
00:17:02,240 --> 00:17:05,720
of things. The first thing really important is that the

320
00:17:05,759 --> 00:17:09,880
authentication needs to happen on the server. So in the

321
00:17:09,880 --> 00:17:12,279
server you have what we call a confidential client, and

322
00:17:12,319 --> 00:17:15,759
the confidential client handles all of the authentication with your

323
00:17:16,000 --> 00:17:20,480
identity provider. Now the browser is still involved, but not

324
00:17:20,599 --> 00:17:25,319
the browser based application. It's not the JavaScript based So

325
00:17:25,400 --> 00:17:28,400
all that the front end has to do is redirect

326
00:17:28,480 --> 00:17:31,240
to a log in page or the logout page, and

327
00:17:32,359 --> 00:17:37,039
the server then takes care of the rest. After the

328
00:17:37,079 --> 00:17:41,079
authentication has completed. What the server then does is it

329
00:17:41,119 --> 00:17:44,079
places a cookie on your machine. Now, cookies have a

330
00:17:44,079 --> 00:17:47,039
bit of a bad rep for privacy reasons, of course,

331
00:17:47,359 --> 00:17:52,200
but also you know, for a cross side request forgery attacks,

332
00:17:52,440 --> 00:17:54,000
and we might get into those in a little bit

333
00:17:54,000 --> 00:17:56,839
in a minute, but they're very easily to protect you

334
00:17:56,920 --> 00:18:01,240
against those actually pretty much. Yeah, but cookies have been

335
00:18:01,279 --> 00:18:03,680
around for a long time and actually they you know,

336
00:18:04,480 --> 00:18:07,640
when you apply them properly. They're actually really secure. Sure,

337
00:18:08,039 --> 00:18:11,000
so what happens if you set your cookie to HTTP only.

338
00:18:11,480 --> 00:18:14,319
That means that your JavaScript can't reach them, and they're

339
00:18:14,359 --> 00:18:18,279
just added by the browser implicitly. Now, you can also

340
00:18:18,400 --> 00:18:21,160
set some policies on there, like same site policies, maybe

341
00:18:21,200 --> 00:18:24,319
even underscore underscore host prefix. It's a little bit technical,

342
00:18:24,400 --> 00:18:26,839
but all these flags that you can turn onto your

343
00:18:26,839 --> 00:18:30,200
cookies so that it's more difficult for attackers to to

344
00:18:31,119 --> 00:18:33,200
you know, accidentally get access to those things.

345
00:18:33,519 --> 00:18:35,079
Speaker 1: Got to keep the cookie monster away.

346
00:18:35,519 --> 00:18:39,160
Speaker 3: Yeah, but then once you've once you've configured those cookies correctly,

347
00:18:39,440 --> 00:18:42,559
the authentication just happens. Any call that you make to

348
00:18:42,680 --> 00:18:47,119
your backhand service is just authenticated automatically in a simple

349
00:18:47,240 --> 00:18:50,480
application what you just mentioned, right, just an MVC application,

350
00:18:50,519 --> 00:18:54,319
but then maybe one that exposes APIs the authentication just flows.

351
00:18:54,720 --> 00:18:59,240
Everything's fine, But now if you want to access external services,

352
00:18:59,720 --> 00:19:02,599
you know, micro services that you have running somewhere else,

353
00:19:03,000 --> 00:19:05,319
you don't want the cookie to flow over there because

354
00:19:05,319 --> 00:19:09,559
it can't read those cookies, can't do anything with them there.

355
00:19:09,079 --> 00:19:13,759
Speaker 1: So you need some federated kind of multiple server communication

356
00:19:13,920 --> 00:19:14,240
going on.

357
00:19:14,400 --> 00:19:17,160
Speaker 3: Right, Yeah, Well, what you then do is you exchange

358
00:19:17,279 --> 00:19:20,000
the cookie for an access token, and from that point

359
00:19:20,039 --> 00:19:24,880
on you just have a request from the BFF to

360
00:19:24,960 --> 00:19:28,079
your API using access tokens. And that's just a very

361
00:19:28,119 --> 00:19:32,880
well known pattern to flow, just credentials and information and

362
00:19:33,119 --> 00:19:38,319
security context. Yeah, okay, that is pretty much it. I mean,

363
00:19:38,359 --> 00:19:39,920
there's more that you can add to that.

364
00:19:40,279 --> 00:19:42,720
Speaker 1: But so the access tokens are kind of made up

365
00:19:42,720 --> 00:19:47,160
on the fly, whereas the cookie identifies you to your server. Yeah,

366
00:19:47,200 --> 00:19:50,359
but when you say exchange, you mean, hey, this is

367
00:19:50,440 --> 00:19:52,359
me because I have this cookie, you know who I am.

368
00:19:52,480 --> 00:19:54,720
Give me an authentication token that I can use over

369
00:19:54,759 --> 00:19:55,440
in this API.

370
00:19:55,599 --> 00:19:58,400
Speaker 3: Yes, yeah, and you can still have the choice. I mean,

371
00:19:58,440 --> 00:20:02,079
some APIs they don't want what we call a user

372
00:20:02,119 --> 00:20:04,799
based a token, right, They just want to have a

373
00:20:04,839 --> 00:20:08,079
client credentials token and that's it. You might want to

374
00:20:08,079 --> 00:20:11,279
have a token that's very narrow for that one particular service,

375
00:20:11,839 --> 00:20:14,680
because you might want to have multiple tokens for different services,

376
00:20:14,960 --> 00:20:17,720
and some other service might actually want to have a

377
00:20:17,799 --> 00:20:20,200
token with the subject identifier in it and all kinds

378
00:20:20,240 --> 00:20:21,480
of claims in there as well.

379
00:20:21,960 --> 00:20:27,200
Speaker 1: So we're really talking about authorization at this point, not authentication.

380
00:20:27,279 --> 00:20:31,720
You're authenticated by that cookie. Now authorization takes on this

381
00:20:32,039 --> 00:20:33,240
whole other topic.

382
00:20:33,519 --> 00:20:37,400
Speaker 3: Well, think about it from the perspective of your API.

383
00:20:38,160 --> 00:20:42,079
You're still authenticating, right, because a request comes in, there's

384
00:20:42,119 --> 00:20:45,599
an access token that says who is calling this thing?

385
00:20:45,640 --> 00:20:47,799
And that may just be hey, it's just a BFF

386
00:20:47,839 --> 00:20:51,359
that's calling you. Trust a BFF, right, do your thing,

387
00:20:51,559 --> 00:20:53,400
But it may also be no, this is an access

388
00:20:53,400 --> 00:20:57,279
token that has user information in it, so a subject identifier,

389
00:20:57,400 --> 00:21:00,440
maybe all kinds of other claims that then the might

390
00:21:00,480 --> 00:21:04,119
also use to make coarse grained authorization decisions.

391
00:21:04,200 --> 00:21:06,640
Speaker 1: Sure, sure, okay, So.

392
00:21:08,039 --> 00:21:13,319
Speaker 3: Now on top of that, you can also look at sessions. Now,

393
00:21:14,680 --> 00:21:18,480
the cookie, that's the thing that identifies you as a

394
00:21:19,079 --> 00:21:21,160
but you can store information in the cookie. If you

395
00:21:21,160 --> 00:21:24,599
wanted to, you could store the access token in the cookie.

396
00:21:24,759 --> 00:21:27,160
Now it's still secure. It goes to the browser, but

397
00:21:27,480 --> 00:21:31,839
the browser based application can't reach it, and then that's sorry.

398
00:21:31,880 --> 00:21:36,440
The advantage of that is is that your BFF is

399
00:21:36,680 --> 00:21:40,160
relatively stateless, right, it doesn't need to store that session

400
00:21:40,200 --> 00:21:43,279
information somewhere. But if you were to store that session

401
00:21:43,319 --> 00:21:46,240
information in a database, then you can also do things

402
00:21:46,319 --> 00:21:50,440
like remote sign out, for example, because if you delete

403
00:21:50,440 --> 00:21:52,720
the record from the database, the user is signed out

404
00:21:52,759 --> 00:21:54,839
and you can't access to the system anymore and needs

405
00:21:54,880 --> 00:21:58,000
to log back in again. So there are benefits and

406
00:21:58,039 --> 00:22:02,240
downside of store. You know, your your session information in

407
00:22:02,279 --> 00:22:02,880
a database.

408
00:22:03,119 --> 00:22:07,200
Speaker 1: Sure, and if you have something like Blazer server you

409
00:22:07,240 --> 00:22:10,319
can use or server based stuff. You can use a

410
00:22:10,359 --> 00:22:13,279
protected browser storage, which I guess gives you what five

411
00:22:13,400 --> 00:22:18,519
megabytes of encrypted data on the on the browser per

412
00:22:18,680 --> 00:22:21,440
user per r L. Yeah. Yeah.

413
00:22:21,559 --> 00:22:26,480
Speaker 3: The downside of of these storages in the browser is

414
00:22:26,519 --> 00:22:29,519
that it is still the browser application that reaches into that.

415
00:22:29,960 --> 00:22:33,200
And there's been quite a number of things that have

416
00:22:33,279 --> 00:22:36,559
been tried to to do that. I mean storing things

417
00:22:36,599 --> 00:22:40,680
inside of web workers to to keep them, keep them hidden,

418
00:22:40,960 --> 00:22:44,119
you know, encrypted storage, all of that stuff. But ultimately,

419
00:22:44,200 --> 00:22:47,359
if the browser based application can reach it, you know,

420
00:22:47,440 --> 00:22:52,160
you're exposing that information also to potentially malicious actors.

421
00:22:52,400 --> 00:22:55,079
Speaker 1: I remember one thing that Dom I think it was dumb,

422
00:22:55,119 --> 00:22:57,240
it might have been Brock said, these are the one

423
00:22:57,319 --> 00:23:03,559
day guys over and over again, is that you want

424
00:23:03,599 --> 00:23:08,640
your authorization system to be totally separate from your authentication system. Yes,

425
00:23:08,839 --> 00:23:12,519
you know want those two tied together. And in what

426
00:23:12,680 --> 00:23:15,400
is the asp net core identity where you have just

427
00:23:15,440 --> 00:23:21,119
these databases that do that hold both the authentication passwords,

428
00:23:21,279 --> 00:23:26,960
hashes and also you know, claims, roles and that kind

429
00:23:27,000 --> 00:23:29,440
of stuff. You're really kind of tying the two together.

430
00:23:30,119 --> 00:23:33,039
And I didn't really understand what he meant by that,

431
00:23:33,279 --> 00:23:37,640
but but I get it that that having it separate

432
00:23:39,039 --> 00:23:41,680
just it doesn't tie them together.

433
00:23:42,039 --> 00:23:45,680
Speaker 3: Yeah. I think the key thing to keep in mind

434
00:23:45,720 --> 00:23:49,039
here is that what you get from your identity provider,

435
00:23:49,240 --> 00:23:51,880
and maybe you layer a little bit on top of

436
00:23:51,920 --> 00:23:54,720
that inside of your application, and you could do that

437
00:23:54,799 --> 00:23:58,079
in the BFF as well. Should say something about the

438
00:23:58,160 --> 00:24:02,640
user itself. Right, So I am irwin, I have you

439
00:24:02,680 --> 00:24:06,720
know this role in the organization, right, But as soon

440
00:24:06,759 --> 00:24:10,160
as you start to think about other things like I

441
00:24:10,240 --> 00:24:14,359
have created this particular document, or I am a manager

442
00:24:14,519 --> 00:24:19,119
of that particular department, and therefore I that is not

443
00:24:19,279 --> 00:24:22,559
information that you want to store and managing your identity provider.

444
00:24:22,680 --> 00:24:25,279
That's not part of your identity. That's much more part

445
00:24:25,279 --> 00:24:30,599
of your application domain. And therefore those authorization decisions you

446
00:24:30,680 --> 00:24:33,880
do not want to take purely based on information that's

447
00:24:33,880 --> 00:24:36,839
stored in your cookie and sorting your access token, you

448
00:24:36,880 --> 00:24:40,759
actually want to say no no, no, I am. I'm

449
00:24:40,839 --> 00:24:43,680
defining what we call a policy, and that policy says,

450
00:24:43,720 --> 00:24:46,279
am I allowed to do this given who I am?

451
00:24:46,640 --> 00:24:50,079
And then inside of the code that executes that policy,

452
00:24:50,319 --> 00:24:54,200
you can do lookups like are you the right manager

453
00:24:54,200 --> 00:24:57,960
for this particular thing? Do you have access to that thing.

454
00:24:57,839 --> 00:25:01,000
Speaker 1: If you're rolling your own Well, but I've seen many

455
00:25:01,000 --> 00:25:03,200
customers and I do this myself, is that you have

456
00:25:03,799 --> 00:25:08,720
you know, your your aspnet user's table in identity Core

457
00:25:09,839 --> 00:25:12,720
ASPN Core Identity and then basically what we would do

458
00:25:12,799 --> 00:25:15,319
is create a separate user's table that has all the

459
00:25:15,400 --> 00:25:20,880
application specific data about that user, and then it's related

460
00:25:20,920 --> 00:25:23,240
with a foreign key to that aspnet user in case

461
00:25:23,400 --> 00:25:26,799
you know, so that that's how they're tied together, but

462
00:25:27,000 --> 00:25:28,359
they're still in the same database.

463
00:25:28,640 --> 00:25:32,960
Speaker 3: Yeah, and authorization can become really complex.

464
00:25:33,240 --> 00:25:33,400
Speaker 1: Right.

465
00:25:33,960 --> 00:25:37,640
Speaker 3: You can imagine inside of a big enterprise, one system

466
00:25:37,680 --> 00:25:41,039
controls this particular aspect, that other system controls that particular aspect.

467
00:25:41,279 --> 00:25:45,319
Now there are these systems, you know, policy server being

468
00:25:45,359 --> 00:25:49,000
one of them as an example, right, that might actually say, okay,

469
00:25:49,599 --> 00:25:52,599
you replicate some of the information that's part of your

470
00:25:52,640 --> 00:25:56,440
domain into that server and then you know, since that

471
00:25:56,519 --> 00:25:59,920
information is also stored in there. You can create association

472
00:26:00,079 --> 00:26:04,720
is there. You can say, because this particular person has

473
00:26:04,839 --> 00:26:08,319
this role, this relationship with that other thing, that's why

474
00:26:08,359 --> 00:26:10,680
he's allowed to do these particular things, and those things

475
00:26:10,680 --> 00:26:14,079
can inherit from each other. You can basically model your

476
00:26:14,359 --> 00:26:18,200
authorization domain, but that is only if you have an

477
00:26:18,279 --> 00:26:23,000
application landscape that is complex enough to warrant extracting that.

478
00:26:23,240 --> 00:26:27,599
Speaker 1: Multiple applications from the same vendor. For example. Yeah, and

479
00:26:27,680 --> 00:26:31,079
some customers have access to this application and that application,

480
00:26:31,119 --> 00:26:32,039
but not that one.

481
00:26:32,119 --> 00:26:35,839
Speaker 2: But I also look at it from a administrative versus

482
00:26:35,920 --> 00:26:38,200
regular user role within an app or you can even

483
00:26:38,240 --> 00:26:40,920
be more gradiated that HR can see some things that

484
00:26:41,000 --> 00:26:44,160
sales can't see, Like you need to have someplace for

485
00:26:44,200 --> 00:26:46,200
all of those different levels of authorization to live.

486
00:26:46,359 --> 00:26:50,559
Speaker 3: Yeah, and you know, in an enterprise, what you typically

487
00:26:50,599 --> 00:26:52,720
see is that, you know, especially if the enterprise has

488
00:26:52,720 --> 00:26:56,240
built their own custom software for certain types of things,

489
00:26:56,359 --> 00:26:59,640
that it really warrants you to store that that centrally.

490
00:27:00,119 --> 00:27:04,000
Sometimes you literally have islands where each application stores its

491
00:27:04,000 --> 00:27:05,839
own and has its own logic.

492
00:27:05,519 --> 00:27:09,480
Speaker 1: Around right, yeah, right, you want to take a break,

493
00:27:09,599 --> 00:27:11,319
or yeah, it's a good time. Oh well, yeah, okay,

494
00:27:11,319 --> 00:27:13,440
we'll take a break. We'll be right back after these

495
00:27:13,640 --> 00:27:17,799
very important messages. Stay tuned. Do you have a complex

496
00:27:17,839 --> 00:27:20,359
dot net monolith you'd like to refactor to a micro

497
00:27:20,480 --> 00:27:24,880
services architecture? The micro Service Extractor for dot Net tool

498
00:27:25,039 --> 00:27:29,720
visualizes your app and helps progressively extract code into micro services.

499
00:27:30,079 --> 00:27:38,279
Learn more at aws dot Amazon dot com, slash modernize

500
00:27:38,559 --> 00:27:42,079
and we're back. It's dot NetRocks. I'm Carl Franklin. That's

501
00:27:42,079 --> 00:27:44,920
my friend Richard Campbell. Hey, and that's our friend Erwin

502
00:27:45,039 --> 00:27:50,559
van Dervach from Duende. We're talking about interestingly enough policy

503
00:27:50,640 --> 00:27:53,880
server and why it's such a good idea to separate

504
00:27:55,200 --> 00:27:59,359
authorization policies from authentication databases.

505
00:27:59,480 --> 00:28:02,599
Speaker 3: Yeah, and of course you really have to think, you know,

506
00:28:03,920 --> 00:28:06,319
how complex is your application and do you need to

507
00:28:06,359 --> 00:28:10,039
externalize those decisions? And then you know, is it complex

508
00:28:10,160 --> 00:28:12,519
enough that you need a product for that, because.

509
00:28:12,279 --> 00:28:14,960
Speaker 2: There's an awful lot of cases where identity enough and

510
00:28:15,119 --> 00:28:19,319
authorization are essentially identical. You identify with this so you

511
00:28:19,440 --> 00:28:22,200
get all right, so this app. There is no granularization

512
00:28:22,359 --> 00:28:23,559
of the rights within the app.

513
00:28:23,839 --> 00:28:28,440
Speaker 1: Yeah, and if it's complex enough, you'll know, Yeah, absolutely,

514
00:28:28,680 --> 00:28:29,599
you'll fit that point.

515
00:28:29,640 --> 00:28:31,599
Speaker 2: It's one of those things where the moment I want

516
00:28:31,640 --> 00:28:34,319
to granularize the rights within an app, I probably should

517
00:28:34,319 --> 00:28:34,559
have a.

518
00:28:34,480 --> 00:28:35,720
Speaker 1: Place for all that stuff to live.

519
00:28:35,799 --> 00:28:39,039
Speaker 3: Yeah, coming back to the BFF pattern, right, one of

520
00:28:39,039 --> 00:28:42,720
the things I mentioned is c surf protection. You know,

521
00:28:43,319 --> 00:28:46,559
the challenge with issuing cookies is that cookies are sent

522
00:28:46,680 --> 00:28:53,240
automatically when the browser makes a request to a particular domain.

523
00:28:54,119 --> 00:28:57,880
And the challenge there could be is that if a

524
00:28:58,000 --> 00:29:02,400
malicious actor lures you your users to a malicious site

525
00:29:02,799 --> 00:29:05,359
and he then makes a call from that malicious site

526
00:29:05,519 --> 00:29:09,960
to your application, you don't want, you know, authorized requests

527
00:29:10,000 --> 00:29:13,920
to be sent. Now, browsers already have pretty good protection

528
00:29:14,240 --> 00:29:17,599
baked in there, I mean, and also there's a process

529
00:29:17,599 --> 00:29:21,519
for that, what we call cross origin resource sharing. You

530
00:29:21,559 --> 00:29:25,559
can define policies around that course to define well is

531
00:29:25,599 --> 00:29:28,960
this allowed or not. But unfortunately, there are a couple

532
00:29:29,000 --> 00:29:33,519
of holes that are still allowed by the course you know,

533
00:29:33,599 --> 00:29:36,720
that wouldn't trigger a course policy check, and that could

534
00:29:36,759 --> 00:29:38,559
potentially be dangerous.

535
00:29:38,400 --> 00:29:40,720
Speaker 1: Allow all for example, Well.

536
00:29:40,920 --> 00:29:43,440
Speaker 3: That's if you have a course policy in the first place.

537
00:29:43,480 --> 00:29:46,519
But what I'm talking about here is that there are

538
00:29:46,599 --> 00:29:50,319
certain requests that the browser deemed safe and therefore won't

539
00:29:50,319 --> 00:29:55,599
trigger a course check, and because of that, you know

540
00:29:55,680 --> 00:29:59,079
you could be in trouble. Now, to be fair, dot

541
00:29:59,160 --> 00:30:01,440
net already does a pretty good job of protecting you

542
00:30:01,480 --> 00:30:06,839
against those because they those type of requests would be gets.

543
00:30:07,039 --> 00:30:10,440
Now gets shouldn't manipulate states, so you shouldn't be able

544
00:30:10,480 --> 00:30:13,279
to get into trouble with those. And they can be

545
00:30:14,319 --> 00:30:17,119
simple posts, but as soon as you try to do

546
00:30:17,200 --> 00:30:21,519
a post with a specific content type, that's when you

547
00:30:21,559 --> 00:30:24,559
know the course policy would be would be triggered.

548
00:30:24,559 --> 00:30:25,119
Speaker 1: For example.

549
00:30:25,680 --> 00:30:30,480
Speaker 3: Now, some frameworks, you know, some server side frameworks, they

550
00:30:30,799 --> 00:30:33,559
don't do a very good job of checking those content types.

551
00:30:33,599 --> 00:30:35,559
But dot Net, by default, if you say, hey, you know,

552
00:30:35,640 --> 00:30:38,720
I'm expecting a post that's just an adjacent document, you know,

553
00:30:39,000 --> 00:30:44,160
it will not accept it if it's not adjacent post.

554
00:30:44,359 --> 00:30:45,279
Speaker 1: Is it just raise an error?

555
00:30:45,359 --> 00:30:46,799
Speaker 3: Yeah, it would just say hey, this is the wrong

556
00:30:46,799 --> 00:30:48,240
content type, I go away.

557
00:30:48,440 --> 00:30:48,680
Speaker 1: Yeah.

558
00:30:48,799 --> 00:30:51,359
Speaker 3: Right, So fortunately dot net also helps you with that.

559
00:30:51,480 --> 00:30:54,759
But again, right, security is about more layers. So there's

560
00:30:54,799 --> 00:30:59,480
a very simple way of tackling this. Now, Microsoft provides

561
00:30:59,519 --> 00:31:03,440
you with se SERF protection, right, so cross side request

562
00:31:03,440 --> 00:31:07,880
forger reprotection, but it is based on encryption, and you

563
00:31:07,920 --> 00:31:11,359
need to specify the data protection keys and all your servers,

564
00:31:11,359 --> 00:31:13,359
and if you make a mistake there, you know it

565
00:31:13,400 --> 00:31:17,480
doesn't work. But the very simple thing is just to

566
00:31:17,519 --> 00:31:21,720
say in your BFF server to demand that a specific

567
00:31:21,759 --> 00:31:24,319
header is there. And I'm saying specific header. It really

568
00:31:24,359 --> 00:31:26,279
doesn't matter what the header is as long as it's

569
00:31:26,319 --> 00:31:30,599
a custom header. So your front end just always sends

570
00:31:30,640 --> 00:31:33,039
that header, no problem, right, It could be you know

571
00:31:33,640 --> 00:31:37,160
x SE serf equals one, doesn't matter, right, Your front

572
00:31:37,240 --> 00:31:41,559
end just always sends that. If the malicious site wants

573
00:31:41,599 --> 00:31:45,240
to call your service, it doesn't have that header, so

574
00:31:45,480 --> 00:31:49,079
it will that your your BFF will say I'm not

575
00:31:49,160 --> 00:31:52,279
letting you in. If the malicious site then tries to

576
00:31:52,519 --> 00:31:55,920
add that header, now you're adding a custom header to

577
00:31:55,960 --> 00:31:58,880
the request and that triggers the course policies in a browser,

578
00:31:58,920 --> 00:32:02,480
so it stops all the sea surf attacks dead. So

579
00:32:03,279 --> 00:32:07,599
just by demanding in your server you must have a

580
00:32:07,640 --> 00:32:10,480
custom header, and as long as you have an agreement

581
00:32:10,519 --> 00:32:13,039
between your backhand and your front end, hey, send that header.

582
00:32:13,599 --> 00:32:14,119
Speaker 1: You're safe.

583
00:32:15,440 --> 00:32:16,119
Speaker 3: That's kind of cool.

584
00:32:16,440 --> 00:32:17,160
Speaker 1: That's kind of cool.

585
00:32:17,519 --> 00:32:20,079
Speaker 2: And can you read something in that header that's like

586
00:32:20,359 --> 00:32:23,160
a security key or something not easily spoofed.

587
00:32:23,480 --> 00:32:27,279
Speaker 3: You don't have to. That's the thing. I mean, this

588
00:32:27,359 --> 00:32:30,279
confused me in the beginning quite a bit because I thought, well.

589
00:32:30,240 --> 00:32:32,240
Speaker 1: Why headers or headers? They should be able to make

590
00:32:32,240 --> 00:32:32,880
anything I want.

591
00:32:33,319 --> 00:32:37,680
Speaker 3: Yeah, But the point is is that the browser standards

592
00:32:37,839 --> 00:32:41,799
they dictate that if you do a cross origin call

593
00:32:43,119 --> 00:32:47,240
and you do that with a specific header, that first

594
00:32:47,319 --> 00:32:50,839
you must do a course policy check and then that

595
00:32:50,920 --> 00:32:53,039
course policy comes into play. Now, if you screw up

596
00:32:53,079 --> 00:32:56,200
your course policy, if you say course policy allow all, sure,

597
00:32:56,240 --> 00:32:58,920
you're still vulnerable. But here's the point, right, if you

598
00:32:59,000 --> 00:33:02,720
do it correctly, then you're secure. And by default, by

599
00:33:02,720 --> 00:33:04,960
the way, if you don't specify a course policy, the

600
00:33:05,000 --> 00:33:08,279
course policy is deny. So you're pretty secure if you

601
00:33:08,319 --> 00:33:11,200
don't do anything there. There's a couple of other things

602
00:33:11,200 --> 00:33:13,920
that you could look at. I mean, Blazer support is

603
00:33:13,960 --> 00:33:18,400
an interesting one. I Mean, the thing with Blazer is

604
00:33:18,400 --> 00:33:22,279
is that it's a really powerful framework, but because of

605
00:33:22,319 --> 00:33:26,920
all of its rendering modes, you have to pay attention, right,

606
00:33:26,960 --> 00:33:29,960
I mean, if you're doing purely service side rendering, then

607
00:33:30,079 --> 00:33:34,880
you're just building a regular application. But if you start

608
00:33:34,960 --> 00:33:39,559
mixing those interactivity modes, especially in the auto rendering mode.

609
00:33:39,799 --> 00:33:43,839
Then some communication might go over web sockets, some communication

610
00:33:44,000 --> 00:33:48,160
might be with web requests, and yeah, you just have

611
00:33:48,240 --> 00:33:51,039
to you know, look at all, how are you going

612
00:33:51,079 --> 00:33:54,799
to set the you know, as soon as you start

613
00:33:54,799 --> 00:34:00,000
doing web requests, right, so regularates to be requests. Yeah,

614
00:33:59,839 --> 00:34:03,519
you just have to make sure that you're calling it

615
00:34:04,480 --> 00:34:07,799
with the right credentials. Now, inside of the do end,

616
00:34:07,799 --> 00:34:10,719
the BFF framework, the one that I'm responsible for as well,

617
00:34:10,800 --> 00:34:13,199
we try to make sure that that is all unified

618
00:34:13,199 --> 00:34:15,000
so that you just have a single programming model that

619
00:34:15,039 --> 00:34:17,559
you can code in your Blazer back end, in your

620
00:34:17,559 --> 00:34:21,400
front end, and the auto rendering modes just work work seamlessly.

621
00:34:21,760 --> 00:34:24,039
But if you don't use that framework, if you just

622
00:34:24,079 --> 00:34:26,079
want to build your own then of course. And if

623
00:34:26,119 --> 00:34:28,840
you do use Blazer, then that's one thing to watch

624
00:34:28,840 --> 00:34:29,559
out for as well.

625
00:34:30,320 --> 00:34:32,760
Speaker 2: And does the Blazer mode matter, like you have to

626
00:34:32,800 --> 00:34:34,719
be in client mode for this to make sense or

627
00:34:34,760 --> 00:34:36,199
do It'll work the same either way.

628
00:34:36,840 --> 00:34:40,760
Speaker 3: Now, well, so here's the thing. Right with the auto

629
00:34:40,840 --> 00:34:43,880
rendering mode. If you say I want to display a

630
00:34:43,960 --> 00:34:47,960
list on the screen, there's three things that can happen.

631
00:34:48,360 --> 00:34:50,199
One is it get rented on the server, and that's

632
00:34:50,199 --> 00:34:52,599
actually what happens initially, right, it's rented on the server

633
00:34:52,719 --> 00:34:55,719
and then send to the browsers HTML. So then you

634
00:34:55,800 --> 00:34:57,880
need to have on the server. You need to be

635
00:34:57,880 --> 00:34:59,960
able to get to that data. That might either be

636
00:35:00,400 --> 00:35:02,639
just go directly to the database because you're in the

637
00:35:02,679 --> 00:35:06,280
same space, or you're doing a call to an external service,

638
00:35:06,519 --> 00:35:08,320
and therefore you need to make sure that there's an

639
00:35:08,320 --> 00:35:10,480
access token on the ah top client to call that

640
00:35:10,519 --> 00:35:16,719
external service. When you are in interactive mode, right, so

641
00:35:16,800 --> 00:35:21,320
it's running on the in the it switches over to

642
00:35:22,079 --> 00:35:25,239
web assembly mode. Then all of a sudden, it's the

643
00:35:25,239 --> 00:35:28,000
browser that does that request, right, And you can't go

644
00:35:28,119 --> 00:35:31,239
from the browser directly to that API in point because

645
00:35:31,559 --> 00:35:33,880
first of all, it might just be in an internal network, right,

646
00:35:34,000 --> 00:35:36,199
the browser doesn't have access directly to that API in

647
00:35:36,239 --> 00:35:38,239
point right, And second of all, you don't have that

648
00:35:38,320 --> 00:35:41,239
access token. You don't want that access token there, so

649
00:35:41,280 --> 00:35:44,079
then you need to proxy that request using a reverse

650
00:35:44,119 --> 00:35:48,039
proxy through the BFF, and then the BFF does that token,

651
00:35:48,280 --> 00:35:50,960
the cookie exchange for the token, and then goes out

652
00:35:51,400 --> 00:35:56,679
to that external service. So that's how that's supposed to

653
00:35:56,679 --> 00:35:58,239
work together.

654
00:35:58,320 --> 00:36:01,039
Speaker 2: Then as well, trying to figure out how much work

655
00:36:01,039 --> 00:36:02,920
I actually have to do to implement this framework. It

656
00:36:03,000 --> 00:36:05,039
sounds almost like a drop in thing and that should

657
00:36:05,079 --> 00:36:05,639
be good to go.

658
00:36:05,840 --> 00:36:09,159
Speaker 3: Yeah, I mean, if you want to build it yourself,

659
00:36:09,199 --> 00:36:10,840
then of course you need to know what you're doing,

660
00:36:10,920 --> 00:36:13,920
and you know, Microsoft provides a bunch of things, but.

661
00:36:14,000 --> 00:36:15,639
Speaker 1: That's never stopping before or when.

662
00:36:15,760 --> 00:36:19,960
Speaker 3: Come on, yeah, of course, but I mean you know

663
00:36:20,000 --> 00:36:21,840
you need to You can use YARP, that's a really

664
00:36:21,880 --> 00:36:24,440
good reverse proxy. I mean, you can use the Microsoft

665
00:36:24,440 --> 00:36:27,840
libraries for that. We provide an open source library for

666
00:36:27,840 --> 00:36:30,519
access token management, so that there's a bunch of things

667
00:36:30,519 --> 00:36:32,119
that you can do, and if you know what you're doing,

668
00:36:32,360 --> 00:36:36,039
then you can just do that. If you rather use

669
00:36:36,079 --> 00:36:38,079
a product, then of course, you know, we provide a

670
00:36:38,239 --> 00:36:40,960
product that you can also. You know, if you uh,

671
00:36:41,519 --> 00:36:41,800
it is.

672
00:36:41,800 --> 00:36:43,800
Speaker 1: A new GET package, right like this isn't it.

673
00:36:43,800 --> 00:36:45,559
Speaker 3: It's just a new Get packaging. You plug it in

674
00:36:45,639 --> 00:36:47,639
with a couple of lines of code, you have it working,

675
00:36:47,719 --> 00:36:50,199
and you know, we have a community license as well,

676
00:36:50,239 --> 00:36:53,880
so that if you uh, you know, I think it's

677
00:36:54,239 --> 00:36:56,719
if you make less than a couple of million of years,

678
00:36:56,760 --> 00:36:58,880
then you can just use the product for free. Right

679
00:36:58,920 --> 00:37:01,119
if you make over that then you know, you pay

680
00:37:01,119 --> 00:37:04,920
a little bit and then you get a nice product

681
00:37:04,960 --> 00:37:05,119
for that.

682
00:37:05,280 --> 00:37:08,239
Speaker 2: So yeah, no, and you said, drop in a couple

683
00:37:08,239 --> 00:37:12,760
of configuration things. You're working and you've you're using this

684
00:37:12,800 --> 00:37:15,000
whole TLS approach, like your life is better.

685
00:37:15,320 --> 00:37:19,519
Speaker 3: Absolutely. Now there's one thing that we're also working on,

686
00:37:19,639 --> 00:37:24,000
and it kind of bleeds into more operations, right because

687
00:37:24,880 --> 00:37:28,119
if you have a purely browser based application, you can

688
00:37:28,159 --> 00:37:30,159
just host that on a CD and and you know,

689
00:37:31,000 --> 00:37:33,159
run that somewhere and now all of a sudden, you

690
00:37:33,199 --> 00:37:35,800
do need a back end component for that. Now, if

691
00:37:35,840 --> 00:37:37,519
you do that for your first application, you have a

692
00:37:37,559 --> 00:37:39,079
really nice you know, you've got a nice back end

693
00:37:39,079 --> 00:37:42,159
for your front end. It's all good. But typically, you know,

694
00:37:42,239 --> 00:37:45,400
especially enterprises, they have a lot of applications and then

695
00:37:45,440 --> 00:37:47,960
they come to the conclusions like I have a lot

696
00:37:48,000 --> 00:37:51,039
of BFFs here, you know, can't we do anything about that? Right,

697
00:37:51,280 --> 00:37:53,800
So one of the things that we're about to release

698
00:37:54,239 --> 00:37:56,440
is multi front end support as well, So you can

699
00:37:56,440 --> 00:38:00,159
have a single BFF that just you know, from the

700
00:38:00,199 --> 00:38:03,280
perspective of the front end, it is just a single

701
00:38:03,320 --> 00:38:05,800
back end for front end, but physically it's a single

702
00:38:05,800 --> 00:38:07,079
host that can serve many of.

703
00:38:07,039 --> 00:38:09,039
Speaker 2: Them, right, so you don't end up with one for

704
00:38:09,159 --> 00:38:13,280
every app, which can get untenable. You have exactly collective

705
00:38:13,800 --> 00:38:16,039
because they're all using the same right sets and so forth. Like,

706
00:38:16,079 --> 00:38:18,679
this is all very shareable, and I suspet it's like

707
00:38:18,800 --> 00:38:21,239
ninety five percent in common between apps and there's just

708
00:38:21,239 --> 00:38:22,119
a few exceptions.

709
00:38:22,400 --> 00:38:24,880
Speaker 3: Yeah, exactly. Now, now there's a couple of other things

710
00:38:24,880 --> 00:38:27,760
that I mean, I've applied this pattern a lot of

711
00:38:27,760 --> 00:38:30,400
times already in my career, and one of the things

712
00:38:30,400 --> 00:38:33,639
that I'm finding is that it also helps my collaboration

713
00:38:33,840 --> 00:38:36,239
with front end developers. I mean, I am primarily a

714
00:38:36,239 --> 00:38:38,559
back end developer. I know enough about a front end

715
00:38:38,599 --> 00:38:42,599
to being dangerous, but primarily a back end developer. But

716
00:38:43,599 --> 00:38:46,480
when I'm working with front end developers, it's really nice

717
00:38:46,760 --> 00:38:49,760
to have what I typically call then a dev server.

718
00:38:49,920 --> 00:38:53,079
Nowadays you would build that with Aspire. You have something

719
00:38:53,360 --> 00:38:56,039
that front end engineers can just run and it's just

720
00:38:56,039 --> 00:38:58,760
just running there nicely, and they can iterate on building

721
00:38:58,760 --> 00:39:01,400
their front ends. And as a back end engineer, I

722
00:39:01,440 --> 00:39:03,800
mean I just spin up the front end and my

723
00:39:03,880 --> 00:39:05,920
back end is there, and I can iterate on my

724
00:39:05,960 --> 00:39:08,079
back end. And if you have a branch. Where you

725
00:39:08,119 --> 00:39:10,599
have both of them, you can easily work together on

726
00:39:10,639 --> 00:39:12,559
them with the front end. You compare program. Hey, I

727
00:39:12,559 --> 00:39:14,039
build this in the front end, build this in the

728
00:39:14,039 --> 00:39:17,800
back end, work together. It's just a really nice flow

729
00:39:17,880 --> 00:39:21,440
to to collaborate together.

730
00:39:21,840 --> 00:39:26,320
Speaker 2: So and then is the BFF security framework. It's again,

731
00:39:26,320 --> 00:39:28,320
it's just a new GET package. So is it just

732
00:39:28,320 --> 00:39:32,519
a line in Aspire to say include this and just

733
00:39:32,559 --> 00:39:34,039
another part of the equation.

734
00:39:34,199 --> 00:39:36,880
Speaker 3: Right now, it is just a new GET package that

735
00:39:36,920 --> 00:39:40,480
you need to install inside of your web application. In

736
00:39:40,559 --> 00:39:43,960
the near future, yes, it's going to be just a

737
00:39:44,000 --> 00:39:46,320
container that you can just run and aspire and from

738
00:39:46,360 --> 00:39:48,960
that point on you can use that as a development experience.

739
00:39:49,079 --> 00:39:50,639
Speaker 1: Very cool. Yeah, I'd like it. I just like that

740
00:39:50,719 --> 00:39:51,360
in my template.

741
00:39:51,440 --> 00:39:53,800
Speaker 2: I'm thinking, I'm thinking very enterprising here about how do

742
00:39:53,880 --> 00:39:57,239
I get my devs on the path to using these

743
00:39:57,280 --> 00:39:58,440
tools from the outset?

744
00:39:58,679 --> 00:40:02,239
Speaker 3: Yeah, yeah, absolutely, And that's exactly what we see people

745
00:40:02,280 --> 00:40:04,760
do for this, and you know, and there's nice tricks

746
00:40:04,760 --> 00:40:06,840
that you can do there with that, because one of

747
00:40:06,840 --> 00:40:08,760
the things that you know, as a back end engineer,

748
00:40:08,880 --> 00:40:11,719
I don't sometimes even have all the front end tools installed,

749
00:40:11,719 --> 00:40:15,320
and there's like a gazillion of them. So what I

750
00:40:15,320 --> 00:40:16,320
typically do then.

751
00:40:16,320 --> 00:40:19,599
Speaker 1: Is again not an exaggeration, no, and gazillion.

752
00:40:20,239 --> 00:40:22,440
Speaker 3: So when I just start up the back end, it

753
00:40:22,599 --> 00:40:25,199
just loads the most recent front end from my dev

754
00:40:25,360 --> 00:40:27,960
environment in the clouds. It gets it from a CDN

755
00:40:28,239 --> 00:40:30,639
right right. But then if I start up both of them,

756
00:40:30,679 --> 00:40:33,679
I can detect, hey, the front end code is running locally.

757
00:40:33,920 --> 00:40:35,960
Let me just take the front end code locally and

758
00:40:36,000 --> 00:40:42,280
serve that from there instead of them from the CDN server.

759
00:40:42,599 --> 00:40:44,559
So that's a really nice experience. Then. You know, if

760
00:40:44,599 --> 00:40:46,239
I don't care about the front end, I can just

761
00:40:46,280 --> 00:40:48,800
start it up. If I do care about it, especially

762
00:40:48,800 --> 00:40:51,079
when working together, you start them up both and they

763
00:40:51,079 --> 00:40:53,639
just start working together. That's a really nice experience there

764
00:40:53,679 --> 00:40:54,000
as well.

765
00:40:54,119 --> 00:40:57,480
Speaker 2: For sure, What about the telemetry side, is there any

766
00:40:57,679 --> 00:41:01,360
information coming out of this framework that helps me as

767
00:41:01,440 --> 00:41:05,320
an on the administrator side knowing what privileges are being

768
00:41:05,360 --> 00:41:06,039
gained and so forth.

769
00:41:06,159 --> 00:41:08,039
Speaker 1: Is that still be part of the regular system.

770
00:41:08,199 --> 00:41:18,199
Speaker 3: Yeah, that's the actual authentication bit. I mean, we track

771
00:41:18,519 --> 00:41:21,960
how many tokens are being exchanged, and we do metrics

772
00:41:21,960 --> 00:41:25,719
for those type of things. And of course if you

773
00:41:25,800 --> 00:41:28,559
use service side sessions, you know exactly how many people

774
00:41:28,639 --> 00:41:31,719
are online at any point in time, so you can

775
00:41:31,760 --> 00:41:35,599
also do metrics for those, but actually publishing these metrics

776
00:41:35,639 --> 00:41:39,760
as open telemetry is something that we haven't built in yet, right,

777
00:41:39,920 --> 00:41:43,159
And there is a reason for that as well, is

778
00:41:43,199 --> 00:41:47,239
that all of the traffic between your front end and

779
00:41:47,599 --> 00:41:51,360
your APIs flows through the BFF, so it has to

780
00:41:51,400 --> 00:41:54,639
reverse proxy those otherwise the cookie won't flow and therefore

781
00:41:54,920 --> 00:42:00,280
the reverse proxy is very secured, very performance sensitive. I mean,

782
00:42:00,320 --> 00:42:04,800
you don't want delays in there for reasons. So if

783
00:42:04,800 --> 00:42:07,159
you were to add if we were to add code

784
00:42:07,159 --> 00:42:09,760
in there that says every five minutes, look how many

785
00:42:09,840 --> 00:42:12,079
users there are, look how many you know, and publish

786
00:42:12,159 --> 00:42:18,840
those as statistics, right, we might, you know, negatively impact

787
00:42:18,880 --> 00:42:21,440
your performance. So we don't want to do that obviously.

788
00:42:21,480 --> 00:42:25,559
Speaker 2: Sure, I'm just thinking about additional telemetry you'd have access to,

789
00:42:25,760 --> 00:42:28,920
just because you can see these tokens flowing around. But yeah,

790
00:42:29,159 --> 00:42:31,360
and it's always a debate as to how much what

791
00:42:31,400 --> 00:42:32,679
do you want, Like where is that?

792
00:42:32,719 --> 00:42:33,800
Speaker 1: What is that useful for?

793
00:42:33,960 --> 00:42:34,480
Speaker 3: Absolutely?

794
00:42:34,519 --> 00:42:38,400
Speaker 2: Certainly when you're trying to do a call chain, knowing

795
00:42:38,559 --> 00:42:41,599
what token was issued, when it was issued, when it expired,

796
00:42:41,639 --> 00:42:43,199
like that's all part of that chain.

797
00:42:43,320 --> 00:42:47,079
Speaker 3: Oh yeah, well, and access to cam management does alog

798
00:42:47,159 --> 00:42:48,239
quite a lot of information.

799
00:42:49,000 --> 00:42:50,840
Speaker 2: Yeah, that's the thing that's a lot of that's already

800
00:42:50,880 --> 00:42:53,320
handled for you. Absolutely not your problem. You're just calling

801
00:42:53,360 --> 00:42:54,159
into those services.

802
00:42:55,000 --> 00:42:58,239
Speaker 3: Technically, it's my problem because I'm also the product owner

803
00:42:58,239 --> 00:42:59,239
for access to com management.

804
00:42:59,480 --> 00:43:01,239
Speaker 2: Well you're also the COGA provider. But that's not the

805
00:43:01,280 --> 00:43:04,880
security framework's fault. No, exactly, exactly. Now I'll get that

806
00:43:04,920 --> 00:43:08,480
telemetry for identity server. Yeah, but I mean, yeah, I'm

807
00:43:08,519 --> 00:43:10,039
just thin get through all the issues.

808
00:43:10,599 --> 00:43:12,400
Speaker 3: No, absolutely, absolutely so.

809
00:43:13,440 --> 00:43:17,119
Speaker 1: Yeah, So is there anything that we missed, any gotchas

810
00:43:17,599 --> 00:43:22,400
that people might run into, or any other issues around

811
00:43:23,079 --> 00:43:26,559
this BFF pattern that people find tricky.

812
00:43:26,880 --> 00:43:29,440
Speaker 3: Well, I mean there's a couple of ways that you

813
00:43:29,480 --> 00:43:32,519
can host this really in production that might be interesting

814
00:43:32,559 --> 00:43:36,760
to have a look at. So the absolute simplest way

815
00:43:36,800 --> 00:43:40,119
of hosting this is to say, hey, it's just like

816
00:43:40,159 --> 00:43:45,000
you know, you're bundling your back end code with your

817
00:43:45,000 --> 00:43:47,360
front end code and publishing that as a single unit,

818
00:43:47,559 --> 00:43:50,119
deploy that into the cloud or wherever you deploy it,

819
00:43:50,320 --> 00:43:53,719
and then your back end just serves that, right. And

820
00:43:54,360 --> 00:43:56,039
challenge with that is is that every time you want

821
00:43:56,079 --> 00:43:57,320
to make a change to your front end, you have

822
00:43:57,360 --> 00:43:59,239
to redeploy your back end as well, and that's just

823
00:43:59,559 --> 00:44:02,639
very common. So what we typically see is that front

824
00:44:02,719 --> 00:44:05,440
end engineers they bundle their software and they deploy that

825
00:44:05,480 --> 00:44:10,039
to a CDN, and the back end is deployed, you know,

826
00:44:10,800 --> 00:44:13,719
via a different channel, and they might even have different cadences.

827
00:44:13,760 --> 00:44:17,920
It depends on how you structure your organization.

828
00:44:18,199 --> 00:44:20,039
Speaker 2: You would hope like that's kind of a cool thing,

829
00:44:20,119 --> 00:44:23,239
right in my perfect world, As a new version of

830
00:44:23,280 --> 00:44:26,159
the client is coming up, the back end's already been deployed.

831
00:44:26,519 --> 00:44:28,639
It's been running for a while, well just with some

832
00:44:28,760 --> 00:44:29,440
dark features.

833
00:44:29,679 --> 00:44:33,519
Speaker 3: Sure, I mean, but when you make a new version,

834
00:44:33,800 --> 00:44:36,760
right you can You know, if you work, for example,

835
00:44:36,760 --> 00:44:39,159
in a mono RepA where both your front end code

836
00:44:39,199 --> 00:44:41,199
and your back end code is in the same repository,

837
00:44:42,159 --> 00:44:44,440
you could have some logic in your bill pipeline that says,

838
00:44:44,480 --> 00:44:46,639
if only a change happens in the back end code,

839
00:44:46,719 --> 00:44:48,599
I will only deploy the back end if it change

840
00:44:48,639 --> 00:44:49,960
only happens in the front end code.

841
00:44:50,079 --> 00:44:51,400
Speaker 1: Yeah. That scares me.

842
00:44:51,480 --> 00:44:53,360
Speaker 2: I think I want my back end and it container

843
00:44:53,400 --> 00:44:54,639
my front and deployed a CD end.

844
00:44:54,760 --> 00:44:54,960
Speaker 1: Yeah.

845
00:44:55,000 --> 00:44:56,719
Speaker 3: Yeah, but you can still do that. But then you

846
00:44:56,719 --> 00:45:01,519
can have different deployment pipelines for each of them. Now,

847
00:45:02,480 --> 00:45:05,400
so what you then still have a choice, And the

848
00:45:05,519 --> 00:45:08,559
choice is because your code is running in a CD

849
00:45:08,679 --> 00:45:11,559
and your your BFF is running UH and a container

850
00:45:11,559 --> 00:45:13,920
app somewhere, you still have the choice to say the

851
00:45:13,960 --> 00:45:16,760
initial request and the domain name where you're going to

852
00:45:17,360 --> 00:45:19,440
is that owned by the b f F or is

853
00:45:19,480 --> 00:45:22,599
that owned by the front end. Now, the difference is

854
00:45:22,599 --> 00:45:24,639
is that if it's owned by the front end, you're

855
00:45:24,679 --> 00:45:28,000
going to to the CDN directly, so to speak, and

856
00:45:28,039 --> 00:45:30,760
then you're getting the index ahe tmail there, and then

857
00:45:30,800 --> 00:45:34,199
you want to do calls to the BFF that has

858
00:45:34,320 --> 00:45:39,639
to be on the same what we call the same site.

859
00:45:39,719 --> 00:45:44,000
It can be a subdomain, but a site unfortunately is

860
00:45:44,079 --> 00:45:48,159
defined as top level domain minus one, so it also

861
00:45:48,320 --> 00:45:52,199
can include subdomains there. So within subdom you can say,

862
00:45:52,519 --> 00:45:55,880
I've got you know API dot my company dot com,

863
00:45:55,880 --> 00:45:58,599
and I've got you know frontend dot A my company

864
00:45:58,639 --> 00:46:01,880
dot com. And they can share cookies, they can send

865
00:46:01,880 --> 00:46:04,440
cookies to each other if you can figure that correctly.

866
00:46:04,480 --> 00:46:06,880
Speaker 1: If it was easy, we could buy it at seven eleven. Right.

867
00:46:07,000 --> 00:46:08,760
That's why developers.

868
00:46:09,079 --> 00:46:11,960
Speaker 3: The other option and that's the one that I personally prefer,

869
00:46:12,079 --> 00:46:15,079
but you know that's just me. Is that you go

870
00:46:15,199 --> 00:46:18,960
to your BFF. The BFF serves the index document, which

871
00:46:18,960 --> 00:46:20,840
it gets from the CDN by the way, but it

872
00:46:20,840 --> 00:46:24,360
can catch that. And then in the index document you

873
00:46:24,519 --> 00:46:27,119
have all the links to your CDN and that can

874
00:46:27,199 --> 00:46:29,920
be just in an other domain, it doesn't really matter.

875
00:46:30,039 --> 00:46:32,280
That's just static content that gets loaded from your CDN.

876
00:46:32,760 --> 00:46:35,000
And then you have also the option to inject some

877
00:46:35,119 --> 00:46:37,639
script in your in your htmail page if you want to.

878
00:46:37,719 --> 00:46:40,559
You have a little bit more flexibility in you know,

879
00:46:41,599 --> 00:46:46,559
setting up some things and you don't have to you know,

880
00:46:46,840 --> 00:46:51,199
the secured communication is always going onto the same same

881
00:46:51,239 --> 00:46:54,079
domain name, so that's kind of nice. So that's my preference,

882
00:46:54,199 --> 00:46:56,000
but you know, you can you can decide how you

883
00:46:56,039 --> 00:46:57,840
want to deploy these these things.

884
00:46:57,960 --> 00:47:01,519
Speaker 1: I'll stick with your preference. Thank you very much. The

885
00:47:01,679 --> 00:47:05,719
tried and true. Right, what's next for you? What are

886
00:47:05,719 --> 00:47:07,719
you what's coming up in your inbox?

887
00:47:07,840 --> 00:47:11,320
Speaker 3: All right, Well, we're working on two big releases. Access

888
00:47:11,320 --> 00:47:14,280
to com Management fee for is going to come out.

889
00:47:14,719 --> 00:47:17,719
And you know access to com Management has been you know,

890
00:47:17,800 --> 00:47:21,360
originally created by Dom and Brock and it's it's quite

891
00:47:21,719 --> 00:47:24,039
you know, quite an old library. It's been it's been

892
00:47:24,079 --> 00:47:25,800
around for quite a while and it's been of course

893
00:47:25,880 --> 00:47:29,480
updated to the latest specifications. But now we're finding that

894
00:47:29,519 --> 00:47:31,360
we you know, we want to update it a little

895
00:47:31,360 --> 00:47:34,639
bit more to also the most modern coding standards. So

896
00:47:34,679 --> 00:47:37,199
that's the thing that we're that we're working on. And

897
00:47:37,280 --> 00:47:39,400
we're working on b f F FEE for which which

898
00:47:39,440 --> 00:47:42,000
includes that multi funt ten support. So that's going to

899
00:47:42,079 --> 00:47:45,480
come out fairly soon and it's also quite a big release.

900
00:47:45,639 --> 00:47:47,320
Speaker 1: Well when did when did three come out?

901
00:47:47,519 --> 00:47:49,960
Speaker 3: Actually? I think two months ago.

902
00:47:49,920 --> 00:47:53,239
Speaker 1: So okay, so back in like February.

903
00:47:52,840 --> 00:47:55,079
Speaker 3: Yeah, February March timeframe, I think.

904
00:47:55,239 --> 00:47:57,519
Speaker 2: So yeah, okay, you guys are on a fast cadence

905
00:47:57,519 --> 00:47:59,679
then if you're digging before.

906
00:48:00,239 --> 00:48:02,760
Speaker 3: That's the advantage when you know d when they went

907
00:48:02,960 --> 00:48:07,639
commercial obviously, right, I mean before it was just Dominic

908
00:48:07,719 --> 00:48:10,320
and Brock working on this in the spare time that

909
00:48:10,360 --> 00:48:13,480
they had between consultancy engagements. And now there is just

910
00:48:13,519 --> 00:48:16,199
a fully flexed company with an amazing team. You know,

911
00:48:16,280 --> 00:48:17,599
dom and Brock are still there.

912
00:48:17,440 --> 00:48:19,760
Speaker 1: With a development team that can work full time and

913
00:48:19,800 --> 00:48:20,559
they're going to keep.

914
00:48:20,400 --> 00:48:23,800
Speaker 3: Coming alutely absolutely, and you know, we can just provide

915
00:48:23,840 --> 00:48:27,639
better support, faster feature delivery, and you know, we've got

916
00:48:27,679 --> 00:48:29,920
a great team working on it. So it's yeah, going

917
00:48:29,920 --> 00:48:30,440
pretty well.

918
00:48:30,400 --> 00:48:32,800
Speaker 2: And still with a community option if you're small, but

919
00:48:32,840 --> 00:48:36,079
if you're making money off this stuff, contribute, Yeah.

920
00:48:35,840 --> 00:48:36,880
Speaker 3: Yeah, absolutely, it's.

921
00:48:36,760 --> 00:48:39,039
Speaker 1: A good model. Yeah. Or when it's been a delight

922
00:48:39,119 --> 00:48:40,400
talking to you, thank you very.

923
00:48:40,360 --> 00:48:42,320
Speaker 3: Much, Thank you so much. It was great to be

924
00:48:42,360 --> 00:48:43,079
on the show.

925
00:48:43,280 --> 00:48:45,079
Speaker 1: All right, and we'll see you next time.

926
00:48:45,239 --> 00:49:05,800
Speaker 4: I will talk to you next time on dot net frocks.

927
00:49:08,119 --> 00:49:10,840
Speaker 1: Dot net Rocks is brought to you by Franklin's Net

928
00:49:10,920 --> 00:49:14,840
and produced by Pop Studios, a full service audio, video

929
00:49:14,960 --> 00:49:19,039
and post production facility located physically in New London, Connecticut,

930
00:49:19,280 --> 00:49:24,079
and of course in the cloud online at pwop dot com.

931
00:49:24,280 --> 00:49:26,400
Visit our website at d O T N E t

932
00:49:26,639 --> 00:49:30,679
R O c k S dot com for RSS feeds, downloads,

933
00:49:30,840 --> 00:49:34,519
mobile apps, comments, and access to the full archives going

934
00:49:34,559 --> 00:49:37,920
back to show number one, recorded in September two thousand

935
00:49:37,960 --> 00:49:40,599
and two. And make sure you check out our sponsors.

936
00:49:40,760 --> 00:49:43,719
They keep us in business. Now go write some code,

937
00:49:44,119 --> 00:49:44,880
see you next time.

938
00:49:45,800 --> 00:50:01,480
Speaker 3: You got jam vanst the Bos