Speaker 1: How'd you like to listen to dot net rocks with
Speaker 1: no ads? Easy? Become a patron for just five dollars
Speaker 1: a month. You get access to a private RSS feed
Speaker 1: where all the shows have no ads. Twenty dollars a month,
Speaker 1: we'll get you that and a special dot net Rocks
Speaker 1: patron mug. Sign up now at Patreon dot dot NetRocks
Speaker 1: dot com. Hey, it's dot net rocks one more time.
Speaker 1: I'm Carl Franklin, an amateur camp and man, we are
Speaker 1: getting ready to go to build, aren't we getting there? Yeah?
Speaker 1: Now that's just about that time.
Speaker 2: There's a lot of you know, for me, I'm organizing
Speaker 2: a dozen podcasters so right, and a bunch of different teams.
Speaker 1: So it's an adventure. This is something that we did
Speaker 1: in the past together and then you sort of just
Speaker 1: took it over, which is fine because you've got all
Speaker 1: of the podcasts wrangled from not just dot net, right,
Speaker 1: and not just Microsoft, yeah, specifically not just dot net. Yeah.
Speaker 2: We got a bunch of YouTubers well coming out this time,
Speaker 2: Tim Corey, who has been on the show not.
Speaker 1: In a long time anyway.
Speaker 2: I love Tim Corey and Derek co Martin, which we
Speaker 2: had on recently coming as well. We got one video
Speaker 2: studio as well as a few audios do. Yeah, very cool.
Speaker 2: So here's the deal, listeners. If you are going to
Speaker 2: be at build, find us.
Speaker 1: Yeah. Do you have any idea physically where we're going
Speaker 1: to be.
Speaker 2: Yeah, we're on the fourth floor, okay, which is the
Speaker 2: community area. We're off on one side there. You'll find
Speaker 2: us easy enough. We're there.
Speaker 1: Yeah, stop in and say hi. Yep. All right, let's
Speaker 1: get busy with better know a framework. Awesome? All right,
Speaker 1: what do you got? So? I'm having a lot of
Speaker 1: fun with a sister podcast Security this week, which is myself,
Speaker 1: Patrick Hines and Dwayne Laflatte. And if you don't know
Speaker 1: who these guys are, Patrick Hines was actually our first guests.
Speaker 2: Well he's now our lucky charm, right, he's the first
Speaker 2: guest on all shows we make it seems that's right.
Speaker 1: He was your first guest on run As and I
Speaker 1: think he was the first guest on Mondays too. I'm
Speaker 1: not sure, but anyway, Patrick is a veteran and a
Speaker 1: security expert, and Dwayne is his Red team leader. They
Speaker 1: basically do penetration tests for customers. You know, customer says
Speaker 1: go ahead, try to hack us and you know, try
Speaker 1: to be all clever, and Dwayne was like, okay, done.
Speaker 1: So it's just and here's the thing about Security this Week,
Speaker 1: which is just the podcast name and Security this Week
Speaker 1: dot Com is the page we laugh far more than
Speaker 1: we should be laughing while talking about hacks that have
Speaker 1: happened at the end of the universe. Yeah, because what
Speaker 1: we're talking about is fundamentally scary, you know. Yeah. Sure,
Speaker 1: security can be very frightening. Yeah, if you think your
Speaker 1: passwords are safe. Mmm. So we have, you know, a
Speaker 1: lot of mantras that we say over and over again,
Speaker 1: like use a password manager and patch and update your
Speaker 1: firmware on your Wi Fi, you know thing whatever all
Speaker 1: the time. But I just wanted to mention we also
Speaker 1: have a Discord server and it's getting a lot of
Speaker 1: traction and we're even handing out swag which are lock
Speaker 1: pick sets. Oh yeah, with the Security this Week logo
Speaker 1: on them lock pick sets. Yeah. So, so if you
Speaker 1: go to Discord dot Security this Week dot com and
Speaker 1: don't put hddps in front of it or because it's
Speaker 1: a URL DNS router, so just go on your browser
Speaker 1: type Discord dot Security this week dot com. You'll get
Speaker 1: to our discord server and if you, you know, engage
Speaker 1: us and give us some things to think about, we'll
Speaker 1: send you a lock pick set cool and that's my
Speaker 1: better no framework, that's what you get. Who's talking to
Speaker 1: us today? Richard Grab a comment off for show nineteen
Speaker 1: forty eight. This is the one which is just a
Speaker 1: couple of weeks ago with Rob talking about his open
Speaker 1: source maintenance fee and Jimmy Scott had this comment back.
Speaker 1: He said, thanks for your time. Rob.
Speaker 2: We are users of wis, which is a product that
Speaker 2: Rob maintains, and I was concerned that wicks was going commercial.
Speaker 2: Like many others, we use numerous OS projects and I've
Speaker 2: suscribed to several of them. The fee is more than
Speaker 2: reasonable and we will be subscribing today.
Speaker 1: Awesome.
Speaker 2: Yeah, it was great, great news, and I was very
Speaker 2: you know, we've been battling with this problem talking about
Speaker 2: how we're going to create sustainable open source on it
Speaker 2: for years now. So yeah, Rob's approach, you know, and
Speaker 2: again I appreciate it. He's not just postulating. He set
Speaker 2: it up. He set it up how to do it
Speaker 2: through githubs so you can learn everything you need to
Speaker 2: do about it, and clearly Jimmy's taking advantage that. So Jimmy,
Speaker 2: thank you so much for your comment. And a copy
Speaker 2: of music Goby is on its way to you. And
Speaker 2: if you'd like a copy of music Go Buy, I
Speaker 2: write a comment on the website dot NetRocks dot com
Speaker 2: or on the facebooks. We publish every show there and
Speaker 2: if you comment there and a reading the show will
Speaker 2: send you copy Music to Go Buy.
Speaker 1: Yeah, And I just wanted to say I'm standing by
Speaker 1: sort of watching how it unfolds with other people other
Speaker 1: than Rob and this guy or through the only two
Speaker 1: people that I know who are using is systems. So
Speaker 1: but I plan on jumping in as soon as I
Speaker 1: see happy customers. So also a reminder that Music to
Speaker 1: Code By is still going strong with twenty two tracks
Speaker 1: and you can download the whole collection in MP three
Speaker 1: flak or wave at music tocode by dot net. Awesome. Yeah,
Speaker 1: and with that, do you want to do the history thing?
Speaker 1: Are we done with it? Oh? That's a great idea.
Speaker 1: I didn't. I didn't have time to assemble anything. But
Speaker 1: it's nineteen fifty. I mean, what can we say, yes
Speaker 1: besides el Wells or beginning of the Korean War.
Speaker 2: Oh that that would be one.
Speaker 1: There was that, yeah, yeah, okay.
Speaker 2: But also the very first credit card, the Diner's Card,
Speaker 2: no kidding, is nineteen fifty yeah, I said, sort of famous.
Speaker 2: It's it's not an apocryphal story, but it's supposed to
Speaker 2: be true that Frank McNamara. It was this sales guy
Speaker 2: got his wallet in a different suit, took out his clients,
Speaker 2: and his wife had to pay. He didn't have any
Speaker 2: money on him, and thought, well, it's got to be
Speaker 2: a better way and work with a group of folks,
Speaker 2: including Alfred Bloomingdale, who was the heir to the Bloomingdale
Speaker 2: d department store. So got it into Bloomingdale's right away
Speaker 2: and it kicked that whole thing off. Of course, the
Speaker 2: big card, what became Visa, comes along later in nineteen
Speaker 2: towty eight.
Speaker 1: So did you say it was the diners Club.
Speaker 2: That's what became Diner's Club, but at the time it
Speaker 2: was called Diner's Card.
Speaker 1: The Diner's Card.
Speaker 2: Interesting, and it was again focused on restaurants initially, although
Speaker 2: rapidly branched into retail.
Speaker 1: So you know, we're getting out of like the war
Speaker 1: as well, we're getting into via the not the Vietnam,
Speaker 1: the Korean War, but and more interesting things are happening
Speaker 1: in compute around this time. Do you have any computer
Speaker 1: kind of history.
Speaker 2: The only comput story that's like a lot of things
Speaker 2: will happen in the fifties but in fifty is not
Speaker 2: a bunch except that at the Canadian World Exposition in
Speaker 2: nineteen fifty they had a computer they called Birdie the
Speaker 2: Brain and it played tic tac toe. Wow, And apparently
Speaker 2: there was huge cues of people to play tic tac
Speaker 2: toe against Berdie the Brain.
Speaker 1: Wow. That's cool. Silly but yeah, no, that was silly
Speaker 1: but cool.
Speaker 2: And you know that all the write ups talk about
Speaker 2: it being artificial intelligence, but none of the stuff at
Speaker 2: the time called it artificial intelligence. Yeah, which is Bertie
Speaker 2: the Brain. They just called it tic tac toe. Okay,
Speaker 2: So with that, I'm going to introduce Erwin. Erwin van
Speaker 2: der Walk is an experienced software engineer with the passion
Speaker 2: for software design, development practices and web security. He works
Speaker 2: as a principal engineer at Dwende Software and is the
Speaker 2: product owner for the Dwende BFF That's not Best Friends Forever,
Speaker 2: That's back in for front End Security Library and the
Speaker 2: popular open source library dwende access token management. In his
Speaker 2: spare time, he tries to learn as much as possible
Speaker 2: about pretty much anything and everything tech, science, history, and
Speaker 2: all things metal, listening, playing guitar, and fighting with historically
Speaker 2: accurate long's words.
Speaker 1: Well there's a hobby for you.
Speaker 3: Yeah.
Speaker 1: I don't even know what that means, but uh, welcome, Irwin.
Speaker 1: I recently learned what dwen day is. Like, I'm not
Speaker 1: the company, but the word. It's a Spanish word that means,
Speaker 1: you know, it's sort of what do they what do
Speaker 1: they call it? It's it's it's sort of a way
Speaker 1: of life, right day. You would call something dwende if
Speaker 1: it's amazing, if it's awesome, Yeah, that's the idea. Yeah,
Speaker 1: so welcome, Well, thank you very much.
Speaker 3: I'm super excited to be on the show. A long
Speaker 3: time listener, so.
Speaker 1: Yeah, we're super excited to have you BFF. Back End
Speaker 1: for front end. Yeah, and why why is it back
Speaker 1: end for front end and not just back end?
Speaker 3: Well, they call it back and for front end because
Speaker 3: tied to a particular front end, you have to have
Speaker 3: one back end if you have a micro services or
Speaker 3: just an appropriately sized services architecture, behind it. You can
Speaker 3: have many services behind your front end, but in this
Speaker 3: particular case, you only have one back end for that
Speaker 3: front end. And you know, the back end for front
Speaker 3: end pattern itself has been also around for quite a
Speaker 3: long time, and in this particular case, we're explicitly talking
Speaker 3: about adding the security layer on top of that. That's
Speaker 3: also how the if the Internet Engineering Task Force defined
Speaker 3: it now, but originally it was just if you have
Speaker 3: multiple different types of front ends, maybe a mobile, maybe
Speaker 3: a web application, you would build a specific back end
Speaker 3: for that one front end. And in this particular case,
Speaker 3: it's kind of similar, but you have a back end
Speaker 3: for a particular front end, but also to provide it
Speaker 3: with the authentication services.
Speaker 1: So with MVC fall into that category, and MVC server
Speaker 1: because if you think about it, it's serving up hdmun
Speaker 1: JavaScript and front end stuff.
Speaker 3: I think the primary goal is to look at what
Speaker 3: we call browser based application. So it's a little bit
Speaker 3: more like you know, spas applications built with React Angular Blazer,
Speaker 3: those type of applications that live primarily in the browser.
Speaker 3: They don't necessarily need a one single backhand for them.
Speaker 3: I mean, they could use any types of back ends,
Speaker 3: but in this particular case, and yeah, maybe it's good
Speaker 3: to dive into why we need that thing in the
Speaker 3: first place. It is to prevent you from using access
Speaker 3: tokens in the browser. Now why would you want that,
Speaker 3: Because for a long time, using access tokens in the
Speaker 3: browser has been a recommended practice. Right, There's all these
Speaker 3: libraries that are out there to handle those in JavaScript.
Speaker 3: And that's because the field of security is constantly evolving, right.
Speaker 3: I mean, things that were just completely valid in the
Speaker 3: past of implicit grand flow for example, is now totally
Speaker 3: not recommended anymore because you know, just clear security vulnerabilities
Speaker 3: have been discovered in.
Speaker 1: Yeah, you're increasing the surface, the attack surface by allowing
Speaker 1: hackers to get in there and mess with the tokens
Speaker 1: and try to spoof your back end and all of that,
Speaker 1: all the things that hackers do.
Speaker 3: Absolutely And there's the problem, right because within a browser
Speaker 3: based application, all the code for that one application is
Speaker 3: just mashed together in the same sandbox this week. So
Speaker 3: if a hacker is able to inject code in there,
Speaker 3: and unfortunately they do. Injection attacks are still the opity
Speaker 3: top three absolutely issue. It just happens a lot. Then
Speaker 3: an attacker can do exactly what your application is able
Speaker 3: to do as well. Now, if that is just impersonating
Speaker 3: you while you have your browser online, that's already a problem.
Speaker 3: And sure there are ways that you can limit the
Speaker 3: attack surface. Then, but if the attacker is able to
Speaker 3: take an access token and take that offline, even when
Speaker 3: you close down your browser, he's still able to impersonate you,
Speaker 3: or even worse right, take what we call a refresh
Speaker 3: token and be able to get more and more access
Speaker 3: tokens all the time, then you really have a problem
Speaker 3: if that happens.
Speaker 1: But these things are require like a sort of a
Speaker 1: man in the middle attack, right, This isn't something that
Speaker 1: you're going to pick up some malware and somebody's going
Speaker 1: to steal your tokens and whatever. Somebody has to really
Speaker 1: target you, don't they.
Speaker 3: Well, it is so easy to make a small mistake
Speaker 3: while building your web application that opens you up to
Speaker 3: cross side scripting attacks. Yeah, I myself not too long
Speaker 3: ago found out that if you have a URL and
Speaker 3: you add that URL into an image tag all of us,
Speaker 3: and that URL comes from another source, that URL could
Speaker 3: contain script and that will immediately be executed. So immediately
Speaker 3: that turns it into a cross side scripting attack. I
Speaker 3: didn't know that, and the library at the time React
Speaker 3: doesn't handle that particular case. It does when you bind
Speaker 3: a textbox to some data, but it doesn't handle that
Speaker 3: particular problem.
Speaker 1: So so you're saying that I could have you know,
Speaker 1: IMG source equals HTDP Joe's discount, sharkcages dot com, slashcage
Speaker 1: one dot jpeg, and that jpeg could no a jpeg
Speaker 1: could contain a script or is it more like a
Speaker 1: script tag that loads a JavaScript file from some other site.
Speaker 3: This particular example is a URL that contains script itself.
Speaker 3: So it's not necessarily even a URL. It doesn't even
Speaker 3: start with htps or something, but it just contains script.
Speaker 3: And if you put that into an image tag, it
Speaker 3: gets executed and you have a vulnerability.
Speaker 1: Oh if you put it into an image to ic.
Speaker 1: So if you set the source for an image tag
Speaker 1: to a script file, the script is going to get executed.
Speaker 3: Yes, And this is just one tiny example. I mean,
Speaker 3: when you build a browser based application using React or something,
Speaker 3: you get a million node files. How do you know
Speaker 3: that not one of those tiny node files has a problem.
Speaker 2: I wish you were exaggerating that it was a million
Speaker 2: node files, because you're right, so it's so many.
Speaker 3: So here's the point, right, I mean, if you do
Speaker 3: everything perfect, then doing what we call public client public
Speaker 3: client authorization code flow works and it's secure. But as
Speaker 3: soon as you have a tiny little hole in your
Speaker 3: browser based security, then what you want to do is
Speaker 3: put layers in there. Security is all about adding more
Speaker 3: layers and reducing the blast radius if something goes wrong.
Speaker 1: Right, and before you go down that rabbit hole, let
Speaker 1: me just say that it's not just a mistake that
Speaker 1: you could make. But in your software bill of materials,
Speaker 1: which you have right everybody listening, yes, all right, that
Speaker 1: is all of the dependencies that you are taking on
Speaker 1: in that list, and that list, as Richard said, could
Speaker 1: be millions of JavaScript files down the line. And there's
Speaker 1: been examples of these where we've depended on a particular
Speaker 1: JavaScript library and that library contained a bug and everything crashed.
Speaker 1: You're depending on those things, and how are you going
Speaker 1: to know if somebody gets in there maliciously does a
Speaker 1: pull request and approves it and absolutely Bob's your uncle,
Speaker 1: and you won't know.
Speaker 3: Exactly so, and it doesn't even have to be that right,
Speaker 3: script injection attacks is just one of the vectors. I mean,
Speaker 3: not too long ago, we had Spector. Right, Spector was
Speaker 3: a processor based issue. There's a proof of concept that.
Speaker 1: It was a vulnerability in the micro code of Intel processors.
Speaker 3: Exactly. There was a proof of concept out there that
Speaker 3: proved that by somehow from one browser window to another
Speaker 3: browser window, they could find poke into the memory of
Speaker 3: the other browser window. Now that's scary as well, right,
Speaker 3: I mean, the point that I'm making is that you
Speaker 3: have code running that you know, comes from all kinds
Speaker 3: of sources, maybe even you know, add links or whatever. Right,
Speaker 3: it comes from all kinds of sources, just execute together,
Speaker 3: and anything that that code does, it will you know
Speaker 3: that the code can do, you know it might do.
Speaker 3: And that's that's a problem. So the BFF pattern comes
Speaker 3: in to try and help that. Now, like I mentioned,
Speaker 3: the i ETF Enginet Engineering Task Force. That's the group
Speaker 3: that's responsible for creating all of these standards in the
Speaker 3: first place. Right, they created the OALTH to specification, open
Speaker 3: and deconnect all of that, and every now and then
Speaker 3: they come out with what they call a best current
Speaker 3: Practice document and in there they try to document well,
Speaker 3: you know, looking at the landscape, looking at what we
Speaker 3: know right now, what is what do we recommend and
Speaker 3: what don't we recommend. And one of the things that
Speaker 3: they're recommending is to use the BFF pattern. If you
Speaker 3: look at it, the BFF pattern consists of a couple
Speaker 3: of things. The first thing really important is that the
Speaker 3: authentication needs to happen on the server. So in the
Speaker 3: server you have what we call a confidential client, and
Speaker 3: the confidential client handles all of the authentication with your
Speaker 3: identity provider. Now the browser is still involved, but not
Speaker 3: the browser based application. It's not the JavaScript based So
Speaker 3: all that the front end has to do is redirect
Speaker 3: to a log in page or the logout page, and
Speaker 3: the server then takes care of the rest. After the
Speaker 3: authentication has completed. What the server then does is it
Speaker 3: places a cookie on your machine. Now, cookies have a
Speaker 3: bit of a bad rep for privacy reasons, of course,
Speaker 3: but also you know, for a cross side request forgery attacks,
Speaker 3: and we might get into those in a little bit
Speaker 3: in a minute, but they're very easily to protect you
Speaker 3: against those actually pretty much. Yeah, but cookies have been
Speaker 3: around for a long time and actually they you know,
Speaker 3: when you apply them properly. They're actually really secure. Sure,
Speaker 3: so what happens if you set your cookie to HTTP only.
Speaker 3: That means that your JavaScript can't reach them, and they're
Speaker 3: just added by the browser implicitly. Now, you can also
Speaker 3: set some policies on there, like same site policies, maybe
Speaker 3: even underscore underscore host prefix. It's a little bit technical,
Speaker 3: but all these flags that you can turn onto your
Speaker 3: cookies so that it's more difficult for attackers to to
Speaker 3: you know, accidentally get access to those things.
Speaker 1: Got to keep the cookie monster away.
Speaker 3: Yeah, but then once you've once you've configured those cookies correctly,
Speaker 3: the authentication just happens. Any call that you make to
Speaker 3: your backhand service is just authenticated automatically in a simple
Speaker 3: application what you just mentioned, right, just an MVC application,
Speaker 3: but then maybe one that exposes APIs the authentication just flows.
Speaker 3: Everything's fine, But now if you want to access external services,
Speaker 3: you know, micro services that you have running somewhere else,
Speaker 3: you don't want the cookie to flow over there because
Speaker 3: it can't read those cookies, can't do anything with them there.
Speaker 1: So you need some federated kind of multiple server communication
Speaker 1: going on.
Speaker 3: Right, Yeah, Well, what you then do is you exchange
Speaker 3: the cookie for an access token, and from that point
Speaker 3: on you just have a request from the BFF to
Speaker 3: your API using access tokens. And that's just a very
Speaker 3: well known pattern to flow, just credentials and information and
Speaker 3: security context. Yeah, okay, that is pretty much it. I mean,
Speaker 3: there's more that you can add to that.
Speaker 1: But so the access tokens are kind of made up
Speaker 1: on the fly, whereas the cookie identifies you to your server. Yeah,
Speaker 1: but when you say exchange, you mean, hey, this is
Speaker 1: me because I have this cookie, you know who I am.
Speaker 1: Give me an authentication token that I can use over
Speaker 1: in this API.
Speaker 3: Yes, yeah, and you can still have the choice. I mean,
Speaker 3: some APIs they don't want what we call a user
Speaker 3: based a token, right, They just want to have a
Speaker 3: client credentials token and that's it. You might want to
Speaker 3: have a token that's very narrow for that one particular service,
Speaker 3: because you might want to have multiple tokens for different services,
Speaker 3: and some other service might actually want to have a
Speaker 3: token with the subject identifier in it and all kinds
Speaker 3: of claims in there as well.
Speaker 1: So we're really talking about authorization at this point, not authentication.
Speaker 1: You're authenticated by that cookie. Now authorization takes on this
Speaker 1: whole other topic.
Speaker 3: Well, think about it from the perspective of your API.
Speaker 3: You're still authenticating, right, because a request comes in, there's
Speaker 3: an access token that says who is calling this thing?
Speaker 3: And that may just be hey, it's just a BFF
Speaker 3: that's calling you. Trust a BFF, right, do your thing,
Speaker 3: But it may also be no, this is an access
Speaker 3: token that has user information in it, so a subject identifier,
Speaker 3: maybe all kinds of other claims that then the might
Speaker 3: also use to make coarse grained authorization decisions.
Speaker 1: Sure, sure, okay, So.
Speaker 3: Now on top of that, you can also look at sessions. Now,
Speaker 3: the cookie, that's the thing that identifies you as a
Speaker 3: but you can store information in the cookie. If you
Speaker 3: wanted to, you could store the access token in the cookie.
Speaker 3: Now it's still secure. It goes to the browser, but
Speaker 3: the browser based application can't reach it, and then that's sorry.
Speaker 3: The advantage of that is is that your BFF is
Speaker 3: relatively stateless, right, it doesn't need to store that session
Speaker 3: information somewhere. But if you were to store that session
Speaker 3: information in a database, then you can also do things
Speaker 3: like remote sign out, for example, because if you delete
Speaker 3: the record from the database, the user is signed out
Speaker 3: and you can't access to the system anymore and needs
Speaker 3: to log back in again. So there are benefits and
Speaker 3: downside of store. You know, your your session information in
Speaker 3: a database.
Speaker 1: Sure, and if you have something like Blazer server you
Speaker 1: can use or server based stuff. You can use a
Speaker 1: protected browser storage, which I guess gives you what five
Speaker 1: megabytes of encrypted data on the on the browser per
Speaker 1: user per r L. Yeah. Yeah.
Speaker 3: The downside of of these storages in the browser is
Speaker 3: that it is still the browser application that reaches into that.
Speaker 3: And there's been quite a number of things that have
Speaker 3: been tried to to do that. I mean storing things
Speaker 3: inside of web workers to to keep them, keep them hidden,
Speaker 3: you know, encrypted storage, all of that stuff. But ultimately,
Speaker 3: if the browser based application can reach it, you know,
Speaker 3: you're exposing that information also to potentially malicious actors.
Speaker 1: I remember one thing that Dom I think it was dumb,
Speaker 1: it might have been Brock said, these are the one
Speaker 1: day guys over and over again, is that you want
Speaker 1: your authorization system to be totally separate from your authentication system. Yes,
Speaker 1: you know want those two tied together. And in what
Speaker 1: is the asp net core identity where you have just
Speaker 1: these databases that do that hold both the authentication passwords,
Speaker 1: hashes and also you know, claims, roles and that kind
Speaker 1: of stuff. You're really kind of tying the two together.
Speaker 1: And I didn't really understand what he meant by that,
Speaker 1: but but I get it that that having it separate
Speaker 1: just it doesn't tie them together.
Speaker 3: Yeah. I think the key thing to keep in mind
Speaker 3: here is that what you get from your identity provider,
Speaker 3: and maybe you layer a little bit on top of
Speaker 3: that inside of your application, and you could do that
Speaker 3: in the BFF as well. Should say something about the
Speaker 3: user itself. Right, So I am irwin, I have you
Speaker 3: know this role in the organization, right, But as soon
Speaker 3: as you start to think about other things like I
Speaker 3: have created this particular document, or I am a manager
Speaker 3: of that particular department, and therefore I that is not
Speaker 3: information that you want to store and managing your identity provider.
Speaker 3: That's not part of your identity. That's much more part
Speaker 3: of your application domain. And therefore those authorization decisions you
Speaker 3: do not want to take purely based on information that's
Speaker 3: stored in your cookie and sorting your access token, you
Speaker 3: actually want to say no no, no, I am. I'm
Speaker 3: defining what we call a policy, and that policy says,
Speaker 3: am I allowed to do this given who I am?
Speaker 3: And then inside of the code that executes that policy,
Speaker 3: you can do lookups like are you the right manager
Speaker 3: for this particular thing? Do you have access to that thing.
Speaker 1: If you're rolling your own Well, but I've seen many
Speaker 1: customers and I do this myself, is that you have
Speaker 1: you know, your your aspnet user's table in identity Core
Speaker 1: ASPN Core Identity and then basically what we would do
Speaker 1: is create a separate user's table that has all the
Speaker 1: application specific data about that user, and then it's related
Speaker 1: with a foreign key to that aspnet user in case
Speaker 1: you know, so that that's how they're tied together, but
Speaker 1: they're still in the same database.
Speaker 3: Yeah, and authorization can become really complex.
Speaker 1: Right.
Speaker 3: You can imagine inside of a big enterprise, one system
Speaker 3: controls this particular aspect, that other system controls that particular aspect.
Speaker 3: Now there are these systems, you know, policy server being
Speaker 3: one of them as an example, right, that might actually say, okay,
Speaker 3: you replicate some of the information that's part of your
Speaker 3: domain into that server and then you know, since that
Speaker 3: information is also stored in there. You can create association
Speaker 3: is there. You can say, because this particular person has
Speaker 3: this role, this relationship with that other thing, that's why
Speaker 3: he's allowed to do these particular things, and those things
Speaker 3: can inherit from each other. You can basically model your
Speaker 3: authorization domain, but that is only if you have an
Speaker 3: application landscape that is complex enough to warrant extracting that.
Speaker 1: Multiple applications from the same vendor. For example. Yeah, and
Speaker 1: some customers have access to this application and that application,
Speaker 1: but not that one.
Speaker 2: But I also look at it from a administrative versus
Speaker 2: regular user role within an app or you can even
Speaker 2: be more gradiated that HR can see some things that
Speaker 2: sales can't see, Like you need to have someplace for
Speaker 2: all of those different levels of authorization to live.
Speaker 3: Yeah, and you know, in an enterprise, what you typically
Speaker 3: see is that, you know, especially if the enterprise has
Speaker 3: built their own custom software for certain types of things,
Speaker 3: that it really warrants you to store that that centrally.
Speaker 3: Sometimes you literally have islands where each application stores its
Speaker 3: own and has its own logic.
Speaker 1: Around right, yeah, right, you want to take a break,
Speaker 1: or yeah, it's a good time. Oh well, yeah, okay,
Speaker 1: we'll take a break. We'll be right back after these
Speaker 1: very important messages. Stay tuned. Do you have a complex
Speaker 1: dot net monolith you'd like to refactor to a micro
Speaker 1: services architecture? The micro Service Extractor for dot Net tool
Speaker 1: visualizes your app and helps progressively extract code into micro services.
Speaker 1: Learn more at aws dot Amazon dot com, slash modernize
Speaker 1: and we're back. It's dot NetRocks. I'm Carl Franklin. That's
Speaker 1: my friend Richard Campbell. Hey, and that's our friend Erwin
Speaker 1: van Dervach from Duende. We're talking about interestingly enough policy
Speaker 1: server and why it's such a good idea to separate
Speaker 1: authorization policies from authentication databases.
Speaker 3: Yeah, and of course you really have to think, you know,
Speaker 3: how complex is your application and do you need to
Speaker 3: externalize those decisions? And then you know, is it complex
Speaker 3: enough that you need a product for that, because.
Speaker 2: There's an awful lot of cases where identity enough and
Speaker 2: authorization are essentially identical. You identify with this so you
Speaker 2: get all right, so this app. There is no granularization
Speaker 2: of the rights within the app.
Speaker 1: Yeah, and if it's complex enough, you'll know, Yeah, absolutely,
Speaker 1: you'll fit that point.
Speaker 2: It's one of those things where the moment I want
Speaker 2: to granularize the rights within an app, I probably should
Speaker 2: have a.
Speaker 1: Place for all that stuff to live.
Speaker 3: Yeah, coming back to the BFF pattern, right, one of
Speaker 3: the things I mentioned is c surf protection. You know,
Speaker 3: the challenge with issuing cookies is that cookies are sent
Speaker 3: automatically when the browser makes a request to a particular domain.
Speaker 3: And the challenge there could be is that if a
Speaker 3: malicious actor lures you your users to a malicious site
Speaker 3: and he then makes a call from that malicious site
Speaker 3: to your application, you don't want, you know, authorized requests
Speaker 3: to be sent. Now, browsers already have pretty good protection
Speaker 3: baked in there, I mean, and also there's a process
Speaker 3: for that, what we call cross origin resource sharing. You
Speaker 3: can define policies around that course to define well is
Speaker 3: this allowed or not. But unfortunately, there are a couple
Speaker 3: of holes that are still allowed by the course you know,
Speaker 3: that wouldn't trigger a course policy check, and that could
Speaker 3: potentially be dangerous.
Speaker 1: Allow all for example, Well.
Speaker 3: That's if you have a course policy in the first place.
Speaker 3: But what I'm talking about here is that there are
Speaker 3: certain requests that the browser deemed safe and therefore won't
Speaker 3: trigger a course check, and because of that, you know
Speaker 3: you could be in trouble. Now, to be fair, dot
Speaker 3: net already does a pretty good job of protecting you
Speaker 3: against those because they those type of requests would be gets.
Speaker 3: Now gets shouldn't manipulate states, so you shouldn't be able
Speaker 3: to get into trouble with those. And they can be
Speaker 3: simple posts, but as soon as you try to do
Speaker 3: a post with a specific content type, that's when you
Speaker 3: know the course policy would be would be triggered.
Speaker 1: For example.
Speaker 3: Now, some frameworks, you know, some server side frameworks, they
Speaker 3: don't do a very good job of checking those content types.
Speaker 3: But dot Net, by default, if you say, hey, you know,
Speaker 3: I'm expecting a post that's just an adjacent document, you know,
Speaker 3: it will not accept it if it's not adjacent post.
Speaker 1: Is it just raise an error?
Speaker 3: Yeah, it would just say hey, this is the wrong
Speaker 3: content type, I go away.
Speaker 1: Yeah.
Speaker 3: Right, So fortunately dot net also helps you with that.
Speaker 3: But again, right, security is about more layers. So there's
Speaker 3: a very simple way of tackling this. Now, Microsoft provides
Speaker 3: you with se SERF protection, right, so cross side request
Speaker 3: forger reprotection, but it is based on encryption, and you
Speaker 3: need to specify the data protection keys and all your servers,
Speaker 3: and if you make a mistake there, you know it
Speaker 3: doesn't work. But the very simple thing is just to
Speaker 3: say in your BFF server to demand that a specific
Speaker 3: header is there. And I'm saying specific header. It really
Speaker 3: doesn't matter what the header is as long as it's
Speaker 3: a custom header. So your front end just always sends
Speaker 3: that header, no problem, right, It could be you know
Speaker 3: x SE serf equals one, doesn't matter, right, Your front
Speaker 3: end just always sends that. If the malicious site wants
Speaker 3: to call your service, it doesn't have that header, so
Speaker 3: it will that your your BFF will say I'm not
Speaker 3: letting you in. If the malicious site then tries to
Speaker 3: add that header, now you're adding a custom header to
Speaker 3: the request and that triggers the course policies in a browser,
Speaker 3: so it stops all the sea surf attacks dead. So
Speaker 3: just by demanding in your server you must have a
Speaker 3: custom header, and as long as you have an agreement
Speaker 3: between your backhand and your front end, hey, send that header.
Speaker 1: You're safe.
Speaker 3: That's kind of cool.
Speaker 1: That's kind of cool.
Speaker 2: And can you read something in that header that's like
Speaker 2: a security key or something not easily spoofed.
Speaker 3: You don't have to. That's the thing. I mean, this
Speaker 3: confused me in the beginning quite a bit because I thought, well.
Speaker 1: Why headers or headers? They should be able to make
Speaker 1: anything I want.
Speaker 3: Yeah, But the point is is that the browser standards
Speaker 3: they dictate that if you do a cross origin call
Speaker 3: and you do that with a specific header, that first
Speaker 3: you must do a course policy check and then that
Speaker 3: course policy comes into play. Now, if you screw up
Speaker 3: your course policy, if you say course policy allow all, sure,
Speaker 3: you're still vulnerable. But here's the point, right, if you
Speaker 3: do it correctly, then you're secure. And by default, by
Speaker 3: the way, if you don't specify a course policy, the
Speaker 3: course policy is deny. So you're pretty secure if you
Speaker 3: don't do anything there. There's a couple of other things
Speaker 3: that you could look at. I mean, Blazer support is
Speaker 3: an interesting one. I Mean, the thing with Blazer is
Speaker 3: is that it's a really powerful framework, but because of
Speaker 3: all of its rendering modes, you have to pay attention, right,
Speaker 3: I mean, if you're doing purely service side rendering, then
Speaker 3: you're just building a regular application. But if you start
Speaker 3: mixing those interactivity modes, especially in the auto rendering mode.
Speaker 3: Then some communication might go over web sockets, some communication
Speaker 3: might be with web requests, and yeah, you just have
Speaker 3: to you know, look at all, how are you going
Speaker 3: to set the you know, as soon as you start
Speaker 3: doing web requests, right, so regularates to be requests. Yeah,
Speaker 3: you just have to make sure that you're calling it
Speaker 3: with the right credentials. Now, inside of the do end,
Speaker 3: the BFF framework, the one that I'm responsible for as well,
Speaker 3: we try to make sure that that is all unified
Speaker 3: so that you just have a single programming model that
Speaker 3: you can code in your Blazer back end, in your
Speaker 3: front end, and the auto rendering modes just work work seamlessly.
Speaker 3: But if you don't use that framework, if you just
Speaker 3: want to build your own then of course. And if
Speaker 3: you do use Blazer, then that's one thing to watch
Speaker 3: out for as well.
Speaker 2: And does the Blazer mode matter, like you have to
Speaker 2: be in client mode for this to make sense or
Speaker 2: do It'll work the same either way.
Speaker 3: Now, well, so here's the thing. Right with the auto
Speaker 3: rendering mode. If you say I want to display a
Speaker 3: list on the screen, there's three things that can happen.
Speaker 3: One is it get rented on the server, and that's
Speaker 3: actually what happens initially, right, it's rented on the server
Speaker 3: and then send to the browsers HTML. So then you
Speaker 3: need to have on the server. You need to be
Speaker 3: able to get to that data. That might either be
Speaker 3: just go directly to the database because you're in the
Speaker 3: same space, or you're doing a call to an external service,
Speaker 3: and therefore you need to make sure that there's an
Speaker 3: access token on the ah top client to call that
Speaker 3: external service. When you are in interactive mode, right, so
Speaker 3: it's running on the in the it switches over to
Speaker 3: web assembly mode. Then all of a sudden, it's the
Speaker 3: browser that does that request, right, And you can't go
Speaker 3: from the browser directly to that API in point because
Speaker 3: first of all, it might just be in an internal network, right,
Speaker 3: the browser doesn't have access directly to that API in
Speaker 3: point right, And second of all, you don't have that
Speaker 3: access token. You don't want that access token there, so
Speaker 3: then you need to proxy that request using a reverse
Speaker 3: proxy through the BFF, and then the BFF does that token,
Speaker 3: the cookie exchange for the token, and then goes out
Speaker 3: to that external service. So that's how that's supposed to
Speaker 3: work together.
Speaker 2: Then as well, trying to figure out how much work
Speaker 2: I actually have to do to implement this framework. It
Speaker 2: sounds almost like a drop in thing and that should
Speaker 2: be good to go.
Speaker 3: Yeah, I mean, if you want to build it yourself,
Speaker 3: then of course you need to know what you're doing,
Speaker 3: and you know, Microsoft provides a bunch of things, but.
Speaker 1: That's never stopping before or when.
Speaker 3: Come on, yeah, of course, but I mean you know
Speaker 3: you need to You can use YARP, that's a really
Speaker 3: good reverse proxy. I mean, you can use the Microsoft
Speaker 3: libraries for that. We provide an open source library for
Speaker 3: access token management, so that there's a bunch of things
Speaker 3: that you can do, and if you know what you're doing,
Speaker 3: then you can just do that. If you rather use
Speaker 3: a product, then of course, you know, we provide a
Speaker 3: product that you can also. You know, if you uh,
Speaker 3: it is.
Speaker 1: A new GET package, right like this isn't it.
Speaker 3: It's just a new Get packaging. You plug it in
Speaker 3: with a couple of lines of code, you have it working,
Speaker 3: and you know, we have a community license as well,
Speaker 3: so that if you uh, you know, I think it's
Speaker 3: if you make less than a couple of million of years,
Speaker 3: then you can just use the product for free. Right
Speaker 3: if you make over that then you know, you pay
Speaker 3: a little bit and then you get a nice product
Speaker 3: for that.
Speaker 2: So yeah, no, and you said, drop in a couple
Speaker 2: of configuration things. You're working and you've you're using this
Speaker 2: whole TLS approach, like your life is better.
Speaker 3: Absolutely. Now there's one thing that we're also working on,
Speaker 3: and it kind of bleeds into more operations, right because
Speaker 3: if you have a purely browser based application, you can
Speaker 3: just host that on a CD and and you know,
Speaker 3: run that somewhere and now all of a sudden, you
Speaker 3: do need a back end component for that. Now, if
Speaker 3: you do that for your first application, you have a
Speaker 3: really nice you know, you've got a nice back end
Speaker 3: for your front end. It's all good. But typically, you know,
Speaker 3: especially enterprises, they have a lot of applications and then
Speaker 3: they come to the conclusions like I have a lot
Speaker 3: of BFFs here, you know, can't we do anything about that? Right,
Speaker 3: So one of the things that we're about to release
Speaker 3: is multi front end support as well, So you can
Speaker 3: have a single BFF that just you know, from the
Speaker 3: perspective of the front end, it is just a single
Speaker 3: back end for front end, but physically it's a single
Speaker 3: host that can serve many of.
Speaker 2: Them, right, so you don't end up with one for
Speaker 2: every app, which can get untenable. You have exactly collective
Speaker 2: because they're all using the same right sets and so forth. Like,
Speaker 2: this is all very shareable, and I suspet it's like
Speaker 2: ninety five percent in common between apps and there's just
Speaker 2: a few exceptions.
Speaker 3: Yeah, exactly. Now, now there's a couple of other things
Speaker 3: that I mean, I've applied this pattern a lot of
Speaker 3: times already in my career, and one of the things
Speaker 3: that I'm finding is that it also helps my collaboration
Speaker 3: with front end developers. I mean, I am primarily a
Speaker 3: back end developer. I know enough about a front end
Speaker 3: to being dangerous, but primarily a back end developer. But
Speaker 3: when I'm working with front end developers, it's really nice
Speaker 3: to have what I typically call then a dev server.
Speaker 3: Nowadays you would build that with Aspire. You have something
Speaker 3: that front end engineers can just run and it's just
Speaker 3: just running there nicely, and they can iterate on building
Speaker 3: their front ends. And as a back end engineer, I
Speaker 3: mean I just spin up the front end and my
Speaker 3: back end is there, and I can iterate on my
Speaker 3: back end. And if you have a branch. Where you
Speaker 3: have both of them, you can easily work together on
Speaker 3: them with the front end. You compare program. Hey, I
Speaker 3: build this in the front end, build this in the
Speaker 3: back end, work together. It's just a really nice flow
Speaker 3: to to collaborate together.
Speaker 2: So and then is the BFF security framework. It's again,
Speaker 2: it's just a new GET package. So is it just
Speaker 2: a line in Aspire to say include this and just
Speaker 2: another part of the equation.
Speaker 3: Right now, it is just a new GET package that
Speaker 3: you need to install inside of your web application. In
Speaker 3: the near future, yes, it's going to be just a
Speaker 3: container that you can just run and aspire and from
Speaker 3: that point on you can use that as a development experience.
Speaker 1: Very cool. Yeah, I'd like it. I just like that
Speaker 1: in my template.
Speaker 2: I'm thinking, I'm thinking very enterprising here about how do
Speaker 2: I get my devs on the path to using these
Speaker 2: tools from the outset?
Speaker 3: Yeah, yeah, absolutely, And that's exactly what we see people
Speaker 3: do for this, and you know, and there's nice tricks
Speaker 3: that you can do there with that, because one of
Speaker 3: the things that you know, as a back end engineer,
Speaker 3: I don't sometimes even have all the front end tools installed,
Speaker 3: and there's like a gazillion of them. So what I
Speaker 3: typically do then.
Speaker 1: Is again not an exaggeration, no, and gazillion.
Speaker 3: So when I just start up the back end, it
Speaker 3: just loads the most recent front end from my dev
Speaker 3: environment in the clouds. It gets it from a CDN
Speaker 3: right right. But then if I start up both of them,
Speaker 3: I can detect, hey, the front end code is running locally.
Speaker 3: Let me just take the front end code locally and
Speaker 3: serve that from there instead of them from the CDN server.
Speaker 3: So that's a really nice experience. Then. You know, if
Speaker 3: I don't care about the front end, I can just
Speaker 3: start it up. If I do care about it, especially
Speaker 3: when working together, you start them up both and they
Speaker 3: just start working together. That's a really nice experience there
Speaker 3: as well.
Speaker 2: For sure, What about the telemetry side, is there any
Speaker 2: information coming out of this framework that helps me as
Speaker 2: an on the administrator side knowing what privileges are being
Speaker 2: gained and so forth.
Speaker 1: Is that still be part of the regular system.
Speaker 3: Yeah, that's the actual authentication bit. I mean, we track
Speaker 3: how many tokens are being exchanged, and we do metrics
Speaker 3: for those type of things. And of course if you
Speaker 3: use service side sessions, you know exactly how many people
Speaker 3: are online at any point in time, so you can
Speaker 3: also do metrics for those, but actually publishing these metrics
Speaker 3: as open telemetry is something that we haven't built in yet, right,
Speaker 3: And there is a reason for that as well, is
Speaker 3: that all of the traffic between your front end and
Speaker 3: your APIs flows through the BFF, so it has to
Speaker 3: reverse proxy those otherwise the cookie won't flow and therefore
Speaker 3: the reverse proxy is very secured, very performance sensitive. I mean,
Speaker 3: you don't want delays in there for reasons. So if
Speaker 3: you were to add if we were to add code
Speaker 3: in there that says every five minutes, look how many
Speaker 3: users there are, look how many you know, and publish
Speaker 3: those as statistics, right, we might, you know, negatively impact
Speaker 3: your performance. So we don't want to do that obviously.
Speaker 2: Sure, I'm just thinking about additional telemetry you'd have access to,
Speaker 2: just because you can see these tokens flowing around. But yeah,
Speaker 2: and it's always a debate as to how much what
Speaker 2: do you want, Like where is that?
Speaker 1: What is that useful for?
Speaker 3: Absolutely?
Speaker 2: Certainly when you're trying to do a call chain, knowing
Speaker 2: what token was issued, when it was issued, when it expired,
Speaker 2: like that's all part of that chain.
Speaker 3: Oh yeah, well, and access to cam management does alog
Speaker 3: quite a lot of information.
Speaker 2: Yeah, that's the thing that's a lot of that's already
Speaker 2: handled for you. Absolutely not your problem. You're just calling
Speaker 2: into those services.
Speaker 3: Technically, it's my problem because I'm also the product owner
Speaker 3: for access to com management.
Speaker 2: Well you're also the COGA provider. But that's not the
Speaker 2: security framework's fault. No, exactly, exactly. Now I'll get that
Speaker 2: telemetry for identity server. Yeah, but I mean, yeah, I'm
Speaker 2: just thin get through all the issues.
Speaker 3: No, absolutely, absolutely so.
Speaker 1: Yeah, So is there anything that we missed, any gotchas
Speaker 1: that people might run into, or any other issues around
Speaker 1: this BFF pattern that people find tricky.
Speaker 3: Well, I mean there's a couple of ways that you
Speaker 3: can host this really in production that might be interesting
Speaker 3: to have a look at. So the absolute simplest way
Speaker 3: of hosting this is to say, hey, it's just like
Speaker 3: you know, you're bundling your back end code with your
Speaker 3: front end code and publishing that as a single unit,
Speaker 3: deploy that into the cloud or wherever you deploy it,
Speaker 3: and then your back end just serves that, right. And
Speaker 3: challenge with that is is that every time you want
Speaker 3: to make a change to your front end, you have
Speaker 3: to redeploy your back end as well, and that's just
Speaker 3: very common. So what we typically see is that front
Speaker 3: end engineers they bundle their software and they deploy that
Speaker 3: to a CDN, and the back end is deployed, you know,
Speaker 3: via a different channel, and they might even have different cadences.
Speaker 3: It depends on how you structure your organization.
Speaker 2: You would hope like that's kind of a cool thing,
Speaker 2: right in my perfect world, As a new version of
Speaker 2: the client is coming up, the back end's already been deployed.
Speaker 2: It's been running for a while, well just with some
Speaker 2: dark features.
Speaker 3: Sure, I mean, but when you make a new version,
Speaker 3: right you can You know, if you work, for example,
Speaker 3: in a mono RepA where both your front end code
Speaker 3: and your back end code is in the same repository,
Speaker 3: you could have some logic in your bill pipeline that says,
Speaker 3: if only a change happens in the back end code,
Speaker 3: I will only deploy the back end if it change
Speaker 3: only happens in the front end code.
Speaker 1: Yeah. That scares me.
Speaker 2: I think I want my back end and it container
Speaker 2: my front and deployed a CD end.
Speaker 1: Yeah.
Speaker 3: Yeah, but you can still do that. But then you
Speaker 3: can have different deployment pipelines for each of them. Now,
Speaker 3: so what you then still have a choice, And the
Speaker 3: choice is because your code is running in a CD
Speaker 3: and your your BFF is running UH and a container
Speaker 3: app somewhere, you still have the choice to say the
Speaker 3: initial request and the domain name where you're going to
Speaker 3: is that owned by the b f F or is
Speaker 3: that owned by the front end. Now, the difference is
Speaker 3: is that if it's owned by the front end, you're
Speaker 3: going to to the CDN directly, so to speak, and
Speaker 3: then you're getting the index ahe tmail there, and then
Speaker 3: you want to do calls to the BFF that has
Speaker 3: to be on the same what we call the same site.
Speaker 3: It can be a subdomain, but a site unfortunately is
Speaker 3: defined as top level domain minus one, so it also
Speaker 3: can include subdomains there. So within subdom you can say,
Speaker 3: I've got you know API dot my company dot com,
Speaker 3: and I've got you know frontend dot A my company
Speaker 3: dot com. And they can share cookies, they can send
Speaker 3: cookies to each other if you can figure that correctly.
Speaker 1: If it was easy, we could buy it at seven eleven. Right.
Speaker 1: That's why developers.
Speaker 3: The other option and that's the one that I personally prefer,
Speaker 3: but you know that's just me. Is that you go
Speaker 3: to your BFF. The BFF serves the index document, which
Speaker 3: it gets from the CDN by the way, but it
Speaker 3: can catch that. And then in the index document you
Speaker 3: have all the links to your CDN and that can
Speaker 3: be just in an other domain, it doesn't really matter.
Speaker 3: That's just static content that gets loaded from your CDN.
Speaker 3: And then you have also the option to inject some
Speaker 3: script in your in your htmail page if you want to.
Speaker 3: You have a little bit more flexibility in you know,
Speaker 3: setting up some things and you don't have to you know,
Speaker 3: the secured communication is always going onto the same same
Speaker 3: domain name, so that's kind of nice. So that's my preference,
Speaker 3: but you know, you can you can decide how you
Speaker 3: want to deploy these these things.
Speaker 1: I'll stick with your preference. Thank you very much. The
Speaker 1: tried and true. Right, what's next for you? What are
Speaker 1: you what's coming up in your inbox?
Speaker 3: All right, Well, we're working on two big releases. Access
Speaker 3: to com Management fee for is going to come out.
Speaker 3: And you know access to com Management has been you know,
Speaker 3: originally created by Dom and Brock and it's it's quite
Speaker 3: you know, quite an old library. It's been it's been
Speaker 3: around for quite a while and it's been of course
Speaker 3: updated to the latest specifications. But now we're finding that
Speaker 3: we you know, we want to update it a little
Speaker 3: bit more to also the most modern coding standards. So
Speaker 3: that's the thing that we're that we're working on. And
Speaker 3: we're working on b f F FEE for which which
Speaker 3: includes that multi funt ten support. So that's going to
Speaker 3: come out fairly soon and it's also quite a big release.
Speaker 1: Well when did when did three come out?
Speaker 3: Actually? I think two months ago.
Speaker 1: So okay, so back in like February.
Speaker 3: Yeah, February March timeframe, I think.
Speaker 2: So yeah, okay, you guys are on a fast cadence
Speaker 2: then if you're digging before.
Speaker 3: That's the advantage when you know d when they went
Speaker 3: commercial obviously, right, I mean before it was just Dominic
Speaker 3: and Brock working on this in the spare time that
Speaker 3: they had between consultancy engagements. And now there is just
Speaker 3: a fully flexed company with an amazing team. You know,
Speaker 3: dom and Brock are still there.
Speaker 1: With a development team that can work full time and
Speaker 1: they're going to keep.
Speaker 3: Coming alutely absolutely, and you know, we can just provide
Speaker 3: better support, faster feature delivery, and you know, we've got
Speaker 3: a great team working on it. So it's yeah, going
Speaker 3: pretty well.
Speaker 2: And still with a community option if you're small, but
Speaker 2: if you're making money off this stuff, contribute, Yeah.
Speaker 3: Yeah, absolutely, it's.
Speaker 1: A good model. Yeah. Or when it's been a delight
Speaker 1: talking to you, thank you very.
Speaker 3: Much, Thank you so much. It was great to be
Speaker 3: on the show.
Speaker 1: All right, and we'll see you next time.
Speaker 4: I will talk to you next time on dot net frocks.
Speaker 1: Dot net Rocks is brought to you by Franklin's Net
Speaker 1: and produced by Pop Studios, a full service audio, video
Speaker 1: and post production facility located physically in New London, Connecticut,
Speaker 1: and of course in the cloud online at pwop dot com.
Speaker 1: Visit our website at d O T N E t
Speaker 1: R O c k S dot com for RSS feeds, downloads,
Speaker 1: mobile apps, comments, and access to the full archives going
Speaker 1: back to show number one, recorded in September two thousand
Speaker 1: and two. And make sure you check out our sponsors.
Speaker 1: They keep us in business. Now go write some code,
Speaker 1: see you next time.
Speaker 3: You got jam vanst the Bos