00:00:04.297 --> 00:00:05.447 Of our focus on security.
00:00:06.967 --> 00:00:08.167 Yeah, I mean.
00:00:13.307 --> 00:00:15.197 OK, so step one for security.
00:00:15.207 --> 00:00:17.387 Compare you with all of your web configs with the latest core.
00:00:20.537 --> 00:00:22.557 And I I I'm not kidding about that.
00:00:20.887 --> 00:00:21.087 Yeah.
00:00:22.567 --> 00:00:25.976 We've done a whole bunch of stuff that had to do with
00:00:25.976 --> 00:00:29.953 cybersecurity to make it so that the service don't expose what
00:00:29.953 --> 00:00:33.866 versions they're on, that it is IIS versus some other type of
00:00:33.866 --> 00:00:37.717 server, and all of the settings are in all of our latest web
00:00:37.717 --> 00:00:39.547 configs for the API services.
00:00:39.557 --> 00:00:44.573 DNN the UI folders that have them all that stuff because they
00:00:44.573 --> 00:00:49.426 were all capable of exposing the fact that it was a Windows
00:00:49.426 --> 00:00:53.633 Server of a certain version which would help the uh
00:00:53.633 --> 00:00:55.897 malevolent actors to target.
00:00:56.227 --> 00:00:59.633 What kinds of attacks they would make against the server, but by
00:00:59.633 --> 00:01:02.776 obfuscating all that info so it's no longer there, it makes
00:01:02.776 --> 00:01:06.181 it that much harder for them to figure out how to hack into said
00:01:06.181 --> 00:01:06.547 server.
00:01:11.417 --> 00:01:13.197 Yeah. Ah.
00:01:16.487 --> 00:01:20.717 Tristan, do you want to implement an endpoint?
00:01:20.727 --> 00:01:22.727 Show us how to lock it down or you want me to do.
00:01:24.117 --> 00:01:25.117 Sure, whatever works.
00:01:25.127 --> 00:01:29.377 Let me uh coupling up all the crap I have opened real quick.
00:01:29.387 --> 00:01:33.477 One SEC like 30 spreadsheets, 18 Visual Studio instances.
00:01:34.657 --> 00:01:34.877 Yeah.
00:01:37.627 --> 00:01:40.497 So which might contain passwords, so that's.
00:01:43.807 --> 00:01:44.677 The the, the, the, the.
00:01:45.267 --> 00:01:48.047 That would be funny to show your passwords and security training.
00:01:48.857 --> 00:01:49.037 If.
00:01:48.957 --> 00:01:50.117 Yeah, exactly.
00:01:50.127 --> 00:01:51.627 That would probably not be ideal.
00:01:53.317 --> 00:01:54.337 OK, cool.
00:01:56.337 --> 00:01:58.887 But how I pull up a project that's gonna be good?
00:01:58.897 --> 00:01:59.487 Template.
00:01:59.497 --> 00:02:01.027 That's somewhat latest.
00:02:01.117 --> 00:02:02.967 I'll just one SEC, see.
00:02:05.777 --> 00:02:06.157 Thanks.
00:02:13.997 --> 00:02:16.157 To make sure I have some some recent.
00:02:21.747 --> 00:02:22.647 Check it out.
00:02:25.137 --> 00:02:28.262 This will be based on the 2023.1, which is relatively
00:02:28.262 --> 00:02:28.667 recent.
00:02:34.507 --> 00:02:35.167 Do.
00:02:46.807 --> 00:02:47.327 Alrighty.
00:02:50.627 --> 00:02:51.717 You know the screen share.
00:02:55.417 --> 00:02:56.907 After my thing stopped.
00:02:56.917 --> 00:02:59.737 Reason that OK, there we go ship.
00:03:03.067 --> 00:03:03.517 Alright.
00:03:03.567 --> 00:03:04.167 Can you guys see that?
00:03:07.287 --> 00:03:07.627 Can.
00:03:09.357 --> 00:03:09.737 Cool.
00:03:09.747 --> 00:03:10.957 Let me go ahead and close all this.
00:03:11.257 --> 00:03:14.677 This so just gonna be confusing having too many things happen.
00:03:16.267 --> 00:03:17.497 Labs, all these guys down.
00:03:17.567 --> 00:03:18.087 OK, cool.
00:03:19.337 --> 00:03:22.637 So go ahead and open up the service layer.
00:03:23.827 --> 00:03:25.737 This is where a lot of endpoints live.
00:03:25.747 --> 00:03:28.257 There's endpoints that live also in the providers layer as well.
00:03:29.197 --> 00:03:29.497 Umm.
00:03:29.507 --> 00:03:31.967 Like sometimes there's queries, services or whatever.
00:03:31.977 --> 00:03:35.867 But uh, to keep stuff simple.
00:03:35.917 --> 00:03:39.887 Uh, we can look at this service layer.
00:03:39.897 --> 00:03:44.393 So I'm gonna take a look at just because I'm familiar with it,
00:03:44.393 --> 00:03:47.817 invoicing and what you'll and actually one SEC.
00:03:47.827 --> 00:03:51.302 Let me see if I can make my IDE bigger before because I'm
00:03:51.302 --> 00:03:54.117 realizing this is probably really hard to see.
00:03:56.077 --> 00:03:56.997 Ah, there we go.
00:03:57.067 --> 00:03:58.917 That should hopefully be more legible.
00:03:59.687 --> 00:04:01.547 Let me know if that's still still too small.
00:04:00.217 --> 00:04:00.497 And just.
00:04:04.127 --> 00:04:07.894 You can probably go up one more and just for the identification
00:04:06.437 --> 00:04:06.677 OK.
00:04:07.894 --> 00:04:08.717 for the video.
00:04:08.987 --> 00:04:12.594 Typically, if we're gonna the implement a new endpoint for a
00:04:12.594 --> 00:04:16.318 client, projects probably gonna live in a client override, and
00:04:16.318 --> 00:04:19.569 unless it's specific to a new provider or that we have
00:04:16.567 --> 00:04:16.777 Umm.
00:04:19.569 --> 00:04:21.697 implemented or something like that.
00:04:21.707 --> 00:04:23.767 But you can just throw it in services and be fine.
00:04:23.597 --> 00:04:24.227 Yeah, I don't.
00:04:24.277 --> 00:04:27.511 I don't have a client override for this, cause it's kind of
00:04:25.837 --> 00:04:26.237 Umm.
00:04:27.511 --> 00:04:30.691 like a core type thing, but yeah, you would generally have
00:04:30.691 --> 00:04:33.924 like an override project and you'd have endpoints living in
00:04:33.924 --> 00:04:34.247 there.
00:04:35.277 --> 00:04:38.956 This example would be like if you're adding a new core
00:04:38.956 --> 00:04:41.497 endpoint or amending one or whatever.
00:04:42.337 --> 00:04:45.353 So most of those are going live in the services layer under the
00:04:45.353 --> 00:04:46.107 service project.
00:04:46.537 --> 00:04:49.313 I'm going to be looking at invoicing specifically because
00:04:49.313 --> 00:04:52.328 there's more to do with like, hey, let's not let everyone just
00:04:52.328 --> 00:04:55.007 pull whatever invoice they want kind of thing in there.
00:04:55.597 --> 00:04:56.057 Umm.
00:04:56.627 --> 00:05:00.786 In the service layer service layer, you'll see these
00:05:00.786 --> 00:05:04.317 separated into generated and extended files.
00:05:05.027 --> 00:05:08.247 You'll see that a lot of these are generated and what you'll
00:05:08.247 --> 00:05:11.467 notice is if you open up one of these, zoom in here as well.
00:05:14.307 --> 00:05:14.817 Sure.
00:05:14.827 --> 00:05:15.377 There we go.
00:05:15.867 --> 00:05:19.461 And you go to the top, there's a little documentation and it says
00:05:19.461 --> 00:05:20.277 auto generated.
00:05:20.287 --> 00:05:22.875 That means don't touch this file, because whatever you
00:05:22.875 --> 00:05:23.957 change will go bye bye.
00:05:23.967 --> 00:05:28.137 If someone runs to you 4 hours, uh, so yeah, don't edit any of
00:05:28.137 --> 00:05:32.240 these generated files directly where you want to do is either
00:05:32.240 --> 00:05:35.217 create or go to an existing uh dot extended.
00:05:35.227 --> 00:05:38.977 So for example, if you want to do something sales invoices,
00:05:38.977 --> 00:05:42.727 you'd create sales invoice service dot extended dot CS, uh.
00:05:42.737 --> 00:05:44.907 Luckily for us, we have that file here.
00:05:45.337 --> 00:05:45.557 See.
00:05:45.567 --> 00:05:46.917 It doesn't say it's auto generated.
00:05:46.927 --> 00:05:51.367 This is an endpoint as someone had built out explicitly.
00:05:52.317 --> 00:05:56.970 So for example, this end point gets sales invoice payments for
00:05:56.970 --> 00:05:58.447 the current account.
00:05:58.957 --> 00:06:02.409 Obviously I'm kind of just assuming that based off of the
00:06:02.409 --> 00:06:05.980 name, but as I'm sure we've mentioned 1000 times, go ahead,
00:06:03.387 --> 00:06:03.847 Uh.
00:06:05.980 --> 00:06:06.337 sorry.
00:06:06.057 --> 00:06:08.267 Whoever wrote that didn't apply.
00:06:08.277 --> 00:06:11.127 The thing that enforces that on the actual query.
00:06:13.367 --> 00:06:18.567 Well, we that is, that is the thing I will.
00:06:21.567 --> 00:06:21.847 Yeah.
00:06:21.857 --> 00:06:23.207 Well, so getting there.
00:06:24.667 --> 00:06:28.848 But yeah, so given that we're talking about security, I guess
00:06:28.848 --> 00:06:32.691 we don't necessarily need to go into the nitty gritty of
00:06:32.691 --> 00:06:34.107 endpoints themselves.
00:06:34.117 --> 00:06:38.136 However, usually they're locked down in the number of ways the
00:06:38.136 --> 00:06:41.772 first thing is they're usually locked to like a specific
00:06:41.772 --> 00:06:43.047 portal, for example.
00:06:43.057 --> 00:06:46.562 This used in storefront attribute says hey, the APA API
00:06:46.562 --> 00:06:49.127 storefront app pool is gonna serve this.
00:06:49.417 --> 00:06:52.047 So that's where this endpoint should be accessible.
00:06:52.337 --> 00:06:55.787 There's also using addendums files, so forget you.
00:06:55.877 --> 00:06:56.287 Let's see.
00:06:56.377 --> 00:06:57.347 Addendums.
00:06:57.937 --> 00:07:02.707 You'll see that there's a dot Brandon M in franchise and these
00:07:02.707 --> 00:07:07.629 are all different app pools that would be running that can serve
00:07:07.629 --> 00:07:11.717 these and these will also contain partial uh classes.
00:07:11.767 --> 00:07:14.663 Uh, that just have the the one attribute for used in admin or
00:07:14.663 --> 00:07:16.577 used the storefront or whatever on them.
00:07:17.587 --> 00:07:19.957 In this case, this one clearly used in storefront.
00:07:21.147 --> 00:07:23.778 Uh, it doesn't look like it's used in any other like used in
00:07:23.778 --> 00:07:26.323 addendum file, so we can assume this is only accessible to
00:07:26.323 --> 00:07:26.797 storefront.
00:07:27.687 --> 00:07:31.527 Umm, generally speaking, what you would probably want in here.
00:07:31.537 --> 00:07:33.862 I mean, I guess it has authenticate so only somebody's
00:07:33.862 --> 00:07:35.467 logged in should be able to use this.
00:07:36.197 --> 00:07:40.417 But as James pointed out, there doesn't appear.
00:07:40.427 --> 00:07:43.652 I mean it says for current account, so we're going to dive
00:07:43.652 --> 00:07:46.057 into this, I guess real quick and just see.
00:07:48.557 --> 00:07:49.617 Umm, how does it know?
00:07:49.167 --> 00:07:52.302 If it's calling out of the service layer at all, then it
00:07:52.302 --> 00:07:54.997 can't possibly know what the current account is.
00:07:52.817 --> 00:07:53.047 Yeah.
00:07:55.067 --> 00:07:57.067 Any any layers deeper than it is?
00:07:56.297 --> 00:07:56.517 Yeah.
00:07:57.737 --> 00:07:58.187 Yeah.
00:07:58.197 --> 00:07:58.537 So we're.
00:08:01.187 --> 00:08:04.151 So basically before that called the workflow, you would just do
00:08:03.667 --> 00:08:04.337 That she.
00:08:04.151 --> 00:08:07.067 request DOT account ID equals current account ID or throw 401.
00:08:06.967 --> 00:08:07.277 Yeah.
00:08:07.287 --> 00:08:09.927 So just going off of the account ID on here.
00:08:09.307 --> 00:08:10.077 It's going off.
00:08:10.087 --> 00:08:12.037 Whatever you pass in. Yeah.
00:08:10.347 --> 00:08:12.087 Off the request, yeah.
00:08:12.047 --> 00:08:16.317 So you can you can happily pass in any anything you want.
00:08:13.037 --> 00:08:14.277 Yeah. So.
00:08:13.227 --> 00:08:13.467 They're.
00:08:17.487 --> 00:08:17.957 Yeah.
00:08:17.967 --> 00:08:22.470 So uh to explain, assuming this is someone who is not familiar
00:08:22.470 --> 00:08:22.827 with.
00:08:23.597 --> 00:08:24.327 So if what?
00:08:24.337 --> 00:08:27.757 What the issue is here is because we're essentially
00:08:27.757 --> 00:08:30.847 trusting the request body to get what we need.
00:08:31.797 --> 00:08:35.067 Uh, you could pass an any account identifier.
00:08:35.077 --> 00:08:38.249 That means like if I was a hacker, I could hit this end
00:08:38.249 --> 00:08:41.988 points as long as I'm logged in, cause all it has is authenticate
00:08:41.988 --> 00:08:42.327 right?
00:08:42.337 --> 00:08:44.737 Which means I am a user that is logged in.
00:08:44.747 --> 00:08:47.067 It doesn't matter if you're a guest or whatever role.
00:08:47.077 --> 00:08:47.887 It doesn't matter.
00:08:48.237 --> 00:08:53.298 I can pass in any account ID and just rip the payments for their
00:08:53.298 --> 00:08:56.957 sales invoices, which is obviously not a deal.
00:08:55.317 --> 00:08:56.237 Well, OK.
00:08:59.557 --> 00:09:03.792 Not quite the there's a lot of things going wrong with this
00:09:03.792 --> 00:09:04.427 endpoint.
00:09:04.907 --> 00:09:07.627 Umm 1 deep request?
00:09:09.687 --> 00:09:12.667 Yeah, the account ID is nowhere in this process.
00:09:14.327 --> 00:09:17.742 If you go back to how it's being implemented in the workflow, or
00:09:14.337 --> 00:09:14.687 Umm.
00:09:16.777 --> 00:09:16.977 Yeah.
00:09:17.742 --> 00:09:19.317 just bring it up side by side.
00:09:18.057 --> 00:09:19.197 Yeah, which is what I was looking for.
00:09:20.457 --> 00:09:22.487 Umm, you've got the sorts on it.
00:09:20.857 --> 00:09:21.097 It's just.
00:09:22.497 --> 00:09:28.637 You've got the umm, the groupings and you've got, uh,
00:09:28.637 --> 00:09:30.797 the paging, but OK.
00:09:30.807 --> 00:09:32.537 And then you have the request master ID there.
00:09:32.547 --> 00:09:35.771 The master ID on the sales invoice payment table is an
00:09:35.771 --> 00:09:39.522 invoice number, so you have to know the invoice number and then
00:09:39.522 --> 00:09:42.217 you can get the payments off of that invoice.
00:09:42.637 --> 00:09:42.837 Mm-hmm.
00:09:42.707 --> 00:09:46.640 To do that, nowhere in this is any of this enforcing or
00:09:46.640 --> 00:09:49.097 utilizing the account of anything.
00:09:48.407 --> 00:09:48.947 Yeah.
00:09:48.987 --> 00:09:53.369 So we're trusting the request to set an account to filter by
00:09:53.369 --> 00:09:54.087 basically.
00:09:53.487 --> 00:09:57.577 It's not using it because hmm.
00:09:55.047 --> 00:09:57.644 It's it's not setting an account, it's setting an invoice
00:09:57.644 --> 00:09:59.747 ID and that's what it's passing to the server.
00:10:09.247 --> 00:10:09.937 Well, we are.
00:10:09.987 --> 00:10:10.567 Restaurant ID.
00:10:10.007 --> 00:10:11.367 Yeah, we are filtering.
00:10:10.247 --> 00:10:11.247 Yeah, and.
00:10:11.377 --> 00:10:13.097 Yeah, we are filtering by the search model.
00:10:13.107 --> 00:10:17.379 It's online 26 filter query by model extension, but it's still
00:10:13.577 --> 00:10:15.467 Ohh yeah OK, I see it.
00:10:14.877 --> 00:10:15.117 Yeah.
00:10:15.717 --> 00:10:16.427 Yeah.
00:10:16.517 --> 00:10:20.084 So if the account ID was on the search model, it would filter it
00:10:16.717 --> 00:10:17.987 Yeah. So.
00:10:17.379 --> 00:10:18.057 that it's.
00:10:18.147 --> 00:10:18.697 Well, umm.
00:10:19.267 --> 00:10:20.807 EE hold on.
00:10:20.084 --> 00:10:20.797 there, right?
00:10:21.767 --> 00:10:25.979 Even so, the account ID would never be on the search model
00:10:25.979 --> 00:10:29.547 because this is the sales invoice payments table.
00:10:29.827 --> 00:10:33.457 This is not the sales invoice table so.
00:10:32.507 --> 00:10:32.777 Yeah.
00:10:32.617 --> 00:10:32.957 Hmm.
00:10:32.617 --> 00:10:33.317 Yeah. OK.
00:10:32.787 --> 00:10:36.113 So basically what James is saying is that there is no there
00:10:36.113 --> 00:10:39.384 is no property you can set on that search model that would
00:10:39.384 --> 00:10:42.488 filter it by an account even regardless of how you pass
00:10:40.627 --> 00:10:40.747 Yeah.
00:10:42.488 --> 00:10:45.980 account ID in either from the service layer or from the front,
00:10:44.997 --> 00:10:45.227 Yeah.
00:10:45.980 --> 00:10:46.977 it doesn't matter.
00:10:46.407 --> 00:10:46.627 Yeah.
00:10:47.187 --> 00:10:49.787 There is no actual filtering going on for that.
00:10:47.737 --> 00:10:52.790 So this this entire file that is saying that is it an extension
00:10:52.790 --> 00:10:56.737 of sales invoice services is entirely misleading.
00:10:57.127 --> 00:11:01.153 This file is actually extending sales invoice payment services
00:11:01.153 --> 00:11:04.795 and should be owned to the payments folder and then from
00:11:02.377 --> 00:11:02.587 Umm.
00:11:04.795 --> 00:11:05.497 over there.
00:11:05.507 --> 00:11:06.377 That's where we start.
00:11:06.387 --> 00:11:09.878 Like trying to look at payment side stuff and manipulating it
00:11:09.878 --> 00:11:10.497 over there.
00:11:10.567 --> 00:11:13.816 So if we could move the file over there and rename it
00:11:13.816 --> 00:11:17.727 properly to more explicitly what it's supposed to be, I think we
00:11:17.727 --> 00:11:21.396 can get a better idea of where and what we're supposed to be
00:11:21.396 --> 00:11:21.817 fixing.
00:11:22.007 --> 00:11:23.477 So yeah, supposed to be in the payments folder.
00:11:23.857 --> 00:11:27.205 Yeah, and it should be like sales invoice payment service
00:11:27.205 --> 00:11:29.167 dot extended, I'm guessing right.
00:11:29.977 --> 00:11:30.137 Yes.
00:11:39.417 --> 00:11:45.275 Obviously, yeah, I know it does some of it for me, but I have to
00:11:45.275 --> 00:11:50.772 amend the documentation, sales, invoice, payment service and
00:11:46.197 --> 00:11:46.387 Yeah.
00:11:50.772 --> 00:11:55.187 then umm yes payment CRUD workflow still dot CS.
00:11:55.987 --> 00:11:58.007 Assume that's OK.
00:11:58.177 --> 00:12:03.277 I'm guessing we're gonna need to do is actually take in an actual
00:12:03.277 --> 00:12:08.222 account, identify or in here as well, cause as you said the the
00:12:06.617 --> 00:12:06.797 Yeah.
00:12:08.222 --> 00:12:12.162 the search model doesn't actually contain like any
00:12:12.162 --> 00:12:13.707 account identifiers.
00:12:13.717 --> 00:12:16.057 So see INT account ID.
00:12:14.587 --> 00:12:15.077 Yeah.
00:12:15.127 --> 00:12:18.157 So let's add the and.
00:12:18.447 --> 00:12:19.517 Yep, that'll work.
00:12:19.617 --> 00:12:21.487 And then you clone your parameter.
00:12:23.697 --> 00:12:28.007 Say the account identifier and then generally speaking.
00:12:30.137 --> 00:12:31.687 What we do, at least I see this.
00:12:31.697 --> 00:12:34.409 I don't know if this is necessary, but a lot of people
00:12:34.409 --> 00:12:37.267 do this just to make it more readable, you know, spacing.
00:12:35.927 --> 00:12:39.398 The Automan your documentation thing that I I tool that I used
00:12:39.398 --> 00:12:42.647 to generate those automatically aligns those up like that.
00:12:42.657 --> 00:12:45.423 That's part of how I have it formatted, which is why you'll
00:12:44.607 --> 00:12:45.517 Ohtomo and air.
00:12:45.423 --> 00:12:45.837 see that.
00:12:46.387 --> 00:12:46.557 Yeah.
00:12:47.127 --> 00:12:49.657 OK, it is nice.
00:12:48.417 --> 00:12:52.897 Umm, so now yeah, so we we now add the account ID on there and
00:12:49.667 --> 00:12:50.087 I like it.
00:12:52.897 --> 00:12:57.518 then over in the services layer you'll pass in the new parameter
00:12:57.518 --> 00:13:00.077 of current account ID or throw 401.
00:13:05.617 --> 00:13:06.177 Yeah, and.
00:13:06.087 --> 00:13:06.557 OK.
00:13:06.747 --> 00:13:09.337 That's that's the minimum to get what we want done.
00:13:09.347 --> 00:13:13.928 Now, however, there are there is the case of user emulation for
00:13:13.928 --> 00:13:18.079 people who are doing user emulation like in pay hub or in
00:13:18.079 --> 00:13:22.731 other things we need to swap out this thing using the local live
00:13:22.731 --> 00:13:26.739 in or account ID or 401 async wherein you would pass in
00:13:26.739 --> 00:13:31.463 request account ID and then null coalesce back to current account
00:13:31.463 --> 00:13:35.829 ID or their 401 as an argument in there and then pass in the
00:13:35.829 --> 00:13:40.123 account ID that you're going to result all of that into the
00:13:40.123 --> 00:13:40.767 function.
00:13:44.067 --> 00:13:48.909 So take the account ID property or a local variable name that
00:13:48.909 --> 00:13:53.750 you have and put that onto 33 and then inside the argument to
00:13:49.087 --> 00:13:49.327 Umm.
00:13:53.750 --> 00:13:58.669 the function online 30 before the current account ID or 401 do
00:13:58.669 --> 00:14:02.807 request dot account ID and then no coalesce to that.
00:14:05.457 --> 00:14:07.547 But it's not going to have an account of the search model.
00:14:07.557 --> 00:14:09.897 So what we have to amend this? Yeah.
00:14:08.497 --> 00:14:11.677 I I know type it anyway type it.
00:14:11.687 --> 00:14:12.387 Anyway, we're going to add.
00:14:11.827 --> 00:14:16.797 I things like that kind of thing.
00:14:15.217 --> 00:14:19.946 So you put that inside the, you know, put the request that
00:14:19.946 --> 00:14:25.075 account ID and double question mark inside the function call as
00:14:25.075 --> 00:14:26.197 the parameter.
00:14:30.647 --> 00:14:31.827 20 or whatever it would be.
00:14:32.907 --> 00:14:38.367 Yeah, there now on the endpoint line 23 is is the opening brace
00:14:38.367 --> 00:14:43.655 for the glass, make a new line there and then we're gonna add
00:14:43.655 --> 00:14:49.200 the property public INT account ID get set and you can make that
00:14:49.200 --> 00:14:49.967 nullable.
00:14:53.267 --> 00:14:58.197 Now, because it is an end, it is an endpoint with an API member.
00:14:58.527 --> 00:15:04.118 We should add a an API member attribute to the property so
00:15:04.118 --> 00:15:09.994 it'll be API member and then you'll open your parentheses and
00:15:09.994 --> 00:15:15.964 then you'll say name equal to name of account ID, it's capital
00:15:15.964 --> 00:15:16.437 name.
00:15:21.217 --> 00:15:23.447 And then the next argument do. Uh.
00:15:26.827 --> 00:15:29.147 Uh, it's I start having type.
00:15:29.187 --> 00:15:30.257 I think it's it's.
00:15:30.487 --> 00:15:34.432 It's two to two types there, umm data type and then you'll do
00:15:34.432 --> 00:15:38.313 equal to because the version that you're on, you should have
00:15:38.313 --> 00:15:39.267 access to this.
00:15:39.377 --> 00:15:43.037 Do Seth API, uh types.
00:15:44.267 --> 00:15:44.577 Yeah.
00:15:44.587 --> 00:15:46.827 So the API data types dot nullable int.
00:15:50.647 --> 00:15:53.327 There you go, noble integer and then comma space.
00:15:55.287 --> 00:15:56.237 A parameter type.
00:15:58.507 --> 00:16:00.567 Equal to Seth API parameter types.
00:16:04.067 --> 00:16:09.577 Dot body and then the next one is going to be is required
00:16:09.577 --> 00:16:10.147 false.
00:16:13.977 --> 00:16:18.170 And then the next one would be description and then we would
00:16:18.170 --> 00:16:22.225 put a description of the option as optional account ID for
00:16:22.225 --> 00:16:23.737 emulation enforcement.
00:16:32.747 --> 00:16:35.677 But obviously it's a bit of a run on so probably do is.
00:16:33.307 --> 00:16:33.467 Yeah.
00:16:35.297 --> 00:16:35.867 Yeah.
00:16:35.927 --> 00:16:39.507 So normally I would start wrapping.
00:16:39.847 --> 00:16:42.107 You know my arguments and the the thing in there and yeah,
00:16:42.107 --> 00:16:43.217 just get them all down there.
00:16:48.047 --> 00:16:49.407 Alright, cool.
00:16:48.577 --> 00:16:48.997 There you go.
00:16:51.267 --> 00:16:54.209 So essentially what we just did there, if someone knew is
00:16:54.209 --> 00:16:57.200 watching is we're adding a new property, the data transfer
00:16:57.200 --> 00:16:58.417 object that's coming in.
00:16:58.427 --> 00:17:01.316 Obviously we have like a search model which contains like hey
00:17:01.316 --> 00:17:04.344 you can filter by this or filter by that, but it doesn't include
00:17:04.344 --> 00:17:07.372 account identifier for payments cuz payments don't directly have
00:17:07.372 --> 00:17:10.120 an account or user or I guess sales invoice payments don't
00:17:10.120 --> 00:17:13.148 directly have an account or user identifier on them because it's
00:17:13.148 --> 00:17:15.617 kind of like it's kind of like a relationship table.
00:17:15.627 --> 00:17:19.435 It's it's not doesn't contain a lot of important things by
00:17:19.435 --> 00:17:23.179 itself other than saying, hey, this payment links to this
00:17:23.179 --> 00:17:27.180 invoice, but the invoice itself does have an account and user
00:17:27.180 --> 00:17:28.277 identifier on it.
00:17:29.617 --> 00:17:29.817 Yeah.
00:17:29.907 --> 00:17:33.246 Now what we're doing in here is we're saying, hey, let's get
00:17:33.246 --> 00:17:36.531 the, you know, account ID from the request or you know your
00:17:36.531 --> 00:17:37.187 current one.
00:17:37.197 --> 00:17:38.797 And we're gonna check if your local admin.
00:17:39.037 --> 00:17:42.654 Obviously we don't want anyone to be able to, umm, emulate
00:17:42.654 --> 00:17:45.167 another user because that would be dope.
00:17:45.177 --> 00:17:45.717 Weirdo.
00:17:46.207 --> 00:17:48.743 But if you're a local admin or affiliate admin, you can do
00:17:48.743 --> 00:17:48.957 that.
00:17:48.967 --> 00:17:50.857 It'll read the cookie and pull it out of there.
00:17:51.787 --> 00:17:52.277 Umm.
00:17:52.287 --> 00:17:57.875 So yeah, and then we're passing that into the workflow method
00:17:52.517 --> 00:17:52.637 Yeah.
00:17:57.875 --> 00:18:03.553 which we amended both by, you know, updating the interface for
00:18:03.553 --> 00:18:06.617 it and the actual implementation.
00:18:07.047 --> 00:18:10.674 And now what we need to do is we need to pass that account ID
00:18:10.674 --> 00:18:12.837 into the where I would assume right?
00:18:12.887 --> 00:18:13.597 Unless I'm.
00:18:13.877 --> 00:18:16.991 Unless there's like a filter by whatever thing for that, but
00:18:16.407 --> 00:18:19.107 Uh, there, there would be to filter by for that.
00:18:16.991 --> 00:18:17.807 given that it's.
00:18:19.557 --> 00:18:21.477 Umm, automatically.
00:18:21.767 --> 00:18:24.137 So let's go ahead and just add aware.
00:18:24.187 --> 00:18:26.549 Go ahead and add a second where cause I'm we're gonna change the
00:18:26.549 --> 00:18:26.767 where?
00:18:26.777 --> 00:18:28.207 That's there with something else.
00:18:29.077 --> 00:18:31.787 And so where request dot, master.
00:18:32.257 --> 00:18:32.937 I'm sorry.
00:18:33.977 --> 00:18:38.147 You're gonna pass in the stop, stop, stop.
00:18:39.887 --> 00:18:44.757 Uh, where request dot.
00:18:45.307 --> 00:18:45.997 Sorry, just talking.
00:18:46.007 --> 00:18:46.837 It's gonna be request.
00:18:46.847 --> 00:18:47.807 It's just gonna be account ID.
00:18:48.857 --> 00:18:55.295 Umm, so it's gonna be account ID is equal to X dot master dot
00:18:49.547 --> 00:18:49.767 Umm.
00:18:55.295 --> 00:18:56.437 account ID.
00:18:59.447 --> 00:19:01.267 And then you have to exclamation point after master.
00:19:02.597 --> 00:19:03.127 There we go.
00:19:03.307 --> 00:19:06.225 So that the master there is the invoice and the invoice does
00:19:06.225 --> 00:19:09.286 have account ID's on it and so that would be that it would have
00:19:09.286 --> 00:19:12.299 to have, you know, be part of that account ID and that will be
00:19:12.299 --> 00:19:13.207 part of the safety.
00:19:13.217 --> 00:19:16.916 Safety and since this is enforceable by the server to
00:19:16.916 --> 00:19:21.162 where you have to have, you have to be logged in, you have to
00:19:21.162 --> 00:19:25.066 have the affiliate role or whatever or it has to be your
00:19:25.066 --> 00:19:28.147 accounts data to pass through on that stuff.
00:19:28.157 --> 00:19:30.887 Now all that stuff would work technically correctly.
00:19:31.337 --> 00:19:34.957 There's a couple of things we need to change in the query here
00:19:31.547 --> 00:19:31.797 Umm.
00:19:34.957 --> 00:19:38.059 though, because they're not quite right one the apply
00:19:35.377 --> 00:19:35.617 OK.
00:19:38.059 --> 00:19:40.357 sorting, you should go below the wares.
00:19:39.567 --> 00:19:39.787 Yep.
00:19:44.977 --> 00:19:47.217 OK, two the.
00:19:49.027 --> 00:19:52.443 Master ID should be in the filter query by model extension
00:19:52.443 --> 00:19:55.858 async base which is gonna use the search model because the
00:19:55.858 --> 00:19:59.273 search model has messed ID and it should already have that
00:19:59.273 --> 00:19:59.967 stuff on it.
00:20:00.267 --> 00:20:06.061 So I don't know why they're repeating the master ID where
00:20:06.061 --> 00:20:12.453 here on this we can verify that by looking at the sales invoice
00:20:12.453 --> 00:20:17.547 payment search model extension that uses that one.
00:20:17.727 --> 00:20:22.412 So if you do and I don't know if it's control T inside this IDE,
00:20:22.412 --> 00:20:25.367 but the the thing that would find stuff.
00:20:25.907 --> 00:20:28.207 Uh, the uh.
00:20:26.357 --> 00:20:26.647 Umm.
00:20:28.527 --> 00:20:32.797 Do you filter a sales invoice payment?
00:20:35.477 --> 00:20:36.257 By search model.
00:20:38.937 --> 00:20:40.017 This is me, this top one here.
00:20:40.817 --> 00:20:41.047 Yeah.
00:20:41.057 --> 00:20:41.577 At the top one.
00:20:45.007 --> 00:20:45.417 OK.
00:20:45.427 --> 00:20:48.821 And you can see there on line 37, it's doing a filter by I am
00:20:48.821 --> 00:20:52.379 relationship table based search model and if we go into that one
00:20:52.379 --> 00:20:55.882 you should see that it should be using the master and the slave
00:20:55.882 --> 00:20:57.797 ID and master key slave key stuff.
00:20:58.127 --> 00:21:01.325 So because it's already handled here, we don't need to repeat
00:21:01.325 --> 00:21:03.387 that process in our own implementation.
00:21:04.637 --> 00:21:05.147 OK.
00:21:05.197 --> 00:21:05.337 Yeah.
00:21:06.357 --> 00:21:07.877 So we can actually just remove this line.
00:21:08.437 --> 00:21:09.647 Yeah, we can kill that.
00:21:09.657 --> 00:21:11.247 Where and if.
00:21:11.297 --> 00:21:14.654 If it hadn't been handled there, we would have would fix it so it
00:21:14.654 --> 00:21:15.467 could handle it.
00:21:15.537 --> 00:21:18.604 If this was something else where we had to write our own like
00:21:18.604 --> 00:21:21.571 filter by or use one that was supposed to be out of box but
00:21:21.571 --> 00:21:24.390 just hadn't been applied anywhere, I would have switched
00:21:24.390 --> 00:21:25.477 it to use a filter by.
00:21:25.957 --> 00:21:29.807 That was preexisting, or in another case we might have gone
00:21:29.807 --> 00:21:33.913 in and, like, actually written a new filter by so that we could
00:21:33.913 --> 00:21:35.517 apply it on to the thing.
00:21:36.177 --> 00:21:36.377 Mm-hmm.
00:21:37.747 --> 00:21:42.613 So what we've got here is it still it's selecting uh, they
00:21:42.613 --> 00:21:47.808 under the appropriate conditions and the right paging and such
00:21:47.808 --> 00:21:50.117 and under the right sorting.
00:21:51.227 --> 00:21:54.105 And then it goes and selects the slave itself, which is the
00:21:54.105 --> 00:21:57.223 payment, and then it maps it to a payment model in list mode and
00:21:57.223 --> 00:22:00.197 then gives those out as a list of results and then we get our
00:22:00.197 --> 00:22:02.067 accounts and all that stuff off of it.
00:22:02.077 --> 00:22:06.979 So that we have a payment page results coming back on that
00:22:06.979 --> 00:22:07.477 thing.
00:22:07.867 --> 00:22:11.655 Normally the workflows layer doesn't do the paged results
00:22:11.655 --> 00:22:14.527 part like the actual class of page results.
00:22:12.347 --> 00:22:12.577 Umm.
00:22:14.537 --> 00:22:20.195 It just gives back the the like instead of a task object here
00:22:20.195 --> 00:22:25.945 and for the return type it would return a tuple, a value tuple
00:22:25.945 --> 00:22:28.317 with three elements in it.
00:22:26.797 --> 00:22:27.177 Umm.
00:22:28.327 --> 00:22:31.697 It would be one is the list of results.
00:22:31.707 --> 00:22:37.152 As a result, umm collection, it would say a list of I payment
00:22:37.152 --> 00:22:40.927 model and the name of it would be results.
00:22:41.187 --> 00:22:42.137 The second one would be.
00:22:43.007 --> 00:22:46.984 Total pages and then the third one would be total count, which
00:22:46.984 --> 00:22:50.770 both of those would be integers and then in in the services
00:22:48.857 --> 00:22:49.177 OK.
00:22:50.770 --> 00:22:54.683 layer is where the page payment results would be and it would
00:22:54.683 --> 00:22:55.377 convert it.
00:22:55.467 --> 00:23:00.257 They just moved it down for some reason to here to get handled
00:23:00.257 --> 00:23:00.637 here.
00:23:00.647 --> 00:23:04.724 I don't know why because the payment page results class is
00:23:02.177 --> 00:23:02.437 OK.
00:23:04.724 --> 00:23:08.247 supposed to exist in the service dot core project.
00:23:09.017 --> 00:23:12.521 Uh, which is above the workflows layer, so it wouldn't be able to
00:23:09.637 --> 00:23:09.877 Umm.
00:23:12.307 --> 00:23:12.547 Yeah.
00:23:12.521 --> 00:23:13.847 read it inside workflows.
00:23:13.857 --> 00:23:17.117 I don't know this this is just another copy of it or or what's
00:23:17.117 --> 00:23:20.377 going on, but that's just where that is and where it would be.
00:23:22.617 --> 00:23:27.625 But that's gonna enforce pretty much everything we need it to
00:23:27.625 --> 00:23:28.917 enforce on this.
00:23:28.967 --> 00:23:33.059 To start, there are alternate forms of enforcement for
00:23:30.367 --> 00:23:30.707 Hmm.
00:23:33.059 --> 00:23:36.407 different kinds of endpoints that we can do.
00:23:37.167 --> 00:23:42.482 Umm for things that are like not a known like for current account
00:23:42.482 --> 00:23:43.287 type call.
00:23:44.007 --> 00:23:46.657 Umm, an example of one of those is.
00:23:46.667 --> 00:23:51.367 If you go to the like the regular and get orders search.
00:23:53.617 --> 00:23:55.387 And thing.
00:23:57.457 --> 00:23:58.377 Get sales orders.
00:23:57.477 --> 00:24:00.817 Like get sales orders. Yeah.
00:24:00.827 --> 00:24:06.458 So go to that class and then go to its usage, which is the the
00:24:06.458 --> 00:24:07.887 the get request.
00:24:10.647 --> 00:24:12.627 And there that will be in this it will be in this file.
00:24:17.257 --> 00:24:18.167 OK, so there's.
00:24:17.387 --> 00:24:19.437 This is the admin endpoint too, just.
00:24:21.797 --> 00:24:22.247 Uh.
00:24:22.387 --> 00:24:24.327 The there's.
00:24:24.497 --> 00:24:27.928 Yeah, there's this piece here and then we have there might
00:24:27.928 --> 00:24:31.242 there should be an override of this of this git endpoint
00:24:31.242 --> 00:24:31.707 handler.
00:24:33.237 --> 00:24:35.647 So if you can go find the over any overrides of this.
00:24:40.327 --> 00:24:41.437 Still supporters.
00:24:43.117 --> 00:24:43.657 Uh.
00:24:43.467 --> 00:24:44.137 Would not.
00:24:43.727 --> 00:24:45.744 That you wouldn't be looking for get sales orders, you'd be
00:24:45.744 --> 00:24:46.147 looking for.
00:24:47.007 --> 00:24:51.790 And like you've got an overrides button there on the line above
00:24:51.790 --> 00:24:52.387 the get.
00:24:53.167 --> 00:24:55.217 Yeah, it's not saying anything.
00:24:55.037 --> 00:25:01.384 It's not finding any OK and search this project for API kind
00:24:55.287 --> 00:24:56.617 Uh, for me on my end, yeah.
00:25:01.384 --> 00:25:07.417 capital a capital P capital a capital K at lower case ID.
00:25:04.447 --> 00:25:04.747 Deep.
00:25:11.567 --> 00:25:15.527 True, let's no.
00:25:15.597 --> 00:25:20.149 OK, so so the API cons like that right and then but we wanna be
00:25:20.149 --> 00:25:21.927 specifically in this one.
00:25:20.167 --> 00:25:20.307 Yes.
00:25:26.047 --> 00:25:26.957 Service.
00:25:26.997 --> 00:25:29.357 So I just start denominate.
00:25:27.117 --> 00:25:27.467 OK.
00:25:27.477 --> 00:25:31.887 Well, there I I think I saw I saw a good example.
00:25:31.897 --> 00:25:34.689 There's a switch current API kind on query service 2 below
00:25:34.689 --> 00:25:36.297 the current one less highlighted.
00:25:37.997 --> 00:25:38.537 Yeah, this one.
00:25:39.527 --> 00:25:39.707 Yeah.
00:25:41.647 --> 00:25:42.377 There we go.
00:25:42.467 --> 00:25:44.357 This is another one that's an example.
00:25:44.787 --> 00:25:47.640 So based upon the current API kind, whether it's a brand
00:25:47.640 --> 00:25:50.343 admin, a franchise admin store, admin, vendor, admin,
00:25:50.343 --> 00:25:53.345 manufacturer, admin or it's, it could be that it's the main
00:25:53.345 --> 00:25:55.497 admin or it could be that it's storefront.
00:25:55.737 --> 00:25:59.797 You can enforce a particular value into the request so that
00:25:59.797 --> 00:26:03.517 it is helping to enforce the security around the data.
00:26:03.787 --> 00:26:07.126 So for instance, if it's the brand admin one, we're doing,
00:26:07.126 --> 00:26:08.257 what is the current?
00:26:08.267 --> 00:26:09.437 What am I currently doing?
00:26:09.447 --> 00:26:12.617 The brand have been of based upon the URL that we're in.
00:26:13.507 --> 00:26:17.362 So and then it will apply the Brent that ID onto the request
00:26:17.362 --> 00:26:20.457 server side and then before it tries to reserve.
00:26:20.517 --> 00:26:25.526 I'm sorry return results for sales quotes, then it must do
00:26:25.526 --> 00:26:28.667 the correct one for the thing on it.
00:26:28.787 --> 00:26:31.071 And there's other examples of where it's it's kind of used
00:26:31.071 --> 00:26:31.457 like this.
00:26:32.027 --> 00:26:32.477 Umm.
00:26:32.807 --> 00:26:37.109 In places but the the the general goal here is we're
00:26:33.107 --> 00:26:33.447 Umm.
00:26:37.109 --> 00:26:42.304 enforcing service side that no one, you know X portal can serve
00:26:42.304 --> 00:26:47.417 data to the wrong thing for the wrong for the wrong store, the
00:26:47.417 --> 00:26:51.637 wrong brand, the wrong franchise, whatever onto it.
00:26:52.757 --> 00:26:56.571 And so we use the current API kind flag to do that, cause the
00:26:56.571 --> 00:27:00.384 current API kind flag gets set as it starting up and it knows
00:27:00.384 --> 00:27:04.259 which one it is by what the URL and everything it's being told
00:27:04.259 --> 00:27:05.427 to serve itself as.
00:27:05.897 --> 00:27:09.231 The same way that it knows like the used in storefront or the
00:27:09.231 --> 00:27:12.187 used in admin attribute is on the particular endpoint.
00:27:09.917 --> 00:27:10.157 Umm.
00:27:12.237 --> 00:27:16.567 It knows which API it is to apply this onto there.
00:27:17.757 --> 00:27:18.087 Yeah.
00:27:18.097 --> 00:27:23.757 So essentially just to that, I guess dumb it down.
00:27:24.167 --> 00:27:27.528 If if you have an endpoint that's open everything open to
00:27:27.528 --> 00:27:31.237 all the app pools, we can know which one we're making call from
00:27:31.237 --> 00:27:34.540 by using the current API comments cause that's that gets
00:27:34.540 --> 00:27:38.307 all set before it before it hits the actual like post handler or
00:27:36.467 --> 00:27:36.627 Yeah.
00:27:38.307 --> 00:27:39.697 get handler or whatever.
00:27:40.627 --> 00:27:41.877 Yeah, you you'd have to find him.
00:27:40.787 --> 00:27:42.327 Negrete said at application start.
00:27:41.887 --> 00:27:45.307 But there's a yeah, they're they're, you know, to find them.
00:27:45.317 --> 00:27:48.540 But there's a few endpoints that do this where they they don't do
00:27:48.540 --> 00:27:51.127 anything unless it's the storefront, and if it's the
00:27:51.127 --> 00:27:54.007 storefront, it applies like a current account requirement.
00:27:54.017 --> 00:27:56.699 We're current user requirement onto whatever the request is,
00:27:55.017 --> 00:27:55.277 Hmm.
00:27:56.699 --> 00:27:58.237 otherwise it just leaves it alone.
00:27:59.017 --> 00:27:59.277 OK.
00:27:59.167 --> 00:28:02.760 We also use this in the caching logic to completely bypass
00:27:59.357 --> 00:27:59.927 Kind of thing.
00:27:59.937 --> 00:28:01.437 So there there's there's a few that are like that.
00:28:02.760 --> 00:28:04.647 caching if it's not storefront.
00:28:05.707 --> 00:28:06.327 Yeah.
00:28:06.107 --> 00:28:06.407 OK.
00:28:06.607 --> 00:28:07.977 Yeah, that's that's another instance.
00:28:07.987 --> 00:28:12.157 This is if it's not storefront as the current API kind.
00:28:12.227 --> 00:28:14.277 It doesn't allow caching of any kind.
00:28:14.567 --> 00:28:17.019 It doesn't go to Redis, it doesn't go through the three or
00:28:17.019 --> 00:28:17.517 four system.
00:28:17.527 --> 00:28:20.737 It doesn't do any of that stuff, so if you ever like wondering
00:28:20.737 --> 00:28:22.877 like is this request cached in the admin?
00:28:22.887 --> 00:28:25.507 I'm like, no, it's not because it's not allowed to.
00:28:28.027 --> 00:28:28.327 The cool.
00:28:30.377 --> 00:28:34.550 So any other specific examples or anything we wanted to look at
00:28:34.550 --> 00:28:35.397 growing that?
00:28:37.437 --> 00:28:41.502 Regarding that part, no, the the other thing for authentication
00:28:41.502 --> 00:28:45.567 is and you'll see these on there is with the authenticate tags.
00:28:45.797 --> 00:28:49.447 You might also see a requires role or requires permission.
00:28:49.257 --> 00:28:49.397 Yeah.
00:28:50.287 --> 00:28:50.897 Umm.
00:28:51.127 --> 00:28:52.007 On particular things.
00:28:55.227 --> 00:28:55.707 To.
00:28:55.747 --> 00:28:56.207 So what?
00:28:56.217 --> 00:28:58.837 You're what you're looking at is like finding a definition of
00:28:58.837 --> 00:29:01.246 something, not searching the tech, but for by text for a
00:29:01.246 --> 00:29:02.217 particular instance of.
00:29:03.767 --> 00:29:04.697 Be able to do it this way.
00:29:05.907 --> 00:29:06.437 Uh.
00:29:06.697 --> 00:29:07.157 OHS.
00:29:07.167 --> 00:29:08.887 No, it's gonna, like, go more and more and more.
00:29:08.897 --> 00:29:09.777 More but.
00:29:09.297 --> 00:29:09.747 Do you?
00:29:10.097 --> 00:29:10.447 Yeah.
00:29:10.457 --> 00:29:10.947 Do you like?
00:29:10.957 --> 00:29:11.987 Requires any role?
00:29:16.337 --> 00:29:17.047 Attribute.
00:29:16.867 --> 00:29:17.977 What's the attribute?
00:29:17.057 --> 00:29:19.337 But yeah one SEC.
00:29:18.367 --> 00:29:22.087 Yeah, but it's trying to find the definition of it, not the
00:29:21.787 --> 00:29:23.917 For whatever reason, it's not fun type stuff.
00:29:22.087 --> 00:29:22.397 text.
00:29:22.407 --> 00:29:25.604 You do control shift F instead of so that you're doing into
00:29:25.604 --> 00:29:27.787 finding files as opposed to the control.
00:29:27.797 --> 00:29:28.257 There you go.
00:29:28.237 --> 00:29:28.417 Yeah.
00:29:32.477 --> 00:29:34.717 OK, so let's, let's say requires role.
00:29:37.837 --> 00:29:39.127 So the requires is plural.
00:29:38.337 --> 00:29:38.537 Or.
00:29:40.777 --> 00:29:42.967 Ohh yeah sorry that probably be why.
00:29:45.087 --> 00:29:45.907 Umm.
00:29:47.287 --> 00:29:48.367 Still, it's a match case.
00:29:54.207 --> 00:29:56.467 And then I think it's usually requires any role.
00:30:01.727 --> 00:30:01.987 Weird.
00:30:01.997 --> 00:30:05.944 I don't know why my ID is being difficult, but might see where
00:30:05.944 --> 00:30:08.387 could we go for that probably be like.
00:30:10.967 --> 00:30:11.317 Umm.
00:30:14.887 --> 00:30:17.511 I mean the file that you have opened one of those
00:30:17.511 --> 00:30:20.765 autogenerated services filed gonna have it in there on one of
00:30:20.765 --> 00:30:21.447 these things.
00:30:20.967 --> 00:30:21.117 Yeah.
00:30:21.127 --> 00:30:21.207 Yeah.
00:30:21.757 --> 00:30:22.387 There you go.
00:30:22.217 --> 00:30:23.267 Soon as required permission.
00:30:22.637 --> 00:30:24.367 Line 32 required permission.
00:30:25.277 --> 00:30:25.847 Umm.
00:30:26.237 --> 00:30:27.787 So required permission.
00:30:28.077 --> 00:30:30.776 Then there's also required role or and there's required any role
00:30:30.776 --> 00:30:33.225 or requires any permission meeting that you could have one
00:30:33.225 --> 00:30:35.507 of one of several permissions and it would satisfy it.
00:30:36.127 --> 00:30:37.657 Umm for stuff.
00:30:38.167 --> 00:30:41.559 There's variations on this stuff on the theme here, but the the
00:30:41.559 --> 00:30:44.474 idea is you should have this particular permission now
00:30:44.474 --> 00:30:47.017 because of how many different things there are.
00:30:47.167 --> 00:30:49.567 There's over 3000 permissions in the database.
00:30:50.487 --> 00:30:53.068 If you're on the global admin role, you should have every
00:30:53.068 --> 00:30:53.557 permission.
00:30:54.147 --> 00:30:58.662 If you're on the CEF user role, you get a very much smaller
00:30:58.662 --> 00:31:00.317 subset of permissions.
00:31:00.687 --> 00:31:04.230 Excuse me to work with on them and then so like if you tried to
00:31:04.230 --> 00:31:07.606 hit this endpoint even though you were authenticated, if you
00:31:07.606 --> 00:31:10.927 didn't have the particular permission, it would reject with
00:31:10.927 --> 00:31:14.414 the endpoint from even accepting the request and it would give
00:31:14.414 --> 00:31:15.797 you a four or three back.
00:31:17.077 --> 00:31:17.767 Yeah.
00:31:17.997 --> 00:31:22.052 For from what I've seen, generally the the T4 generated,
00:31:22.052 --> 00:31:23.047 I guess there.
00:31:23.097 --> 00:31:26.156 I'm not sure if they're actually 4 generated or not, but the
00:31:26.156 --> 00:31:29.315 permissions like invoicing, dot, sales, invoice, whatever like
00:31:29.315 --> 00:31:32.274 the schema dot view or whatever the generally those are by
00:31:32.274 --> 00:31:35.082 default locked down to admins and then we have a lot of
00:31:35.082 --> 00:31:38.140 specific permissions like you know that have like storefront
00:31:38.140 --> 00:31:41.099 in the name that denote that hey, this is specifically for
00:31:41.099 --> 00:31:44.207 like any you know CEF user who's logged in and kind of thing.
00:31:45.237 --> 00:31:47.367 Umm but yeah.
00:31:47.257 --> 00:31:50.872 We could be better about the naming or or you know, you know,
00:31:50.872 --> 00:31:54.487 making it genericized so that it's more it's generically more
00:31:54.487 --> 00:31:57.752 specific, if that makes sense, where because, you know,
00:31:55.607 --> 00:31:56.017 Hmm.
00:31:57.752 --> 00:32:01.250 sometimes the page is get a different name even though even
00:32:01.250 --> 00:32:04.981 though it is a sales order, it might be called service requests
00:32:04.981 --> 00:32:08.538 like WBS has it, something like that, making it so that it's
00:32:06.257 --> 00:32:06.487 Umm.
00:32:08.538 --> 00:32:09.237 still clear.
00:32:09.247 --> 00:32:12.184 Like what you're pointing at and what in what it's actually
00:32:12.184 --> 00:32:12.967 trying to cover.
00:32:13.607 --> 00:32:14.167 Umm.
00:32:14.467 --> 00:32:18.370 And we could be better about making sure that the storefront
00:32:18.370 --> 00:32:20.097 elements actually followed.
00:32:20.107 --> 00:32:22.397 Like what these individual permissions actually were?
00:32:22.527 --> 00:32:27.304 Instead of just making their own on stuff for for assigning
00:32:27.304 --> 00:32:28.657 inside of the UI.
00:32:28.927 --> 00:32:33.176 But generally speaking, that is all correct for for what we can
00:32:33.176 --> 00:32:35.897 do, and you can append stuff onto these.
00:32:35.907 --> 00:32:38.367 So just like with the user in addendums.
00:32:38.937 --> 00:32:42.943 Umm you these are partial classes, so you can go in and
00:32:42.943 --> 00:32:47.021 append another required permission or requires role onto
00:32:47.021 --> 00:32:51.528 the partial class using another partial class in a non T4 area
00:32:51.528 --> 00:32:55.963 for stuff and we do do that in a few places and then also the
00:32:53.377 --> 00:32:53.637 OK.
00:32:55.963 --> 00:32:57.107 inverse of that.
00:32:57.117 --> 00:33:01.847 Basically is you can't take an attribute off of the T4 values.
00:33:02.127 --> 00:33:05.399 So what we've done in a few cases is we've made a separate
00:33:02.517 --> 00:33:02.787 Umm.
00:33:05.399 --> 00:33:08.782 endpoint that calls the initial calls with the thing they're
00:33:08.782 --> 00:33:12.220 called, but doesn't have the permission to requirements on it
00:33:10.157 --> 00:33:10.597 Umm.
00:33:12.220 --> 00:33:15.658 so that we can get around like what the default is because it
00:33:15.658 --> 00:33:18.708 might be something that is perfectly acceptable for an
00:33:18.708 --> 00:33:20.427 anonymous user to call to make.
00:33:20.917 --> 00:33:23.942 But because of the way the T4 is written, it doesn't know to not
00:33:23.942 --> 00:33:24.547 lock it down.
00:33:25.217 --> 00:33:25.497 OK.
00:33:25.597 --> 00:33:25.967 Kind of thing.
00:33:26.607 --> 00:33:29.543 And desire with that call, like the request handler or like it
00:33:27.307 --> 00:33:28.757 So there are a few cases like that.
00:33:29.543 --> 00:33:32.152 would, it would actually just call like the workflow or
00:33:32.152 --> 00:33:32.897 whatever, right?
00:33:33.117 --> 00:33:37.487 In like the I I've done it in two different ways.
00:33:37.497 --> 00:33:40.714 Generally speaking, we have an endpoint of that separate class
00:33:40.714 --> 00:33:44.033 that is the endpoint handler and that it internally could either
00:33:44.033 --> 00:33:47.199 call the workflow or it could call the other endpoint handler
00:33:47.199 --> 00:33:50.007 if it's inside the same class, the same service class.
00:33:48.397 --> 00:33:51.067 Umm yeah.
00:33:50.877 --> 00:33:53.793 So you could do it either way and it would be fine because by
00:33:53.793 --> 00:33:56.661 that because when you're inside the service class and you're
00:33:56.661 --> 00:33:59.718 calling another endpoint handle like another get call or another
00:33:59.718 --> 00:34:00.517 post or whatever.
00:33:59.877 --> 00:34:00.087 Umm.
00:34:00.997 --> 00:34:04.307 Umm, you're you're bypassing those checks.
00:34:04.317 --> 00:34:06.927 That service stack has because service decks doing that at the.
00:34:08.977 --> 00:34:12.592 Dynamic like by reflection level umm for the services that could
00:34:12.592 --> 00:34:16.152 that get started during startup to figure out what all of those
00:34:16.152 --> 00:34:19.433 are, and you're so you're already passed that point and it
00:34:16.467 --> 00:34:16.697 OK.
00:34:19.433 --> 00:34:21.657 doesn't get the check all those things.
00:34:21.667 --> 00:34:24.433 So you would either reimplement your own logic or just go and
00:34:22.377 --> 00:34:22.627 Umm.
00:34:24.433 --> 00:34:27.244 just completely bypass and just do whatever you were trying to
00:34:27.244 --> 00:34:27.377 do.
00:34:28.067 --> 00:34:31.096 Umm, just be aware that you might be unsecured data that is
00:34:31.096 --> 00:34:32.257 supposed to be secured.
00:34:32.787 --> 00:34:35.741 If you do that, so just be careful if you're going to
00:34:35.741 --> 00:34:37.327 implement that kind of thing.
00:34:38.767 --> 00:34:39.447 That makes sense.
00:34:42.737 --> 00:34:46.187 I think that covers pretty much everything for services. Uh.
00:34:42.887 --> 00:34:43.367 Alright.
00:34:46.447 --> 00:34:46.687 Uh.
00:34:46.477 --> 00:34:46.867 Yeah.
00:34:48.317 --> 00:34:50.127 Trying to think if there's anything else.
00:34:52.817 --> 00:34:56.557 Umm so I the next part would really be about logging I think.
00:34:58.807 --> 00:35:01.124 Uh, like the OR talking about like the payment stuff we're
00:35:01.124 --> 00:35:01.987 talking about earlier.
00:35:02.457 --> 00:35:02.697 Yeah.
00:35:04.137 --> 00:35:04.357 Yeah.
00:35:04.357 --> 00:35:05.177 Like what should you?
00:35:05.267 --> 00:35:07.247 What should you blank out of logs?
00:35:10.927 --> 00:35:12.897 Yeah, I don't know if there's.
00:35:12.967 --> 00:35:13.407 Let's see.
00:35:15.937 --> 00:35:18.027 Two fighters stuff.
00:35:20.287 --> 00:35:24.668 So all the payment providers are well, I shouldn't say all some
00:35:24.668 --> 00:35:27.337 of them have separate projects, right?
00:35:27.347 --> 00:35:32.696 But a lot of them live in providers dot payments under the
00:35:32.696 --> 00:35:34.237 providers folder.
00:35:34.467 --> 00:35:35.127 In the layer there.
00:35:36.037 --> 00:35:38.987 Uh, there's a bunch of them.
00:35:38.997 --> 00:35:42.978 I guess we can just look at whatever, but let's see what's
00:35:42.978 --> 00:35:44.867 probably going to be simple.
00:35:46.597 --> 00:35:51.903 Serve first to be simple, but uh, essentially, I mean there's
00:35:51.903 --> 00:35:57.037 a I guess I guess we'll start like we'll start it this way.
00:35:57.807 --> 00:36:01.983 As far as I'm aware, I I I don't know if any providers were
00:36:01.983 --> 00:36:06.367 restoring like the the full card number or anything like that.
00:36:07.727 --> 00:36:12.742 Um, anywhere now I could be wrong, so feel free to correct
00:36:11.657 --> 00:36:12.447 That is correct.
00:36:12.457 --> 00:36:12.897 No one.
00:36:12.742 --> 00:36:12.997 me.
00:36:13.007 --> 00:36:14.207 OK, alright.
00:36:13.767 --> 00:36:16.887 No one know where should be ever be storing a full credit card
00:36:16.887 --> 00:36:17.927 number in our system.
00:36:18.527 --> 00:36:18.977 Yeah.
00:36:18.807 --> 00:36:20.007 OK and.
00:36:19.267 --> 00:36:23.241 The only place that that used to happen, which is fixed now, is
00:36:23.241 --> 00:36:26.780 that we used to have error handling logic that would log
00:36:26.780 --> 00:36:30.257 like the request body of the request to help debugging.
00:36:30.807 --> 00:36:34.104 And the problem there was if for example like a create wallet
00:36:34.104 --> 00:36:37.507 entry through an exception that wasn't caught, the body of that
00:36:37.507 --> 00:36:40.910 create well it exception would be logged and that would contain
00:36:40.910 --> 00:36:43.728 like full card number, expiration date, that kind of
00:36:43.728 --> 00:36:44.047 thing.
00:36:44.687 --> 00:36:48.063 Umm, so on on all current projects that should be fixed
00:36:48.063 --> 00:36:51.799 and if there are any that it isn't, we need to get that fixed
00:36:51.799 --> 00:36:53.607 into them before they go live.
00:36:54.707 --> 00:36:55.257 Yeah.
00:36:55.307 --> 00:36:58.890 So essentially, the reason why we're not storing that and we
00:36:58.890 --> 00:37:02.296 also shouldn't be storing that in logs obviously is cause
00:37:02.296 --> 00:37:06.113 that's a that's a huge like PCI compliance thing where now we're
00:37:06.113 --> 00:37:09.813 we're holding data that we don't wanna hold, it creates a huge
00:37:09.813 --> 00:37:10.987 amount of liability.
00:37:11.777 --> 00:37:14.177 Umm, you know, think about it this way.
00:37:14.187 --> 00:37:17.353 Like if we if we get hacked, we don't want every single or if
00:37:17.353 --> 00:37:20.416 like let's say an instance of wanna recites contact or just
00:37:20.416 --> 00:37:23.530 someone gets unauthorized access even if that's like just an
00:37:23.530 --> 00:37:26.594 employee of the let's say our client hires someone and that
00:37:26.594 --> 00:37:29.657 person decides I'm gonna go through and try to steal credit
00:37:29.657 --> 00:37:30.167 card info.
00:37:30.377 --> 00:37:32.057 We don't want that to be possible.
00:37:32.897 --> 00:37:36.583 Umm, so that that's why something exists that you'll
00:37:36.583 --> 00:37:39.017 probably hear called tokenization.
00:37:39.507 --> 00:37:43.540 Essentially, we're passing all the info to a payment provider,
00:37:43.540 --> 00:37:47.317 a gateway, whatever, and then they're gonna pass us back a
00:37:47.317 --> 00:37:51.221 token that we can use and we store the token instead of like
00:37:51.221 --> 00:37:53.717 a full card number and all that stuff.
00:37:53.927 --> 00:37:56.952 So as we basically try to store as little as possible, we'll
00:37:56.952 --> 00:37:59.927 still making it possible to store like a wallet entry where
00:37:59.927 --> 00:38:03.051 someone can say, hey, I wanna use this card that ends in these
00:38:03.051 --> 00:38:03.497 4 digits.
00:38:03.647 --> 00:38:06.886 That way they can identify what card it is and they just type in
00:38:06.886 --> 00:38:09.676 the CV, if that's even in requirement for that specific
00:38:09.676 --> 00:38:12.217 provider or gateway or implementation or whatever.
00:38:13.737 --> 00:38:16.145 And they could just make the payment and all we're storing is
00:38:16.145 --> 00:38:17.387 basically just a string of text.
00:38:17.397 --> 00:38:22.083 That says to their system, hey, this is this, this the string of
00:38:22.083 --> 00:38:26.840 text means use this wallet entry that has this carbon number, but
00:38:26.840 --> 00:38:31.165 we never hold that and unique example is and I'm I actually
00:38:31.165 --> 00:38:32.967 has it was kind of weird.
00:38:33.217 --> 00:38:37.491 They're kind of a weird provider, but basically, umm all
00:38:37.491 --> 00:38:42.364 the tokenization happens on the client side and all CEF takes in
00:38:42.364 --> 00:38:45.137 is the token itself on the back end.
00:38:45.147 --> 00:38:48.969 So our back end doesn't even doesn't even in memory touch a
00:38:48.969 --> 00:38:50.497 full credit card number.
00:38:50.507 --> 00:38:53.013 It just touches a token and we just save it and validate it
00:38:53.013 --> 00:38:53.597 kind of thing.
00:38:54.467 --> 00:38:59.137 So essentially we want to store as little as possible, and that
00:38:59.137 --> 00:39:00.887 also goes on to logging.
00:39:01.367 --> 00:39:04.956 So what I mean by that is, and a lot of these will have like an
00:39:04.956 --> 00:39:08.432 extension and a lot of these payment providers will be like a
00:39:08.432 --> 00:39:11.909 blah blah blah extensions dot CS, but she usually will handle
00:39:11.909 --> 00:39:13.927 like sending and receiver requests.
00:39:14.337 --> 00:39:18.664 And generally speaking, will have error handling and what we
00:39:18.664 --> 00:39:22.565 don't want to do is that if we're in like a production
00:39:22.565 --> 00:39:26.962 environment, we don't want to necessarily like log the entire
00:39:26.962 --> 00:39:27.387 error.
00:39:28.097 --> 00:39:28.827 Umm.
00:39:29.057 --> 00:39:32.007 If it might have like some kind of sensitive information in it.
00:39:32.667 --> 00:39:36.377 Umm, so we gotta be careful about that for example.
00:39:42.637 --> 00:39:47.636 You know, I think in this one, just let me see here if I can
00:39:47.636 --> 00:39:52.962 find a good example blank and a little bit of like where there's
00:39:52.962 --> 00:39:53.207 OK.
00:39:53.217 --> 00:39:53.527 Yeah.
00:39:53.537 --> 00:39:58.547 So for example, logging, you know talk about logging.
00:39:59.187 --> 00:40:03.957 Umm for serve first, at least unless it's in sandbox mode.
00:40:03.967 --> 00:40:06.879 We're not logging information about things we're sending over
00:40:06.879 --> 00:40:09.790 the wire consistently, which would include like you know, all
00:40:09.790 --> 00:40:12.513 the fields were sending over, even though that that isn't
00:40:12.513 --> 00:40:14.297 gonna let me see what method is this.
00:40:14.697 --> 00:40:17.056 Otherwise, even though authorizing capture isn't gonna
00:40:17.056 --> 00:40:19.757 be taking in a full card number or something, it might contain
00:40:19.757 --> 00:40:21.257 something like a CVS or something.
00:40:21.267 --> 00:40:22.577 I don't know if that's actually true.
00:40:22.587 --> 00:40:25.542 I don't think servers require CVV and I don't think our
00:40:25.542 --> 00:40:28.337 implementation has it, but not actually sure. Do we?
00:40:28.757 --> 00:40:29.907 Do we do have CVV, dear?
00:40:30.777 --> 00:40:31.587 Umm.
00:40:31.677 --> 00:40:34.397 If it if it is required, OK, so it's kind of analogous.
00:40:34.407 --> 00:40:35.367 You can have it on or off.
00:40:35.377 --> 00:40:39.199 It doesn't really matter, but if you did have CV, you wouldn't
00:40:39.199 --> 00:40:42.777 want to be logging that the person's pin right to the logs
00:40:42.777 --> 00:40:46.174 in a production environment where you're have real data
00:40:46.174 --> 00:40:47.447 flying around, right?
00:40:47.677 --> 00:40:49.207 So only if you're in test mode.
00:40:49.217 --> 00:40:50.647 Basically, is what this says.
00:40:50.997 --> 00:40:54.153 Then you can log it so that we can help debug and figure stuff
00:40:54.153 --> 00:40:56.907 out, but if you're not, we're not logging that at all.
00:40:57.157 --> 00:41:00.469 And then it should never be captured somewhere, because
00:41:00.469 --> 00:41:04.136 obviously if we're logging it to the logs, that means someone
00:41:04.136 --> 00:41:07.802 could go through and say hmm, let me go into the database and
00:41:07.802 --> 00:41:11.528 say get me blah blah blah where like we're description like CV
00:41:11.528 --> 00:41:12.947 and pull sensitive data.
00:41:11.607 --> 00:41:15.567 So that's actually not OK.
00:41:18.797 --> 00:41:19.347 Umm.
00:41:19.397 --> 00:41:22.821 Even if it is sandbox mode and we're just using test cards and
00:41:22.821 --> 00:41:26.081 data, we still shouldn't be logging in the entire object on
00:41:26.081 --> 00:41:26.407 there.
00:41:26.417 --> 00:41:29.791 We should be making the efforts to blink the info before it goes
00:41:29.791 --> 00:41:30.517 into the blog.
00:41:33.107 --> 00:41:37.862 Umm, what I would be doing and I believe I've done over in cyber
00:41:37.497 --> 00:41:37.797 Mm-hmm.
00:41:37.862 --> 00:41:42.250 sources provider is I make a copy of the object and then in
00:41:42.250 --> 00:41:46.712 the copy I set like the card number or the CVV to like a set
00:41:46.712 --> 00:41:51.539 of bullets or a set of asterisks so that I could show that it has
00:41:51.539 --> 00:41:56.366 been blinked and then I log that value as my serialized object in
00:41:56.366 --> 00:42:00.901 there and then you should be doing that with the you know any
00:41:57.987 --> 00:41:58.237 OK.
00:42:00.901 --> 00:42:03.607 tokens or anything that get created.
00:42:03.617 --> 00:42:07.570 You shouldn't log the token either, cause it just makes it
00:42:07.570 --> 00:42:11.925 easier to get the token and out of the log, but like, see how it
00:42:11.925 --> 00:42:13.867 I've got the like like there.
00:42:13.927 --> 00:42:17.451 If you stay for a second line 219 instead of the full card
00:42:17.451 --> 00:42:21.034 number, I have it taking the last four, which is a normally
00:42:21.034 --> 00:42:22.347 commonly public thing.
00:42:22.357 --> 00:42:25.184 That's OK to show because you know that that's something
00:42:24.267 --> 00:42:24.477 Umm.
00:42:25.184 --> 00:42:28.110 that's something people have easy access to and it doesn't
00:42:28.110 --> 00:42:31.383 give them the actual number, but it does show that you did have a
00:42:31.383 --> 00:42:34.507 number and that you were able to read the last four off of it.
00:42:34.267 --> 00:42:34.567 Umm.
00:42:34.667 --> 00:42:39.876 But the rest of the data is all stripped and is copied out of it
00:42:39.876 --> 00:42:41.077 using settings.
00:42:41.667 --> 00:42:44.577 So we have in the response values and headers.
00:42:41.767 --> 00:42:42.017 Umm.
00:42:45.107 --> 00:42:48.415 Umm I I have it blinking and stuff with that copy of the
00:42:48.415 --> 00:42:51.781 object on there and then it looks like it's doing it this
00:42:51.781 --> 00:42:55.263 way, but then other ones were like in order to make a quick
00:42:55.263 --> 00:42:59.035 clone of something for something that is not have the icloneable
00:42:57.157 --> 00:42:57.407 Umm.
00:42:59.035 --> 00:43:01.937 interface, I literally just serialize it and then
00:43:01.937 --> 00:43:04.897 deserialize it to another variable so that I can't
00:43:04.897 --> 00:43:08.495 accidentally affect my original object that I'm about to that
00:43:08.495 --> 00:43:12.209 I'm logging right before I send it in a request because I don't
00:43:12.077 --> 00:43:12.357 Umm.
00:43:12.209 --> 00:43:15.865 want to blink data and then I accidentally sent the blink data
00:43:15.865 --> 00:43:17.257 to the payment provider.
00:43:17.267 --> 00:43:18.037 That would suck.
00:43:19.267 --> 00:43:23.570 I instead do it to a copy of the thing, and the copy is for sure
00:43:23.570 --> 00:43:27.541 separated because I used it to serialize and deserialize it
00:43:27.541 --> 00:43:28.467 into the copy.
00:43:29.497 --> 00:43:34.373 Umm to enforce a separate object in memory for that stuff and
00:43:34.373 --> 00:43:38.541 also of course generally speaking, almost all of our
00:43:35.197 --> 00:43:35.487 Umm.
00:43:38.541 --> 00:43:43.337 providers should be under the functionality of Wallet first.
00:43:43.447 --> 00:43:43.767 Where?
00:43:44.597 --> 00:43:47.475 Uh, you don't just enter the credit card number and send it
00:43:47.475 --> 00:43:49.297 directly off for payment information.
00:43:49.037 --> 00:43:49.327 Umm.
00:43:49.307 --> 00:43:52.296 You should be doing it where you create a wallet entry and then
00:43:52.296 --> 00:43:54.257 you use the wallet entry for the payment.
00:43:54.827 --> 00:43:58.225 Umm on that set because it is a more secure situation and
00:43:55.107 --> 00:43:55.357 Yep.
00:43:58.225 --> 00:44:01.916 there's no reason why any of our clients should not be using a
00:44:01.916 --> 00:44:04.317 wallet feature at this point out of box.
00:44:06.207 --> 00:44:08.267 Uh, which was the case for a while, but.
00:44:06.257 --> 00:44:07.367 Yeah, I can only think of.
00:44:08.967 --> 00:44:12.220 Yeah, I can only think of 1 project off the time ahead where
00:44:12.220 --> 00:44:15.259 they wanted unsaved wallet entries, which means like you
00:44:15.259 --> 00:44:18.724 can go through and just pay with your details right away without
00:44:18.724 --> 00:44:19.257 saving it.
00:44:20.507 --> 00:44:24.552 But other than that, every single product I think I've been
00:44:24.552 --> 00:44:28.597 on it has been a non issue to just tokenize it and save it.
00:44:28.727 --> 00:44:36.713 So yeah, save the token at least, but yeah, so I guess let
00:44:32.877 --> 00:44:33.057 Yeah.
00:44:36.713 --> 00:44:38.337 me see here.
00:44:39.087 --> 00:44:42.957 But like when we're, let's see your Craig customer profile.
00:44:44.507 --> 00:44:47.897 Uh, just do? Yeah.
00:44:50.307 --> 00:44:54.567 Trying to think where the actual uh mappings.
00:44:53.217 --> 00:44:56.290 But in this case you've got a login sensitive information
00:44:56.290 --> 00:44:56.607 async.
00:44:56.917 --> 00:44:59.411 So if we go to that definition, we could see what gets taken off
00:44:59.411 --> 00:44:59.947 of the object.
00:45:01.577 --> 00:45:02.447 Yeah.
00:45:02.457 --> 00:45:07.387 So I think all this one does is it basically says like hey, was
00:45:07.387 --> 00:45:12.085 it approved, it was the status code error code error message
00:45:12.085 --> 00:45:13.317 stuff like that.
00:45:13.497 --> 00:45:17.542 So it's basically only logging a ton of stuff about whether it
00:45:17.542 --> 00:45:21.265 worked or not, but not anything about necessarily the the
00:45:21.265 --> 00:45:22.227 request itself.
00:45:22.237 --> 00:45:24.907 At side of, I think there's two.
00:45:24.917 --> 00:45:25.427 I think this has.
00:45:26.197 --> 00:45:29.232 There's a different one for a different class, but the other
00:45:29.232 --> 00:45:32.417 one it's kind of the same thing where just says like, you know,
00:45:32.417 --> 00:45:35.302 maybe the account ID of the request, but doesn't actually
00:45:35.302 --> 00:45:37.840 doesn't like even record anything that would allow
00:45:37.840 --> 00:45:41.073 someone to like rip crap out of it and make a subsequent request
00:45:41.073 --> 00:45:42.267 on their own, let's say.
00:45:41.447 --> 00:45:41.567 Yeah.
00:45:43.847 --> 00:45:47.392 And and I understand because of the like a, you know, Plaid and
00:45:47.392 --> 00:45:51.047 Payoneer and pay easy, you know, they'll function so differently.
00:45:51.057 --> 00:45:54.473 We can't just have one consistent like, you know,
00:45:54.473 --> 00:45:58.297 function that we can use to strip all this logging out.
00:45:58.667 --> 00:46:03.944 I do want to get a more common version or at least an
00:46:03.944 --> 00:46:06.777 implementation of it in that.
00:46:06.787 --> 00:46:10.613 Could that the basically says that the payment provider base
00:46:10.613 --> 00:46:14.188 says you have to implement a login sensitive information
00:46:14.188 --> 00:46:18.140 async and that you need to pass in whatever your types are and
00:46:16.167 --> 00:46:16.427 Umm.
00:46:18.140 --> 00:46:21.715 then inside that function when you implement it and then
00:46:21.715 --> 00:46:25.353 everyone knows you need to be calling the logins additive
00:46:25.353 --> 00:46:28.990 information async for any logging inside of these payment
00:46:28.990 --> 00:46:29.617 providers.
00:46:29.627 --> 00:46:32.508 That way we can be consistent that we are always doing the
00:46:32.508 --> 00:46:35.486 same thing with the stuff, even if it's different classes or
00:46:35.486 --> 00:46:38.610 different, you know, properties on these classes because of the
00:46:38.610 --> 00:46:39.977 way the different ones work.
00:46:40.507 --> 00:46:44.303 Umm for stuff and I wanna make sure that you know we're we're
00:46:40.997 --> 00:46:41.247 Umm.
00:46:44.303 --> 00:46:48.099 logging in a consistent manner on these payment providers too
00:46:48.099 --> 00:46:51.651 of like, you know this is the request of going to send to
00:46:51.651 --> 00:46:52.997 authorize the payment.
00:46:53.007 --> 00:46:54.577 This is the request I got back.
00:46:54.587 --> 00:46:56.777 This is the response I got back from the server.
00:46:57.247 --> 00:46:59.787 This is the request I made to create a wallet entry.
00:46:59.797 --> 00:47:03.834 This is a response back I got for it and then like pairing
00:47:03.834 --> 00:47:07.802 them together as logs so that when logging is on and it's
00:47:05.837 --> 00:47:06.057 Umm.
00:47:07.802 --> 00:47:11.565 doing all that stuff, it's really easy to backtrack no
00:47:11.565 --> 00:47:16.012 matter which payment provider it is, what entries were occurring
00:47:16.012 --> 00:47:17.517 where inside our logs.
00:47:17.527 --> 00:47:21.677 But but of course don't include the most sensitive customer data
00:47:21.677 --> 00:47:25.571 about them, just that we did send stuff and that we got back
00:47:21.917 --> 00:47:22.157 Umm.
00:47:25.571 --> 00:47:29.337 in the specific area codes where where it said like error.
00:47:29.347 --> 00:47:33.447 The ZIP code is field is in the wrong format or error.
00:47:33.457 --> 00:47:37.081 The year for expiration date must be 4 digits and not to or
00:47:37.081 --> 00:47:40.824 something like that or at the expiration dates in the past or
00:47:40.417 --> 00:47:40.867 Umm.
00:47:40.824 --> 00:47:44.447 the card was declined by the payment processor or whatever.
00:47:44.977 --> 00:47:45.487 Umm.
00:47:45.227 --> 00:47:45.387 Yeah.
00:47:45.877 --> 00:47:49.578 And then we need to we do need to eventually get to a point
00:47:49.578 --> 00:47:53.587 where with the payment providers where we're doing a more common
00:47:53.587 --> 00:47:56.917 handling of of common issues like insufficient funds.
00:47:57.567 --> 00:48:02.447 Umm, you know, in the account we don't handle that consistently
00:47:57.927 --> 00:47:58.127 Yeah.
00:48:02.447 --> 00:48:06.107 anywhere and we don't even show that in the UI.
00:48:03.217 --> 00:48:03.457 Yeah.
00:48:06.177 --> 00:48:08.893 So the customer just gets a a generic error that says
00:48:08.893 --> 00:48:11.507 something went wrong it but they have no idea what.
00:48:09.777 --> 00:48:10.057 Yeah.
00:48:11.697 --> 00:48:13.927 When we could be telling them you have insufficient funds, you
00:48:13.927 --> 00:48:14.917 should check with your bank.
00:48:15.607 --> 00:48:16.057 Umm.
00:48:15.967 --> 00:48:16.187 Yeah.
00:48:16.287 --> 00:48:18.900 Or your payment was declined by the bank for whatever reason,
00:48:18.900 --> 00:48:20.417 because your cards on a fraud hold.
00:48:20.747 --> 00:48:21.977 You know, that kind of thing.
00:48:21.777 --> 00:48:22.037 Yeah.
00:48:21.987 --> 00:48:26.219 There were some errors that we can be pushing out on that
00:48:26.219 --> 00:48:30.743 stuff, but others that are like this credit card isn't a real
00:48:30.743 --> 00:48:35.193 number type of thing like we should be kicking those over to
00:48:35.193 --> 00:48:37.017 obfuscated logs on stuff.
00:48:35.907 --> 00:48:38.957 Yep, you know that makes.
00:48:37.207 --> 00:48:39.807 But there's things like that to go deal with.
00:48:40.267 --> 00:48:41.707 Yeah, there's that makes perfect sense.
00:48:41.717 --> 00:48:45.035 That probably be a good idea because obviously right now if
00:48:45.035 --> 00:48:48.352 you do, you know for whatever reason, you know, I guess not
00:48:48.352 --> 00:48:49.457 for whatever reason.
00:48:49.467 --> 00:48:52.172 But let's say, let's say we have a client who says hey, like this
00:48:52.172 --> 00:48:53.687 person just said insufficient funds.
00:48:54.147 --> 00:48:57.666 Why am I getting like a something went wrong, log ID or
00:48:57.666 --> 00:48:59.487 whatever, right or something.
00:48:58.757 --> 00:48:58.937 Yeah.
00:49:00.437 --> 00:49:03.037 Obviously, if someone wanted that, yeah.
00:49:00.767 --> 00:49:04.957 Yeah, we had a lot of those in CMMC where people are trying to
00:49:04.957 --> 00:49:08.747 use like a, you know, they're buying a $6000 like annual
00:49:08.747 --> 00:49:13.002 license or annual membership fee and they would consistently be
00:49:09.337 --> 00:49:09.597 Umm.
00:49:13.002 --> 00:49:14.797 trying to use like AP card.
00:49:15.347 --> 00:49:17.777 But P cards are special.
00:49:17.787 --> 00:49:21.335 They don't work everywhere, so like it can decline the fact
00:49:21.335 --> 00:49:25.118 that the car, because it is a P card or it could define decline
00:49:25.118 --> 00:49:28.724 it because the accounting team inside your company forgot to
00:49:28.724 --> 00:49:32.626 pay the bill on it low enough to where there would be $6000 worth
00:49:32.626 --> 00:49:33.867 of room on your card.
00:49:34.227 --> 00:49:34.427 Umm.
00:49:34.257 --> 00:49:38.514 To put it in there, so that was a very common occurrence at 1st
00:49:38.514 --> 00:49:42.704 and we had to educate the CMMC like CSR team like, hey, that's
00:49:42.704 --> 00:49:43.967 gonna happen a lot.
00:49:44.657 --> 00:49:47.286 You just gotta deal with it, like and just tell the client
00:49:47.286 --> 00:49:49.915 they need to use a different card or they need to pay down
00:49:49.915 --> 00:49:51.607 their bill first before trying again.
00:49:51.047 --> 00:49:51.407 Down.
00:49:52.167 --> 00:49:52.697 Umm.
00:49:53.127 --> 00:49:56.263 Or use like an alternate payment procedure where you send them a
00:49:56.263 --> 00:49:59.206 a separate invoice that they can pay with like an E check or
00:49:59.206 --> 00:50:02.341 whatever that you don't have set up inside your website which is
00:50:02.341 --> 00:50:03.547 only taking credit cards.
00:50:04.267 --> 00:50:04.937 That kind of thing.
00:50:06.427 --> 00:50:06.717 Yeah.
00:50:06.727 --> 00:50:11.239 No, I think, yeah, I think in terms of this specific provider
00:50:11.239 --> 00:50:15.387 with commo, it wasn't this method, but there another one
00:50:15.387 --> 00:50:19.608 that puts some custom fields into like the actual payment
00:50:19.608 --> 00:50:20.117 itself.
00:50:20.127 --> 00:50:22.217 So if something goes wrong, they can just look and see.
00:50:22.227 --> 00:50:24.187 Like what went wrong or what?
00:50:24.197 --> 00:50:26.647 Actually, I think I think the provider itself concludes that
00:50:26.647 --> 00:50:29.177 either way in terms of logging whatever, hey, what went wrong?
00:50:29.187 --> 00:50:30.847 Can we see and then I can check the status code.
00:50:30.857 --> 00:50:31.147 Whatever.
00:50:31.407 --> 00:50:34.288 Yeah, umm, you know, there's gonna be clients that are gonna
00:50:34.288 --> 00:50:37.310 wanna be able to handle certain use cases with maybe a specific
00:50:37.310 --> 00:50:37.687 message.
00:50:37.697 --> 00:50:40.719 And right now, there's no generalized thing to build that
00:50:40.719 --> 00:50:44.105 out or not to handle it, so that would probably be a really good
00:50:43.187 --> 00:50:43.407 Yeah.
00:50:44.105 --> 00:50:46.917 idea to have generic handling of different responses.
00:50:47.917 --> 00:50:49.967 Umm, because there's a lot.
00:50:48.187 --> 00:50:51.061 Yeah, like if, if if we fed all the responses through a
00:50:51.061 --> 00:50:54.346 particular function and then we gave it a switch statement that
00:50:54.346 --> 00:50:57.425 says if the error message says this then you can reply with
00:50:57.425 --> 00:51:00.504 this and then that would be function that we could override
00:51:00.504 --> 00:51:03.430 easily inside a client override project and add customer
00:51:02.857 --> 00:51:03.117 Umm.
00:51:03.430 --> 00:51:06.457 responses that that client wants for different situations.
00:51:06.647 --> 00:51:06.807 Yeah.
00:51:06.667 --> 00:51:09.791 And usually these payment providers have the list of the
00:51:09.791 --> 00:51:13.134 most common error codes and error messages that you're going
00:51:13.134 --> 00:51:14.777 to get from the have provider.
00:51:14.907 --> 00:51:17.692 So we can just turn that copy that off the web page, turn it
00:51:17.692 --> 00:51:19.107 into a Switch statement and go.
00:51:19.967 --> 00:51:24.176 And so I'd like to start seeing something like that happen in
00:51:20.387 --> 00:51:20.657 Yeah.
00:51:24.176 --> 00:51:25.397 core on something.
00:51:25.407 --> 00:51:29.005 So the next time someone builds a payment provider, hey, if you
00:51:29.005 --> 00:51:32.322 wanna try and build some of that out for us, for core, get
00:51:32.322 --> 00:51:33.727 permission and go for it.
00:51:35.847 --> 00:51:38.717 Well, uh, I apologize if it's me.
00:51:39.307 --> 00:51:40.417 I messed up, but no.
00:51:41.387 --> 00:51:42.077 Yeah, I've.
00:51:42.127 --> 00:51:45.757 I've had a couple of these and I do, but again, even though the
00:51:45.757 --> 00:51:49.272 the one, the one painful thing that will happen with a lot of
00:51:49.272 --> 00:51:52.901 these is oftentimes, I know at least with serve first like even
00:51:52.901 --> 00:51:56.133 the the fields in which they return the information that
00:51:56.133 --> 00:51:59.762 you'd be able to parse to say, hey, it was this kind of problem
00:51:59.762 --> 00:52:03.278 can be different like it can be in, in any one of these given
00:52:03.278 --> 00:52:06.850 fields for whatever reason like and not even in all of them or
00:52:06.850 --> 00:52:07.587 specific one.
00:52:07.597 --> 00:52:12.016 It moves around depending on what kind of issue it is, so
00:52:12.016 --> 00:52:16.815 there's a lot of like cases to account for, but regardless, in
00:52:16.815 --> 00:52:21.614 the future we started building these out so that at least some
00:52:21.614 --> 00:52:24.737 of the most common problems are handled.
00:52:24.887 --> 00:52:28.195 That would probably be good for the end user, Even so that when
00:52:28.195 --> 00:52:31.451 someone goes to their to, you know, one of our sites and tries
00:52:31.451 --> 00:52:34.655 to pay for something and it's a simple problem like you don't
00:52:34.655 --> 00:52:37.756 have enough funds or whatever, they see that by default and
00:52:37.756 --> 00:52:40.909 it's not like a mystery where the hit up support and they're
00:52:40.909 --> 00:52:42.717 like, hey, are crap isn't working.
00:52:42.727 --> 00:52:44.697 We need to developer to come fix it whatever.
00:52:45.007 --> 00:52:48.206 When, when at the end of the day it was really just that someone
00:52:48.206 --> 00:52:51.207 didn't have enough money on their card or whatever, so yeah.
00:52:54.897 --> 00:52:57.537 Was there anything specific we wanted to look at?
00:52:55.157 --> 00:52:55.447 Where?
00:53:00.937 --> 00:53:01.197 Uh.
00:53:02.547 --> 00:53:03.327 We'll talk about, I guess.
00:53:05.157 --> 00:53:08.154 I can't think of anything else really cause like passwords are
00:53:08.154 --> 00:53:11.198 already hash and we've already we've got a handling on like the
00:53:11.198 --> 00:53:12.387 the user password system.
00:53:12.397 --> 00:53:16.612 So visually, anybody, any person should have to do for that at
00:53:16.612 --> 00:53:17.347 this point.
00:53:17.977 --> 00:53:18.237 Umm.
00:53:18.397 --> 00:53:22.298 And if you do have some other kind of sensitive data that
00:53:22.298 --> 00:53:26.534 needs to not get out, just make sure you're blinking it before
00:53:26.534 --> 00:53:30.636 you log it wherever it is, even if it's the sandbox mode, or
00:53:30.636 --> 00:53:32.317 even if it's we're in QA.
00:53:32.527 --> 00:53:36.589 You need to take the effort to go ahead and blink it there too,
00:53:36.447 --> 00:53:36.717 Umm.
00:53:36.589 --> 00:53:40.460 so that there's no that there is a zero chance that it could
00:53:40.460 --> 00:53:44.204 happen in production because somebody said a flag wrong or
00:53:41.907 --> 00:53:42.067 Yeah.
00:53:44.204 --> 00:53:47.757 set of thing wrong, that it was then able to log to it.
00:53:47.767 --> 00:53:48.347 We need to stop.
00:53:48.587 --> 00:53:50.037 To stop it from ever happening, period.
00:53:51.167 --> 00:53:53.817 No, that makes sense. I've.
00:53:52.957 --> 00:53:55.586 And then the only and then the only effective time where you
00:53:55.586 --> 00:53:58.257 can see that information is if you're debugging and attached.
00:53:59.377 --> 00:54:06.007 Umm I have a a semi adjacent questions slash topic of
00:54:06.007 --> 00:54:07.357 discussion.
00:54:07.367 --> 00:54:09.347 Assuming we're we're OK to move on.
00:54:10.487 --> 00:54:13.127 Umm, Tim, that's OK.
00:54:17.567 --> 00:54:18.767 Ohh yeah, I was muted.
00:54:18.777 --> 00:54:19.307 Keep rolling.
00:54:20.317 --> 00:54:24.546 OK, I'm only bringing this up because I've seen it at least on
00:54:24.546 --> 00:54:28.372 two projects, say at least probably 3 or 4, but it seems
00:54:28.372 --> 00:54:32.198 like there's a common thing where a lot of databases are
00:54:32.198 --> 00:54:36.024 getting bloat from, like system dot log or whatever, and
00:54:36.024 --> 00:54:40.454 obviously all the important logs are usually log level 10 for the
00:54:40.454 --> 00:54:41.527 most part right?
00:54:41.537 --> 00:54:44.897 Which is the error if I'm like, usually those are errors, right,
00:54:44.897 --> 00:54:45.207 James?
00:54:46.157 --> 00:54:51.118 Yes, 10 should be error 20 should be warning in 30, should
00:54:51.118 --> 00:54:52.547 be informational.
00:54:52.957 --> 00:54:56.607 Is there a kernel? Umm.
00:54:53.187 --> 00:54:53.747 Then you can.
00:54:53.757 --> 00:54:57.005 Technically, you can customize those numbers and add numbers in
00:54:57.005 --> 00:54:59.999 between, but that's just the defaults that I set up a long
00:54:59.999 --> 00:55:03.043 time ago so that we would have numbers to work with that we
00:55:03.043 --> 00:55:04.007 could later expand.
00:55:03.427 --> 00:55:10.208 Umm yeah, I my question is is is there a general way at this time
00:55:10.208 --> 00:55:16.269 to clear out those like let's say old stale log entries in
00:55:16.269 --> 00:55:19.967 order to save space and stop bloat?
00:55:19.977 --> 00:55:21.717 Or is that not currently a thing?
00:55:21.207 --> 00:55:21.867 Uh.
00:55:22.197 --> 00:55:26.109 Find find out the a log ID the the the the first log ID for
00:55:26.109 --> 00:55:30.216 like 30 days ago and then and then go through and just call it
00:55:30.216 --> 00:55:34.127 delete query for anything that's all other than that and if
00:55:34.127 --> 00:55:38.299 that's done on a regular basis it should never be a big deal to
00:55:38.299 --> 00:55:41.037 just make that query call and just do it.
00:55:41.047 --> 00:55:44.347 It should be a big deal if you've got millions of records
00:55:42.857 --> 00:55:43.087 Yeah.
00:55:44.347 --> 00:55:46.337 in there, that query is gonna die.
00:55:47.797 --> 00:55:49.677 Because it's not gonna work very fast.
00:55:49.687 --> 00:55:53.640 So you need to add like top 10,000 to that and that will
00:55:52.687 --> 00:55:52.717 E.
00:55:53.640 --> 00:55:57.107 keep it from blowing up the log size or whatever.
00:55:57.197 --> 00:56:01.884 Or sorry that the logs not our log but like the SQL log for the
00:56:00.477 --> 00:56:00.977 LDF.
00:56:01.884 --> 00:56:04.447 yeah, the LDF file for blowing up.
00:56:05.647 --> 00:56:09.832 Umm but if if if it's like you have all of this data in there
00:56:09.832 --> 00:56:14.085 and not even the last 30 days where the logs are even gonna be
00:56:14.085 --> 00:56:16.717 relevant, just call it truncate table.
00:56:19.557 --> 00:56:19.837 OK.
00:56:19.647 --> 00:56:22.438 And that'll that'll literally wipe it back as if it was a
00:56:22.438 --> 00:56:23.207 brand new table.
00:56:23.217 --> 00:56:27.155 And since system log doesn't directly reference any foreign
00:56:27.155 --> 00:56:31.355 keys or anything, it's able to do that to go wipe all that kind
00:56:28.557 --> 00:56:28.817 Umm.
00:56:31.355 --> 00:56:34.767 of stuff out, which is nice for that kind of stuff.
00:56:32.147 --> 00:56:32.447 OK.
00:56:34.777 --> 00:56:39.447 But another thing you would do is go ahead and bring up a
00:56:39.447 --> 00:56:44.198 browser and go to Google and search for and I sequel T SQL
00:56:44.198 --> 00:56:45.727 Delete wall exists.
00:56:48.267 --> 00:56:49.797 He said delete. Uh.
00:56:50.677 --> 00:56:51.637 While exists.
00:56:54.587 --> 00:56:55.587 Well exists.
00:56:58.697 --> 00:57:01.497 Yep, grab that first one.
00:57:05.837 --> 00:57:09.707 EI don't want to go to the answer that question, uh.
00:57:07.927 --> 00:57:08.147 Yeah.
00:57:10.637 --> 00:57:11.127 Yes.
00:57:11.137 --> 00:57:14.914 OK, So what this would do is is, you know, if we've got 20
00:57:14.914 --> 00:57:18.947 million records to to delete and we can only do 10,000 a time.
00:57:19.497 --> 00:57:22.266 You don't wanna sit there and wait 8 seconds, delete 8
00:57:22.266 --> 00:57:24.984 seconds, delete 8 seconds, delete over and over again
00:57:24.984 --> 00:57:25.437 yourself.
00:57:25.477 --> 00:57:25.717 Umm.
00:57:25.657 --> 00:57:29.507 This loop is a way to do that so that you can.
00:57:30.297 --> 00:57:35.984 It will execute the query over and over again as it goes on the
00:57:35.984 --> 00:57:39.537 stuff, and by using an ID number on it.
00:57:36.407 --> 00:57:36.647 Umm.
00:57:39.687 --> 00:57:44.612 But it versus like the the date, the date query filtering is a
00:57:44.612 --> 00:57:48.677 much slower than the identifier ID filtering on it.
00:57:47.037 --> 00:57:47.257 Umm.
00:57:48.687 --> 00:57:50.997 So you wanna find out what that number is?
00:57:51.007 --> 00:57:53.957 Use that number and throw it into there and this will count.
00:57:52.417 --> 00:57:52.597 Yeah.
00:57:53.967 --> 00:57:56.727 Will check to see how many rows it was able to delete until
00:57:56.727 --> 00:57:59.303 there, and it will just do that until it stops deleting
00:57:59.303 --> 00:57:59.717 anything.
00:58:00.387 --> 00:58:03.592 So it comes back with zero results from the delete
00:58:03.592 --> 00:58:04.157 function.
00:58:04.587 --> 00:58:06.677 Then it will stop the loop and it will just exit out.
00:58:07.547 --> 00:58:09.357 It's a good way to get that stuff done.
00:58:09.367 --> 00:58:11.229 Unfortunately, I'd never remembered the syntax, so I
00:58:11.229 --> 00:58:13.231 always have to Google it and bring it back up a copy and
00:58:13.231 --> 00:58:13.547 paste it.
00:58:14.157 --> 00:58:20.550 Umm to drop it in here so so again from what I was saying
00:58:16.897 --> 00:58:17.177 OK.
00:58:17.957 --> 00:58:18.597 Yeah, that makes sense.
00:58:20.550 --> 00:58:27.054 there I would uh select top I would I would select top 100
00:58:27.054 --> 00:58:33.777 from system log order by ID ascending where date is equal or
00:58:33.777 --> 00:58:40.391 like the date is like greater than what I think 30 days ago
00:58:40.391 --> 00:58:43.697 might have been appropriately.
00:58:43.707 --> 00:58:45.277 It's not actually be 30 days.
00:58:44.487 --> 00:58:44.817 Hmm.
00:58:45.287 --> 00:58:48.422 It could just be like be getting of July or July 14th or
00:58:48.422 --> 00:58:48.917 whatever.
00:58:48.927 --> 00:58:53.283 You're gonna pick as your date, and then that will give me an ID
00:58:50.507 --> 00:58:50.797 Umm.
00:58:53.283 --> 00:58:57.103 number and then by delete function I'll do anything that
00:58:57.103 --> 00:59:01.324 is an ID less than that number to throw on there and that will
00:58:58.887 --> 00:58:59.107 Umm.
00:59:01.324 --> 00:59:05.345 flush the system log down so that only the most recent logs
00:59:05.345 --> 00:59:09.432 are in there and all the other irrelevant information should
00:59:09.432 --> 00:59:12.447 just be straight up gone at that point. Umm.
00:59:09.957 --> 00:59:13.377 Umm in terms of.
00:59:13.647 --> 00:59:14.347 Ohh go ahead sorry.
00:59:15.407 --> 00:59:19.577 Uh, that will work almost all the time for the system log.
00:59:21.787 --> 00:59:25.254 Stuff you may wanna filter that to where it's, you know
00:59:25.254 --> 00:59:28.781 additionally only or deleting the info level records and
00:59:28.781 --> 00:59:29.957 leaving the errors.
00:59:29.967 --> 00:59:33.714 So you would it would add like and log level equal to or and
00:59:30.547 --> 00:59:30.727 Yeah.
00:59:33.714 --> 00:59:37.091 log level greater than 10 because it's greater than 10
00:59:37.091 --> 00:59:39.977 then it's not an error and that kind of thing.
00:59:38.417 --> 00:59:38.717 Yep.
00:59:41.557 --> 00:59:45.561 Another thing is, uh, there the most common thing that I've seen
00:59:45.561 --> 00:59:48.948 blow up in these tables over time has been the product
00:59:48.948 --> 00:59:52.643 categories table because of the way connect talks to it, it
00:59:52.643 --> 00:59:56.400 might be wiping and reloading your categories on the product
00:59:56.400 --> 00:59:57.077 every time.
00:59:57.767 --> 00:59:58.227 Hmm.
00:59:59.067 --> 01:00:02.302 That's been the most common case where you can end up with 20
01:00:02.302 --> 01:00:03.867 million dead records in there.
01:00:04.457 --> 01:00:08.920 Umm, it's the same thing where you basically just delete where
01:00:04.637 --> 01:00:04.987 Umm.
01:00:08.920 --> 01:00:12.037 active equals zero on the table and repeat.
01:00:12.047 --> 01:00:15.003 Rinse and repeat until it's done, and then once you have
01:00:13.977 --> 01:00:14.227 Umm.
01:00:15.003 --> 01:00:18.322 done that and now the database is performing better, you've got
01:00:18.322 --> 01:00:21.434 to work with the Kinect dev to make sure that that issue is
01:00:21.434 --> 01:00:24.597 resolved for that client so it does not build back up again.
01:00:25.217 --> 01:00:25.477 Yeah.
01:00:26.397 --> 01:00:28.511 And if it's not product categories and it's something
01:00:28.511 --> 01:00:29.097 else, so be it.
01:00:29.107 --> 01:00:32.113 Whatever thing is is doing and blowing up itself because of the
01:00:32.113 --> 01:00:32.347 sink.
01:00:32.977 --> 01:00:35.546 You know whether it's connect causing the problem itself
01:00:35.546 --> 01:00:36.447 causing the problem.
01:00:36.647 --> 01:00:40.107 The two of you need to work together to make sure that the
01:00:40.107 --> 01:00:43.626 problem gets resolved for that project, and if it was a SEV
01:00:43.626 --> 01:00:47.085 side issue, especially get a core PR in so that we can get
01:00:47.085 --> 01:00:50.956 that cleaned up because we don't want that to just keep happening
01:00:50.956 --> 01:00:53.887 to new clients in the future over and over again.
01:00:54.747 --> 01:00:54.967 Umm.
01:00:58.437 --> 01:01:02.427 In regards to the LDF file specifically, is there a way to
01:01:02.427 --> 01:01:06.483 shrink that down reliably, or is that kind of just gonna be
01:01:06.483 --> 01:01:07.497 whatever it is?
01:01:07.587 --> 01:01:08.797 Uh, because it's a log file.
01:01:10.927 --> 01:01:14.010 I believe there are SQL commands that you can tell it in SSMS to
01:01:14.010 --> 01:01:16.997 shrink that file, but I don't know them off the top of my head
01:01:16.997 --> 01:01:18.277 other than shrink database.
01:01:19.547 --> 01:01:19.827 OK.
01:01:19.687 --> 01:01:21.497 Uh, I don't know about shrinking.
01:01:21.507 --> 01:01:25.322 I don't know what shrinking the LDF file does specifically, or
01:01:25.322 --> 01:01:29.015 what command does that, and I'm usually not worried about it
01:01:29.015 --> 01:01:32.587 because it's because it's usually not that bad compared to
01:01:32.587 --> 01:01:36.037 the contents of the database itself, but is problematic.
01:01:34.957 --> 01:01:35.237 Umm.
01:01:36.507 --> 01:01:40.774 We do used to utilize because we would run out of space all the
01:01:40.774 --> 01:01:41.107 time.
01:01:43.337 --> 01:01:47.247 A script that is available in the file share or it was.
01:01:47.257 --> 01:01:50.591 I have no idea where it sits anymore since those that server
01:01:49.197 --> 01:01:49.457 Umm.
01:01:50.591 --> 01:01:51.137 got moved.
01:01:51.827 --> 01:01:57.054 Umm it is a script that would read out all of the databases in
01:01:57.054 --> 01:02:02.197 uh in the server the the SQL Server that you were looking at.
01:02:02.207 --> 01:02:06.162 So like it was SQL 2019, you would look at SQL 2019 and go
01:02:05.167 --> 01:02:05.417 Umm.
01:02:06.162 --> 01:02:10.452 grab every single database name that had Seth in it and then it
01:02:10.452 --> 01:02:14.273 would spit out like truncate table system logs, truncate
01:02:14.273 --> 01:02:18.228 table, the hangfire log ones stuff so that those could get
01:02:18.228 --> 01:02:22.250 reset and basically it would it would spit those out as SQL
01:02:22.250 --> 01:02:22.987 statements.
01:02:22.997 --> 01:02:25.425 You would then copy those SQL statements from those results
01:02:25.425 --> 01:02:27.853 and then you put them into the into the runner and then you
01:02:27.853 --> 01:02:30.443 would run them all and it would knock all that stuff out and it
01:02:30.443 --> 01:02:31.737 would do the same thing for DNN.
01:02:31.747 --> 01:02:36.493 It would talk like the scheduler history and the exception logs
01:02:36.493 --> 01:02:41.164 of the DNN tables to go clear all that stuff out too, and then
01:02:41.164 --> 01:02:45.613 the third thing it would do is go make sure that all of our
01:02:45.613 --> 01:02:49.987 databases on our SQL Server 2019, 2016, whatever and were.
01:02:51.917 --> 01:02:55.305 We're all set to simplified logging and instead of full
01:02:55.305 --> 01:02:58.935 logging to make sure it's the log files physically couldn't
01:02:58.935 --> 01:03:02.262 grow to a point where they would ever become a problem
01:03:02.262 --> 01:03:02.927 themselves.
01:03:03.497 --> 01:03:03.717 Uh.
01:03:03.787 --> 01:03:04.107 OK.
01:03:03.817 --> 01:03:07.440 On on stuff, and usually what would happen is we'd have like 0
01:03:07.440 --> 01:03:10.947 bytes left on the server and by just running those queries I
01:03:10.947 --> 01:03:12.787 would clear a TB of information.
01:03:13.727 --> 01:03:16.957 Umm, like because it was like a TB and 1/2 drive.
01:03:16.967 --> 01:03:19.848 Anybody get down to like 500 gigs of like, actual data on
01:03:19.848 --> 01:03:22.679 there and it would take a while because it would have to
01:03:22.679 --> 01:03:24.417 physically go through an exercise.
01:03:24.427 --> 01:03:27.982 These commands on all these different databases, but when it
01:03:27.982 --> 01:03:31.128 was done it was totally worth all that time for it to
01:03:31.128 --> 01:03:32.817 physically do all that stuff.
01:03:33.197 --> 01:03:37.073 And every now and then you find like this database is still
01:03:37.073 --> 01:03:38.817 using a lot of extra space.
01:03:39.027 --> 01:03:40.267 Where's all that space coming from?
01:03:40.277 --> 01:03:43.431 And that's where I would identify stuff like the product
01:03:43.431 --> 01:03:46.639 categories thing where it was something that had blown up
01:03:46.639 --> 01:03:49.737 because of a sync causing something to happen regularly
01:03:49.737 --> 01:03:53.278 and nothing and no one had ever bothered to come back and clean
01:03:53.278 --> 01:03:54.107 it up on stuff.
01:03:54.117 --> 01:03:56.247 So look at your databases, see.
01:03:56.317 --> 01:03:57.407 See what they're doing?
01:03:57.877 --> 01:04:00.658 One way that you can find out if a database is using too much
01:04:00.658 --> 01:04:00.927 space.
01:04:01.317 --> 01:04:03.737 If you scroll up and right click on the database itself.
01:04:10.287 --> 01:04:11.307 And then go to reports.
01:04:15.957 --> 01:04:17.137 And then standard reports.
01:04:19.027 --> 01:04:20.557 Disk usage by top tables.
01:04:20.567 --> 01:04:21.247 It's the third one.
01:04:26.177 --> 01:04:30.227 This will show you the allocated value data that is there, not.
01:04:30.237 --> 01:04:31.927 You obviously got a really tiny database here.
01:04:31.937 --> 01:04:32.977 This isn't a very big one.
01:04:33.487 --> 01:04:33.747 Yeah.
01:04:33.777 --> 01:04:34.097 Go.
01:04:34.637 --> 01:04:39.257 Do you like ADI CEF QA or adisq stage?
01:04:43.527 --> 01:04:45.807 And then once you use, that report is now actually in the
01:04:45.807 --> 01:04:46.357 shortcut menu.
01:04:46.367 --> 01:04:48.057 Here below you don't have to go away to.
01:04:48.067 --> 01:04:49.547 The third one it's on the second one, no.
01:04:49.537 --> 01:04:50.447 No. OK.
01:04:51.457 --> 01:04:52.757 So this one got a lot bigger stuff.
01:04:52.767 --> 01:04:55.837 This one got 287,000 product categories and those are
01:04:55.837 --> 01:04:58.906 actually legit because previously that had 20 million
01:04:58.906 --> 01:04:59.247 in it.
01:04:59.707 --> 01:05:04.318 Umm yeah, because the the this was one of the clients where
01:04:59.937 --> 01:05:00.237 Well.
01:05:04.318 --> 01:05:05.777 that was a problem.
01:05:05.787 --> 01:05:07.307 I think GFS was also doing it too.
01:05:08.727 --> 01:05:12.594 Voters are there and just remind you, like the automated backups
01:05:12.594 --> 01:05:16.103 that are backing up all these databases on a regular basis
01:05:16.103 --> 01:05:19.909 like 4 hour or 12 hour or daily or whatever it is, every one of
01:05:19.757 --> 01:05:20.057 Umm.
01:05:19.909 --> 01:05:22.407 those backups has all of that data in it.
01:05:22.797 --> 01:05:27.321 So we're flooding guns and tons of data into our Nas drives for
01:05:23.017 --> 01:05:23.197 Yeah.
01:05:27.321 --> 01:05:31.703 backups for no reason, because it's just it's just extra data
01:05:31.703 --> 01:05:35.307 that needs to go away and no one should ever have.
01:05:35.577 --> 01:05:39.496 We also get like at some point things like those AFC Arrow
01:05:39.496 --> 01:05:43.680 financials, those need to get turned off and taken out because
01:05:43.680 --> 01:05:45.207 they're dead databases.
01:05:45.217 --> 01:05:46.887 They were just being used for an upgrade process.
01:05:46.897 --> 01:05:50.526 That model we happened a year ago and no one has dealt with
01:05:50.526 --> 01:05:54.336 anything on those sentence, and now that they're done, we need
01:05:54.336 --> 01:05:58.085 to get them out of the way so that the server doesn't have to
01:05:58.085 --> 01:06:01.653 have them up and processing every database that is in here
01:06:01.653 --> 01:06:04.737 and online is using resources in the SQL 2019 box.
01:06:05.627 --> 01:06:05.937 Umm.
01:06:06.097 --> 01:06:08.467 Whether it's being actively called or not, it's there.
01:06:08.477 --> 01:06:09.667 It's loaded stuff in memory.
01:06:09.677 --> 01:06:13.628 It's doing, you know, reporting and analysis values that are
01:06:13.628 --> 01:06:15.247 that automatically occur.
01:06:15.437 --> 01:06:18.731 All of those things are happening to those databases,
01:06:18.731 --> 01:06:20.927 even if no one actively using them.
01:06:21.097 --> 01:06:24.811 So if we can clear that kind of stuff out to turn them off, get
01:06:24.811 --> 01:06:25.507 rid of them.
01:06:25.517 --> 01:06:28.878 Whatever we're gonna do the better I could see stuff where
01:06:28.878 --> 01:06:32.467 we've got, like, restores here for, like ACCU on like CEF prod
01:06:32.467 --> 01:06:33.207 and CEF demo.
01:06:34.267 --> 01:06:34.507 Umm.
01:06:34.757 --> 01:06:37.626 And if you need to restore a copy of that to like your local
01:06:37.626 --> 01:06:40.447 or whatever to go to, go double check something and fix it.
01:06:40.457 --> 01:06:45.043 Fine, but let's not clutter up the main server that everybody
01:06:45.043 --> 01:06:48.667 tries to talk to on with all of this extra junk.
01:06:48.937 --> 01:06:52.393 If we can, or if you need to put it up there so that multiple can
01:06:52.393 --> 01:06:53.387 see it temporarily.
01:06:53.497 --> 01:06:56.247 OK, but when it's done, let's archive it.
01:06:56.917 --> 01:07:00.943 Let's take the backup of it and then get rid of the MDF, LDF by
01:07:00.943 --> 01:07:02.767 detaching it and dropping it.
01:07:02.777 --> 01:07:05.956 And then going into the server and getting rid of those files
01:07:05.956 --> 01:07:08.417 and zip up the backup file and put it in there.
01:07:08.507 --> 01:07:14.166 I had an ADI backup that was over 50 gigs yesterday that I
01:07:14.166 --> 01:07:20.112 had to zip down to 1.2 gigs in order to make room on the hard
01:07:20.112 --> 01:07:20.687 drive.
01:07:21.927 --> 01:07:25.097 Yeah, yesterday because we had 40 gigs of hard drive space and
01:07:25.097 --> 01:07:26.807 we now have a total of about 400.
01:07:27.287 --> 01:07:30.505 After I cleared everything up and in there and that's why I
01:07:29.357 --> 01:07:29.607 Umm.
01:07:30.505 --> 01:07:33.991 put that post inside the develop channel about, you know, making
01:07:33.991 --> 01:07:37.263 sure you take backups and that you take them with names that
01:07:37.263 --> 01:07:40.748 make sense so that we can find, you know, what the hell database
01:07:40.748 --> 01:07:41.177 is this?
01:07:41.327 --> 01:07:45.390 What is this backup of kind of thing and clearing those kinds
01:07:43.317 --> 01:07:43.547 Umm.
01:07:45.390 --> 01:07:46.307 of things out?
01:07:47.127 --> 01:07:49.650 I'm sure it's never gonna go away completely, and I'm sure
01:07:47.567 --> 01:07:47.917 Else.
01:07:49.650 --> 01:07:52.386 that people are still gonna be confused about which server they
01:07:52.386 --> 01:07:54.737 should look at for whatever reason on different stuff.
01:07:54.747 --> 01:07:57.589 But if you see a database there, that is our project you're
01:07:57.589 --> 01:08:00.242 working on and you can double check with the other team
01:08:00.242 --> 01:08:01.757 members who are working on that.
01:08:01.767 --> 01:08:05.827 No one's using this particular copy of a database, then work to
01:08:05.827 --> 01:08:09.759 get rid of it so that we can declutter what we're looking at,
01:08:09.759 --> 01:08:10.837 and it will make.
01:08:10.877 --> 01:08:14.455 It'll help reduce confusion for everyone, and we can clean some
01:08:14.455 --> 01:08:16.467 stuff up and get it all sorted out.
01:08:19.057 --> 01:08:21.953 Feel it's not a forget one underscore, missing data,
01:08:21.953 --> 01:08:24.247 whatever that database is being used for.
01:08:24.777 --> 01:08:31.318 Not sure it's pop quiz tub, but it would just that is I think
01:08:31.318 --> 01:08:35.537 the top one is EP But I'm not sure. Uh.
01:08:35.067 --> 01:08:38.956 MISH, QV one should be either be EP or it's one of the internal
01:08:38.956 --> 01:08:42.358 like like CRM databases and I have no idea what the one
01:08:42.358 --> 01:08:46.003 missing data is and I have no doubt idea how long it's been
01:08:46.003 --> 01:08:46.367 there.
01:08:46.737 --> 01:08:49.900 There have been points over the years where I have like gone
01:08:49.900 --> 01:08:53.011 through and like literally just started turning off a whole
01:08:53.011 --> 01:08:56.382 bunch of databases and then and then waited for someone to pitch
01:08:56.382 --> 01:08:59.285 umm that their database was offline and I'm going to be
01:08:59.285 --> 01:09:01.307 like, why are you using that database?
01:09:01.317 --> 01:09:02.857 And they're like, because that's the one I was using.
01:09:02.867 --> 01:09:04.999 I'm like what you should have been using the A1 or you should
01:09:04.999 --> 01:09:05.927 have been using your local.
01:09:07.227 --> 01:09:08.667 Why were you doing that here?
01:09:08.907 --> 01:09:09.197 Why?
01:09:09.207 --> 01:09:10.307 What are all these olds?
01:09:11.737 --> 01:09:14.747 We have a lot of demo databases from yourself.
01:09:15.557 --> 01:09:19.312 Yeah, and like the demo databases also don't necessarily
01:09:19.312 --> 01:09:23.330 make sense to what their what's actually using them, because
01:09:23.330 --> 01:09:27.217 like, we don't have three different CEF developed websites
01:09:27.217 --> 01:09:30.906 that need a set, a set, underscore 2A, self underscore,
01:09:30.906 --> 01:09:31.037 3.
01:09:31.047 --> 01:09:35.642 That's that doesn't make any sense and the databases for like
01:09:35.642 --> 01:09:40.088 the versions that are from three years ago for it's a or or
01:09:40.088 --> 01:09:44.238 older, should have been taken down by now because those
01:09:44.238 --> 01:09:46.387 websites are no longer there.
01:09:47.497 --> 01:09:48.057 There might be a.
01:09:48.067 --> 01:09:50.787 This might be a factor of like a database is sitting there to do
01:09:50.787 --> 01:09:51.707 a client that doesn't.
01:09:51.757 --> 01:09:54.387 Or A or a demo site that doesn't even exist anymore.
01:09:55.197 --> 01:09:55.987 Grass.
01:09:56.457 --> 01:09:57.257 Is that a client?
01:09:57.267 --> 01:09:58.177 We even still have.
01:09:58.187 --> 01:09:58.917 I thought they went away.
01:09:59.717 --> 01:10:01.027 Uh, you know?
01:10:01.417 --> 01:10:06.058 Obviously Como Jr, you know JBM Craig, you know, Mei, there's
01:10:06.058 --> 01:10:08.677 clients who are definitely active.
01:10:08.687 --> 01:10:10.787 Those guys are there that's there for a reason.
01:10:10.797 --> 01:10:11.207 Great.
01:10:11.817 --> 01:10:14.367 But if you've got a client who's gone live.
01:10:12.887 --> 01:10:14.567 I think MI is dead actually.
01:10:15.587 --> 01:10:19.654 Yeah, if if they're dead and gone, let's archive the database
01:10:19.654 --> 01:10:21.227 and get it out of there.
01:10:22.097 --> 01:10:22.457 Umm.
01:10:22.597 --> 01:10:25.681 It'll save a lot of our resources not just on that box,
01:10:25.681 --> 01:10:29.205 but also on our backups and all that other stuff that are being
01:10:29.205 --> 01:10:31.517 automated that just don't need to happen.
01:10:32.567 --> 01:10:37.563 And and I'd love to move all of the demo stuff off of here so
01:10:37.563 --> 01:10:42.478 that all or so that it's like all of our internal demos like
01:10:42.478 --> 01:10:47.071 like our internal payout, our internal HIPAA, decide our
01:10:47.071 --> 01:10:51.986 internal develop, our internal like R22-4 you know dev sites
01:10:51.986 --> 01:10:55.047 for for in queue for queuing of core.
01:10:55.137 --> 01:10:58.790 I'd love to move all of those to a separate box so that all of
01:10:55.637 --> 01:10:55.887 Umm.
01:10:58.790 --> 01:11:00.587 this is literally just clients.
01:11:01.407 --> 01:11:01.637 Umm.
01:11:01.797 --> 01:11:06.421 You know WBS, Val, Tesco and whatever on here, but that also
01:11:06.421 --> 01:11:10.817 requires someone sitting down and physically moving stuff
01:11:10.817 --> 01:11:11.347 around.
01:11:11.677 --> 01:11:15.599 Which who's gonna do that and how are we gonna get paid to do
01:11:15.599 --> 01:11:17.117 that and all that stuff?
01:11:17.127 --> 01:11:19.240 And then like, what's this database that literally just
01:11:19.240 --> 01:11:19.617 says test?
01:11:21.477 --> 01:11:21.907 Question.
01:11:21.917 --> 01:11:22.587 That's what.
01:11:24.037 --> 01:11:26.477 Like we have no idea whether that's accept database as a DNA
01:11:26.477 --> 01:11:28.717 database without actually opening it and looking at it.
01:11:30.197 --> 01:11:33.937 It's a nothing database, uh.
01:11:30.827 --> 01:11:31.897 Look, it's empty.
01:11:33.177 --> 01:11:34.807 It's it's literally nothing.
01:11:36.157 --> 01:11:36.457 Thick.
01:11:36.337 --> 01:11:39.422 So that's the kind of thing we need to get dev OPS cut to come
01:11:39.422 --> 01:11:42.457 in and migrate and move that stuff around and clean that out.
01:11:43.567 --> 01:11:45.687 And if we can but.
01:11:45.747 --> 01:11:46.797 Well, luckily there's not.
01:11:46.807 --> 01:11:48.697 Not a whole lot to migrate for that one so.
01:11:50.607 --> 01:11:52.817 Yeah, that one can be migrated into a trash can.
01:11:50.867 --> 01:11:51.057 Yeah.
01:11:50.877 --> 01:11:51.437 I think it's easy.
01:11:55.407 --> 01:11:56.127 Round Violet.
01:11:59.437 --> 01:11:59.987 Awesome.
01:11:59.997 --> 01:12:02.907 Well, I think we have a little over 10 minutes.
01:12:05.287 --> 01:12:09.356 So anything else that you wanted to look at or anything fun or
01:12:09.356 --> 01:12:10.647 cool or interesting?
01:12:13.507 --> 01:12:18.524 The latest version of Resharper actually told me about a C sharp
01:12:18.524 --> 01:12:23.232 language feature I did not know about where like how you can
01:12:20.827 --> 01:12:21.017 OK.
01:12:23.232 --> 01:12:23.617 have.
01:12:24.377 --> 01:12:28.757 Uh, OK, I should paste this because it's going to be hard
01:12:28.757 --> 01:12:31.097 for me to explain it otherwise.
01:12:33.637 --> 01:12:34.417 You can do this now.
01:12:42.997 --> 01:12:46.907 Where normally you'd have to use braces to define a body for the
01:12:46.907 --> 01:12:47.267 class.
01:12:47.577 --> 01:12:50.351 If you're not gonna have any contents to it, you can just put
01:12:50.351 --> 01:12:50.887 a semicolon.
01:12:52.647 --> 01:12:53.107 Ah.
01:12:53.657 --> 01:12:54.067 That's nice.
01:12:53.947 --> 01:12:56.217 And that's a normal language.
01:12:56.227 --> 01:12:57.237 C Sharp language feature now.
01:12:58.537 --> 01:13:00.437 Umm, I don't the thing, Richard.
01:12:58.907 --> 01:12:59.417 Is a.
01:12:59.477 --> 01:13:01.477 Is it like C sharp like latest?
01:13:02.517 --> 01:13:05.701 Yeah, I I've got it set to the language preview right now, so I
01:13:05.701 --> 01:13:08.786 don't know specifically which part of it it's doing that, but
01:13:08.377 --> 01:13:08.737 OK.
01:13:08.786 --> 01:13:12.069 umm, with the language of review and I have course at the preview
01:13:12.069 --> 01:13:12.467 as well.
01:13:14.677 --> 01:13:17.379 So I just went through and I applied that all over the place
01:13:17.379 --> 01:13:19.727 because it came up as it by default as a warning and
01:13:19.727 --> 01:13:21.277 Resharper and I was like ohh cool.
01:13:20.207 --> 01:13:20.527 Hmm.
01:13:21.287 --> 01:13:22.097 I can do that everywhere.
01:13:22.787 --> 01:13:25.249 Let me implement this change and it did it to the entire solution
01:13:25.249 --> 01:13:25.547 at once.
01:13:26.267 --> 01:13:27.577 Umm, which was cool.
01:13:28.297 --> 01:13:28.867 Umm.
01:13:28.647 --> 01:13:28.847 Nice.
01:13:29.137 --> 01:13:33.220 And then another thing that I saw was that Resharper actually
01:13:33.220 --> 01:13:37.500 discovered in in plus one issue in some code and warned me about
01:13:37.500 --> 01:13:37.697 it.
01:13:38.457 --> 01:13:41.156 I was like, holy crap, it actually identified 2 separate
01:13:38.837 --> 01:13:39.027 Hmm.
01:13:41.156 --> 01:13:43.713 spots inside of a single function where it identified
01:13:43.713 --> 01:13:46.791 that it was going to have to go back to the database to get more
01:13:46.791 --> 01:13:47.027 data.
01:13:47.527 --> 01:13:51.226 And so instead you should include that data for the call
01:13:51.226 --> 01:13:53.627 so that it wouldn't have to do that.
01:13:53.637 --> 01:13:56.335 I was like ohh wow, I didn't know it could do that and it
01:13:56.335 --> 01:13:58.707 might be a new feature of Resharper, but if it can
01:13:58.707 --> 01:14:00.567 identify that kind of problem, awesome.
01:14:02.997 --> 01:14:03.367 That's cool.
01:14:05.837 --> 01:14:09.027 I especially like the if it's like an empty whatever.
01:14:10.117 --> 01:14:16.494 Umm class declaration of having to have the the squiggles cause
01:14:16.494 --> 01:14:22.571 like especially in those like looking at any service thingy,
01:14:20.627 --> 01:14:24.177 The end last because we have that's literally everywhere.
01:14:22.571 --> 01:14:23.467 it would.
01:14:24.807 --> 01:14:25.817 Yeah, we'll just be like this.
01:14:24.967 --> 01:14:25.397 Yeah.
01:14:25.407 --> 01:14:28.721 So like those that would become a semicolon, but you have to
01:14:27.787 --> 01:14:28.187 Yeah.
01:14:28.237 --> 01:14:30.807 No, that's cool. Yeah.
01:14:28.721 --> 01:14:31.327 turn the in the newest language feature on and.
01:14:32.637 --> 01:14:36.540 So if you want to turn that on real quick with this copy of it,
01:14:36.540 --> 01:14:40.443 go to the data model dot props, not data model the the data dot
01:14:40.443 --> 01:14:40.747 prop.
01:14:40.757 --> 01:14:43.207 What does ******** called directory dot build dot props?
01:14:41.987 --> 01:14:43.537 Directory dot props.
01:14:43.217 --> 01:14:43.487 I'm sorry.
01:14:43.587 --> 01:14:44.247 Yeah, that's it.
01:14:44.287 --> 01:14:46.037 Yeah, directory dot buildup.
01:14:46.047 --> 01:14:48.047 Props, which is at the root of the solution.
01:14:50.307 --> 01:14:53.845 You should be able to see from the solution items as well and
01:14:53.845 --> 01:14:54.187 there.
01:14:56.577 --> 01:14:58.237 You're up build up props this one.
01:14:58.957 --> 01:14:59.657 Yeah.
01:14:59.937 --> 01:15:03.627 And then the language level, the language version.
01:15:03.777 --> 01:15:06.137 Right now it's got latest major on it like 32.
01:15:06.247 --> 01:15:10.577 If you change that to preview, it will then absolutely always
01:15:06.867 --> 01:15:07.077 Umm.
01:15:10.577 --> 01:15:14.837 use the the latest feature that Visual Studio has access to.
01:15:14.847 --> 01:15:17.773 So if you long as you got your Visual Studio kept up the date,
01:15:17.773 --> 01:15:20.373 you should be able to pick up all the latest C language
01:15:20.373 --> 01:15:22.834 features and then obviously sometimes those language
01:15:22.834 --> 01:15:25.712 features get firewalled behind like a newer version of Visual
01:15:25.712 --> 01:15:26.037 Studio.
01:15:26.307 --> 01:15:30.371 But there isn't one right now, so it's still in there and then
01:15:30.371 --> 01:15:34.306 it might need a moment to to pick up that stuff and as well,
01:15:31.567 --> 01:15:31.827 School.
01:15:34.306 --> 01:15:36.757 you might need to update your writer.
01:15:37.227 --> 01:15:38.757 Yeah, I was gonna say.
01:15:37.347 --> 01:15:41.770 And so latest version because the version I just updated
01:15:41.770 --> 01:15:45.727 Resharper yesterday, the version number is 2023.2.
01:15:46.747 --> 01:15:47.367 Umm.
01:15:48.347 --> 01:15:48.627 OK.
01:15:48.517 --> 01:15:48.847 Yeah.
01:15:48.857 --> 01:15:52.793 So there is a newer version of writer for you to download,
01:15:52.793 --> 01:15:55.327 although even that seems old because.
01:15:53.697 --> 01:15:54.047 But.
01:15:58.567 --> 01:15:59.067 Hmm.
01:15:59.237 --> 01:15:59.627 Author.
01:15:59.637 --> 01:16:00.467 Was an update.
01:16:00.227 --> 01:16:02.247 We're go to the go to the help menu.
01:16:00.657 --> 01:16:01.077 Me just.
01:16:05.407 --> 01:16:06.597 And then check for updates.
01:16:05.517 --> 01:16:06.877 I'm probably like a way out of date.
01:16:08.417 --> 01:16:08.867 Uh, sorry.
01:16:10.227 --> 01:16:11.777 So help and then check for updates.
01:16:11.787 --> 01:16:14.562 Sometimes it's in the about dialogue, so you would you
01:16:14.562 --> 01:16:17.488 weren't wrong for going to the about dialogue but and now
01:16:17.488 --> 01:16:18.597 you'll get the option.
01:16:18.137 --> 01:16:20.557 Yes, switch 3/3.
01:16:25.157 --> 01:16:25.897 Yeah, whatever.
01:16:25.607 --> 01:16:27.377 So go ahead and tell the update and restart.
01:16:28.707 --> 01:16:33.387 See if it works sales invoices restart.
01:16:36.027 --> 01:16:37.887 If it actually restarts itself, I don't know if it will.
01:16:39.227 --> 01:16:42.837 Ohh OK it's doing the thing.
01:16:47.267 --> 01:16:48.177 Yeah, I like writer.
01:16:48.187 --> 01:16:50.157 I just wish the filter buzz would pop up.
01:16:50.167 --> 01:16:55.464 That's like the only thing that and T4's don't always work as
01:16:55.464 --> 01:16:57.087 expected or at all.
01:17:00.507 --> 01:17:03.894 But other than that, it's kind of like Visual Studio with
01:17:00.607 --> 01:17:00.967 Well.
01:17:03.894 --> 01:17:06.637 Resharper, just not a painfully slow at times.
01:17:18.447 --> 01:17:19.587 Delegating installation.
01:17:23.897 --> 01:17:26.357 I'm sorry your whole cannot be completed as dialed.
01:17:24.187 --> 01:17:24.357 So.
01:17:26.487 --> 01:17:27.587 Please hang up and try again.
01:17:31.107 --> 01:17:33.597 Isn't saying Ben uninstall EXE what?
01:17:39.447 --> 01:17:40.267 Uh, OK.
01:17:40.667 --> 01:17:41.187 Proceed.
01:17:43.407 --> 01:17:44.047 EI don't care.
01:17:46.377 --> 01:17:46.877 Do it.
01:17:51.487 --> 01:17:51.657 But.
01:17:56.377 --> 01:17:57.047 See this one.
01:17:59.547 --> 01:18:00.887 To do.
01:18:12.787 --> 01:18:18.020 Still, I'm still in preview and then if I go back to is it this
01:18:18.020 --> 01:18:18.347 one?
01:18:19.477 --> 01:18:23.237 Ah, well, we tried.
01:18:22.537 --> 01:18:23.877 Massive was it saying?
01:18:25.077 --> 01:18:27.500 It's, uh, it's still doing something analyzer crap, so
01:18:27.500 --> 01:18:28.557 maybe it's not going to.
01:18:30.567 --> 01:18:31.337 Is it gonna?
01:18:31.347 --> 01:18:34.977 She's still processing, I guess keyboard.
01:18:39.177 --> 01:18:40.097 Today, junior.
01:18:43.797 --> 01:18:44.297 What do you know?
01:18:45.857 --> 01:18:46.967 Maybe it's not broken.
01:18:49.907 --> 01:18:51.927 It might have like cashed to that there was there there.
01:18:53.007 --> 01:18:56.670 So I guess we'll find out when it's done and we'll just pretend
01:18:56.670 --> 01:18:57.757 we didn't see that.
01:18:57.987 --> 01:18:58.937 It's all good.
01:18:58.947 --> 01:19:05.773 There's no vulnerabilities and then we packages alright that
01:19:05.773 --> 01:19:07.227 appear oh oh.
01:19:11.627 --> 01:19:13.887 OK, what does it think they issue is?
01:19:16.907 --> 01:19:17.117 OK.
01:19:19.867 --> 01:19:24.177 OK, it's still complaining, but yeah, whatever.
01:19:24.227 --> 01:19:24.437 Where?
01:19:24.387 --> 01:19:27.485 I don't know if I need to rebuild or anything, or yeah,
01:19:27.485 --> 01:19:29.587 it's I didn't change the build props.
01:19:27.837 --> 01:19:28.687 OK, whatever.
01:19:28.697 --> 01:19:29.397 Just put it back in.
01:19:29.407 --> 01:19:29.787 It's fine.
01:19:30.977 --> 01:19:32.407 Yeah, whatever I tried.
01:19:33.767 --> 01:19:34.217 Check and see.
01:19:34.227 --> 01:19:36.117 This is another update for writer.
01:19:34.747 --> 01:19:35.267 Who?
01:19:37.547 --> 01:19:37.977 Maybe.
01:19:38.027 --> 01:19:39.367 Maybe you stage the updates.
01:19:40.587 --> 01:19:41.107 Yeah, maybe.
01:19:41.117 --> 01:19:41.437 I don't know.
01:19:42.577 --> 01:19:42.877 Say what?
01:19:43.457 --> 01:19:45.497 Yeah, 2023.2 available now.
01:19:46.837 --> 01:19:48.157 It made you stage your update.
01:19:47.187 --> 01:19:47.507 Why?
01:19:49.627 --> 01:19:52.277 Why don't you just wait?
01:19:52.287 --> 01:19:54.107 What protocol buffers?
01:19:56.027 --> 01:19:57.397 I'll buffer your protocol.
01:19:57.827 --> 01:19:58.287 Hit update.
01:20:05.007 --> 01:20:05.657 Gotta do one.
01:20:05.667 --> 01:20:06.297 It's like a.
01:20:06.567 --> 01:20:09.868 It's like having a an old Mac back in the day or be like hit
01:20:09.868 --> 01:20:13.169 the update one thing at a time over and over again to go for
01:20:12.567 --> 01:20:16.561 Yeah, I had that problem a lot when I was working at Dell and
01:20:13.169 --> 01:20:14.197 version of version.
01:20:16.561 --> 01:20:20.747 we had printers that you had to stage updates because the if you
01:20:20.747 --> 01:20:24.998 went directly from firmware like 3 to 10, it would just, it would
01:20:24.998 --> 01:20:25.577 break it.
01:20:27.497 --> 01:20:31.569 But if you went from 3 to 5 to 8 to 10 then it was fine and I'm
01:20:31.569 --> 01:20:35.386 like, why can't you make the update or item potents so that
01:20:35.386 --> 01:20:39.457 no matter what other version it was on, it would just go to it.
01:20:43.937 --> 01:20:44.617 That would be too easy.
01:20:43.947 --> 01:20:45.607 Still, he manufacturers.
01:20:53.987 --> 01:20:59.497 Other green grass growing watching session as it validates
01:20:59.497 --> 01:21:00.617 and install.
01:21:00.627 --> 01:21:02.337 It's like validating a steam install.
01:21:03.007 --> 01:21:05.367 Well, if someone wants to pipe up with something else to say.
01:21:06.287 --> 01:21:07.917 Yeah, I mean, go go for it.
01:21:10.427 --> 01:21:14.096 But anyone else anything better to talk about than watch should
01:21:11.727 --> 01:21:12.847 You are doing fine.
01:21:13.687 --> 01:21:14.987 Silence is compliance.
01:21:14.096 --> 01:21:15.127 be updated writer.
01:21:17.337 --> 01:21:17.817 To.
01:21:17.957 --> 01:21:23.407 Uh, I'd say we go to go ahead and kill the recording.
01:21:24.497 --> 01:21:25.607 Yeah, yeah, probably.
01:21:25.747 --> 01:21:25.947 Yeah.
01:21:25.987 --> 01:21:26.307 Yeah.
01:21:28.327 --> 01:21:31.311 Unless, unless the suspense is killing whoever might be
01:21:31.311 --> 01:21:32.057 watching this.
01:21:32.117 --> 01:21:35.557 However, locked down to see how by Optic has.
01:21:34.007 --> 01:21:34.627 It's killing me.
01:21:34.017 --> 01:21:36.107 They must know if you made it.