A critical look at Marvel vs. Capcom....

[boomzilla]

@izzion said in A critical look at Marvel vs. Capcom....:

In light of all of the above, the most common use case in the wild for linked servers is that Server A is making the connection to Server B as the SQL-integrated, default sa account... which is a security nightmare for all of the usual reasons.

Ah, thanks, that starts to explain the "hardcode sa" thing, maybe. Yeah, I have no idea how it's set up at the DB level. I'm not a DBA. I have to assume they've done their job on that. Either way...they're both our DBs, so meh.

[izzion]

@boomzilla said in A critical look at Marvel vs. Capcom....:

@izzion said in A critical look at Marvel vs. Capcom....:

In light of all of the above, the most common use case in the wild for linked servers is that Server A is making the connection to Server B as the SQL-integrated, default sa account... which is a security nightmare for all of the usual reasons.

Ah, thanks, that starts to explain the "hardcode sa" thing, maybe. Yeah, I have no idea how it's set up at the DB level. I'm not a DBA. I have to assume they've done their job on that. Either way...they're both our DBs, so meh.

The basic security hazard from linked servers as sa is that it basically gives anyone with permission to modify sprocs / run arbitrary queries on Server A sa permissions on Server B, if they have read access to the linked server. Or anyone with master db access on Server A now has the sa password to Server B, which most security guys would freak out more over (assuming there was any room left in their pants after they found out the sa account was even enabled), but in my experience, the hidden permissions elevation is a much broader problem, since there's likely to be an order of magnitude more people that have permissions to run queries on Server A, and a bunch of them are going to be developers, so they're more likely to do something dumb, even if only by accident.

[boomzilla]

@izzion said in A critical look at Marvel vs. Capcom....:

@boomzilla said in A critical look at Marvel vs. Capcom....:

@izzion said in A critical look at Marvel vs. Capcom....:

In light of all of the above, the most common use case in the wild for linked servers is that Server A is making the connection to Server B as the SQL-integrated, default sa account... which is a security nightmare for all of the usual reasons.

Ah, thanks, that starts to explain the "hardcode sa" thing, maybe. Yeah, I have no idea how it's set up at the DB level. I'm not a DBA. I have to assume they've done their job on that. Either way...they're both our DBs, so meh.

The basic security hazard from linked servers as sa is that it basically gives anyone with permission to modify sprocs / run arbitrary queries on Server A sa permissions on Server B, if they have read access to the linked server. Or anyone with master db access on Server A now has the sa password to Server B, which most security guys would freak out more over (assuming there was any room left in their pants after they found out the sa account was even enabled), but in my experience, the hidden permissions elevation is a much broader problem, since there's likely to be an order of magnitude more people that have permissions to run queries on Server A, and a bunch of them are going to be developers, so they're more likely to do something dumb, even if only by accident.

I mean...our app, the COTS app and our (Oracle) DB are the only things that can connect to it (in PROD...in our development and test environments we can talk to it with normal developer tools and stuff, of course). Our systems get the bejeezus audited out them (including the aforementioned STIG compliance, but more than that even, for ) so as a developer I have to assume they pass that particular smell test.

[Jaime]

@izzion said in A critical look at Marvel vs. Capcom....:

At this point in MS SQL land, there's an almost blanket recommendation of "Friends Don't Let Friends Use Linked Servers" due to some limitations in how Microsoft has implemented them, and the resulting problems those limitations cause:

Thank you.

Also, this really isn't a problem with Microsoft's implementation, it's an underlying condition that is pretty much unsolvable, so it should apply to any data source that allows pass-through access to another data source.

The authentication problem comes from the fact that better authentication protocols require that the client prove that it holds the password, but without allowing that proof to be simply copied and re-used. That means that passing the current identity to the downstream server requires things like Kerberos delegation, which reduce security by their very nature, when it even manages to work properly.

Manually managing mappings to downstream server accounts is too cumbersome to be a real solution. Always using the same identity downstream pretty much throws authentication in the trash. So, we end up in the position of saying "just don't do it".

@boomzilla ... the security industry has settled on giving people checklists of dos and don'ts because it's too hard to explain everything to everyone and security is too important to put off until it's understood better by the general public. Inside the industry, we tend to find sources that we trust and take a position of using their guidance until we understand the problem well enough to decide if the rules should be modified for our situation. We expect blind compliance from everyone that can't convince us that their plan B has merit... we don't accept people violating the rules until they "get it". That's just the behavioral pattern that's required to survive in the current hostile environment. If you see it as some expert that's trying to tell you what to do, and you're not going to do it; expect it to end badly.

[boomzilla]

@Jaime said in A critical look at Marvel vs. Capcom....:

@boomzilla ... the security industry has settled on giving people checklists of dos and don'ts because it's too hard to explain everything to everyone and security is too important to put off until it's understood better by the general public. Inside the industry, we tend to find sources that we trust and take a position of using their guidance until we understand the problem well enough to decide if the rules should be modified for our situation. We expect blind compliance from everyone that can't convince us that their plan B has merit... we don't accept people violating the rules until they "get it". That's just the behavioral pattern that's required to survive in the current hostile environment. If you see it as some expert that's trying to tell you what to do, and you're not going to do it; expect it to end badly.

You're the one who brought it up. Also, AFAIK, you're an internet rando not a security expert so don't be surprised if people don't take you seriously when you deflect instead of answering a question directly.

[boomzilla]

@Jaime said in A critical look at Marvel vs. Capcom....:

Manually managing mappings to downstream server accounts is too cumbersome to be a real solution.

If you're dealing with a bunch, then sure. If there's literally only a single downstream server then why not? I mean...what are we paying these DBAs and Sysadmins if not to deal with stuff like that?

[Jaime]

@boomzilla said in A critical look at Marvel vs. Capcom....:

@Jaime said in A critical look at Marvel vs. Capcom....:

Manually managing mappings to downstream server accounts is too cumbersome to be a real solution.

If you're dealing with a bunch, then sure. If there's literally only a single downstream server then why not? I mean...what are we paying these DBAs and Sysadmins if not to deal with stuff like that?

I'm referring to mappings between local accounts and the corresponding account on the downstream server. It's actually pretty hard to manage even a small list given the number of hires, terminations, and role changes that happen in any company.

[boomzilla]

@Jaime said in A critical look at Marvel vs. Capcom....:

@boomzilla said in A critical look at Marvel vs. Capcom....:

@Jaime said in A critical look at Marvel vs. Capcom....:

Manually managing mappings to downstream server accounts is too cumbersome to be a real solution.

If you're dealing with a bunch, then sure. If there's literally only a single downstream server then why not? I mean...what are we paying these DBAs and Sysadmins if not to deal with stuff like that?

I'm referring to mappings between local accounts and the corresponding account on the downstream server.

I'll take your word for it because this doesn't even make any sense to me.

[Jaime]

@boomzilla

The top list is a list of mappings. These local users will be connected with the given credentials. This is the list that can't be reasonably managed.

The bottom section is what to do for users not listed.

• "Be made without a security context" only works if the downstream sever doesn't have any security and you don't care to impose any
• "Be made using the login's current security context" is the one mentioned above that sounds promising but isn't.
• "Be made using this security context" is where you put catch-all credentials that pretty much throw security under the bus in the hopes that no notices the hole you just cut in the wall here.

[boomzilla]

@Jaime OK. But like I said, I have no idea what local users (I'm assuming so they can login to the server?) have to do with connecting to a DB. The rest of it is cricket to me, as well, not being a Windows guy, let alone a Windows administrator.

[izzion]

@boomzilla said in A critical look at Marvel vs. Capcom....:

@Jaime OK. But like I said, I have no idea what local users (I'm assuming so they can login to the server?) have to do with connecting to a DB. The rest of it is cricket to me, as well, not being a Windows guy, let alone a Windows administrator.

"Local" in this context is the user within SQL. So when you connect to server A as DOMAIN\boomzilla, and then you need to run a query on server A that connects to server B, the mapping defines what credentials are used for the connection on server B.

(Or, to get into the s that the security guys see more often, there's a SQL login boomzilla that you're using to connect to server A, and then that maps to some other SQL login on server B, and when server C gets installed later it becomes a completely separate mapping because the SQL guys don't have any system for keeping login identities synchronized between servers and aren't just using domain logons).

Though definitely is security guys thinking they're immune to having to justify their recommendations and just relying on "because we said so, that's why." Communicating with business people in plain English (well, OK, business-speak isn't teeeeechnically plain English, but it's closer than IT nerdspeak) isn't just the domain of software BAs... developers, SAs, and security guys need to be doing it too.

[error]

@boomzilla said in A critical look at Marvel vs. Capcom....:

@MrL said in A critical look at Marvel vs. Capcom....:

@Bulb said in A critical look at Marvel vs. Capcom....:

You can use Java in stored procedures in Oracle. I didn't check, but I believe you can use .NET in stored procedures in SQLServer. And you can use Tcl, Perl, Python, Java, Lua, R, shell, and JavaScript (and probably some more) in PostgreSQL.

OMG what a terrible idea. Making BL in DB even worse. Just wow.

It's good for stuff like reports or overnight jobs that need to do some complex calculations. Basically, same reason you'd need a stored function, but in a nicer language. Also, you can have the same code in your application and your DB, available to be called in either place as required.

I might be but I used this to expose some crypto APIs to the server so I could store stronger password hashes, and check them without showing them to the application server.

[boomzilla]

@izzion said in A critical look at Marvel vs. Capcom....:

"Local" in this context is the user within SQL. So when you connect to server A as DOMAIN\boomzilla, and then you need to run a query on server A that connects to server B, the mapping defines what credentials are used for the connection on server B.

I guess I don't understand why I'd be connecting to the server qua server at all instead of just talking to the DB.

[error]

@boomzilla said in A critical look at Marvel vs. Capcom....:

I guess I don't understand why I'd be connecting to the server qua server at all instead of just talking to the DB.

It's really but I worked a project where I had to connect to Oracle via linked server on MS SQL Server because - for some reason I can't fathom - they didn't trust our ASP.NET application with a direct Oracle connection (but tunneling through SQL Server made everything OK?)

I think it was more: they trusted a fellow DBA with access but not a lowly developer, and that DBA was too to provide a proper DAL or API, so they just linked the server to the one we already had access to...

[boomzilla]

@error said in A critical look at Marvel vs. Capcom....:

@boomzilla said in A critical look at Marvel vs. Capcom....:

I guess I don't understand why I'd be connecting to the server qua server at all instead of just talking to the DB.

It's really but I worked a project where I had to connect to Oracle via linked server on MS SQL Server because - for some reason I can't fathom - they didn't trust our ASP.NET application with a direct Oracle connection (but tunneling through SQL Server made everything OK?)

We can and do also connect directly but especially for reporting it makes life so much easier to have that connection to combine our app's data with the 3rd party stuff that we have to use.

[Groaner]

@Unperverted-Vixen said in A critical look at Marvel vs. Capcom....:

@Groaner said in A critical look at Marvel vs. Capcom....:

What's a good name, then, for a design where you not only have models, views, and controllers, but viewmodels and mappers and services and repositories, not just on the backend, but the frontend as well?

if by "frontend" you mean "ASP.NET MVC or ASP.NET Core code"?

By "frontend" I mean "any code that directly handles user input, comprised of HTML and Javascript or things that compile to Javascript, and ends just before a MVC Controller method (which, from there on out, is where the 'backend' lives)."

And yes, as it happens, there are Angular controllers, repositories, services, views, in addition to the controllers, repositories, services, etc. on the ASP.NET MVC side. Having fun yet?

Whatever happened to YAGNI?

We do need it, although we may be an odd case.

• We use the same ASP.NET MVC front-end code with multiple versions of our software. Repositories let us have repository implementations for each possible schema, wiring up the correct one at runtime without the front-end code needing to know any of the particulars.

• We use services as our main extensibility point. Client A needs non-standard logic for something (say, changing the sort order on a page), so they'll override the service to customize the behavior for populating the view model (in this example, they can just call base and then tweak the results).

  If we left that logic in the controller, the only way to customize it would be to copy/paste the whole thing into the client-specific implementation. That provides a lot of space for the dev to screw up, and would also mean that changes from future releases would never make their way to the client.

I'm fine with exceptions to YAGNI if it's truly the case that YAGNI. In that case, a service pattern is justified. Creating a service (and every time I hear the word "service" used in a context that doesn't relate to an application that runs as a background process, it sounds of nails on chalkboard) just for the sake of it that does nothing but act as a shell on top of a repository or whatnot, is premature.

[Groaner]

@Kamil-Podlesak said in A critical look at Marvel vs. Capcom....:

@Groaner said in A critical look at Marvel vs. Capcom....:

What's a good name, then, for a design where you not only have models, views, and controllers, but viewmodels and mappers and services and repositories, not just on the backend, but the frontend as well?

Generally accepted term is overengineering.

I like it. Push to production.

[Groaner]

@error said in A critical look at Marvel vs. Capcom....:

@boomzilla said in A critical look at Marvel vs. Capcom....:

@MrL said in A critical look at Marvel vs. Capcom....:

@Bulb said in A critical look at Marvel vs. Capcom....:

You can use Java in stored procedures in Oracle. I didn't check, but I believe you can use .NET in stored procedures in SQLServer. And you can use Tcl, Perl, Python, Java, Lua, R, shell, and JavaScript (and probably some more) in PostgreSQL.

OMG what a terrible idea. Making BL in DB even worse. Just wow.

It's good for stuff like reports or overnight jobs that need to do some complex calculations. Basically, same reason you'd need a stored function, but in a nicer language. Also, you can have the same code in your application and your DB, available to be called in either place as required.

I might be but I used this to expose some crypto APIs to the server so I could store stronger password hashes, and check them without showing them to the application server.

You mean you don't like being restricted to SHA256/512 in 2021?

[Bulb]

@Jaime said in A critical look at Marvel vs. Capcom....:

The truth is... it's simply not worth it. Just put your damn code in the application where it belongs and make your security posture much stronger and much easier to confirm.

No, it won't help security a iota. At most it will placate an auditor too lazy to do actual threat analysis.

See, if you chase all logic out of the database and into the application, the application still has to be allowed to query all the data and modify most of them. So it can siphon the data to a chinese sftp … more easily, because the database server is behind an extra layer of firewall.

… you probably don't want to allow CLR into a database server shared by multiple unrelated applications though, so it depends on your setup. Policy rules don't solve security. You always have to do a risk analysis, and it will come out differently for different projects.

[Groaner]

@Bulb said in A critical look at Marvel vs. Capcom....:

See, if you chase all logic out of the database and into the application, the application still has to be allowed to query all the data and modify most of them. So it can siphon the data to a chinese sftp … more easily, because the database server is behind an extra layer of firewall.

I should also recommend the security measures of 1) not hiring developers who have reason to siphon data to Chinese SFTP, or 2) abusing developers enough such that they have reason to siphon data to Chinese SFTPs.

If those are too much to ask, you can always embed key phrases in the source code like "Xitler Looks Like Winnie the Pooh", "Great Leap Forward", "Let a thousand flowers out themselves and submit for reeducationbloom", "Tiananmen Square", "Autonomous Region of Xinjiang" and so forth, and it won't make it past the Great Firewall.

[Kamil Podlesak]

@Groaner said in A critical look at Marvel vs. Capcom....:

@Unperverted-Vixen said in A critical look at Marvel vs. Capcom....:

@Groaner said in A critical look at Marvel vs. Capcom....:

What's a good name, then, for a design where you not only have models, views, and controllers, but viewmodels and mappers and services and repositories, not just on the backend, but the frontend as well?

if by "frontend" you mean "ASP.NET MVC or ASP.NET Core code"?

By "frontend" I mean "any code that directly handles user input, comprised of HTML and Javascript or things that compile to Javascript, and ends just before a MVC Controller method (which, from there on out, is where the 'backend' lives)."

And yes, as it happens, there are Angular controllers, repositories, services, views, in addition to the controllers, repositories, services, etc. on the ASP.NET MVC side. Having fun yet?

You should have started with this, because this is definitely
Actually, having two frontends on top of each other is a front-page material.

[MrL]

@Kamil-Podlesak said in A critical look at Marvel vs. Capcom....:

@Groaner said in A critical look at Marvel vs. Capcom....:

@Unperverted-Vixen said in A critical look at Marvel vs. Capcom....:

@Groaner said in A critical look at Marvel vs. Capcom....:

What's a good name, then, for a design where you not only have models, views, and controllers, but viewmodels and mappers and services and repositories, not just on the backend, but the frontend as well?

if by "frontend" you mean "ASP.NET MVC or ASP.NET Core code"?

By "frontend" I mean "any code that directly handles user input, comprised of HTML and Javascript or things that compile to Javascript, and ends just before a MVC Controller method (which, from there on out, is where the 'backend' lives)."

And yes, as it happens, there are Angular controllers, repositories, services, views, in addition to the controllers, repositories, services, etc. on the ASP.NET MVC side. Having fun yet?

You should have started with this, because this is definitely
Actually, having two frontends on top of each other is a front-page material.

Js framework on top of C# MVC? That's pretty normal.

[Kamil Podlesak]

@MrL said in A critical look at Marvel vs. Capcom....:

@Kamil-Podlesak said in A critical look at Marvel vs. Capcom....:

@Groaner said in A critical look at Marvel vs. Capcom....:

@Unperverted-Vixen said in A critical look at Marvel vs. Capcom....:

@Groaner said in A critical look at Marvel vs. Capcom....:

What's a good name, then, for a design where you not only have models, views, and controllers, but viewmodels and mappers and services and repositories, not just on the backend, but the frontend as well?

if by "frontend" you mean "ASP.NET MVC or ASP.NET Core code"?

By "frontend" I mean "any code that directly handles user input, comprised of HTML and Javascript or things that compile to Javascript, and ends just before a MVC Controller method (which, from there on out, is where the 'backend' lives)."

And yes, as it happens, there are Angular controllers, repositories, services, views, in addition to the controllers, repositories, services, etc. on the ASP.NET MVC side. Having fun yet?

You should have started with this, because this is definitely
Actually, having two frontends on top of each other is a front-page material.

Js framework on top of C# MVC? That's pretty normal.

Surely you mean common. I don't want to live in a world where this is normal.

[MrL]

@Kamil-Podlesak said in A critical look at Marvel vs. Capcom....:

@MrL said in A critical look at Marvel vs. Capcom....:

@Kamil-Podlesak said in A critical look at Marvel vs. Capcom....:

@Groaner said in A critical look at Marvel vs. Capcom....:

@Unperverted-Vixen said in A critical look at Marvel vs. Capcom....:

@Groaner said in A critical look at Marvel vs. Capcom....:

What's a good name, then, for a design where you not only have models, views, and controllers, but viewmodels and mappers and services and repositories, not just on the backend, but the frontend as well?

if by "frontend" you mean "ASP.NET MVC or ASP.NET Core code"?

By "frontend" I mean "any code that directly handles user input, comprised of HTML and Javascript or things that compile to Javascript, and ends just before a MVC Controller method (which, from there on out, is where the 'backend' lives)."

And yes, as it happens, there are Angular controllers, repositories, services, views, in addition to the controllers, repositories, services, etc. on the ASP.NET MVC side. Having fun yet?

You should have started with this, because this is definitely
Actually, having two frontends on top of each other is a front-page material.

Js framework on top of C# MVC? That's pretty normal.

Surely you mean common. I don't want to live in a world where this is normal.

The world of pure html pages is gone. If the frontend must use js, I prefer to leave it up to js guys with their frameworks, rather than wrestle with it myself.

[Zenith]

@boomzilla said in A critical look at Marvel vs. Capcom....:

Well, we have things to prevent that, like code reviews and deployment history / audits and firewalls and other network monitoring.

Some places review the code for what it does, some places review the code for how it looks. So far, the odds are not in favor of the correct approach.

[Jaime]

@izzion said in A critical look at Marvel vs. Capcom....:

Though definitely is security guys thinking they're immune to having to justify their recommendations and just relying on "because we said so, that's why."

After the industry spent twenty years trying to teach people why, for example, SQL Injection happens and how to prevent it, we realized that more people were entering the industry than we were able to reach. These problems cannot be solved by explaining and training alone.

In this day and age we reduce this one particular issue down to: Use a well-established library to manage query parameters, or have a security expert approve your alternative. You don't get to say "I'm doing it my way until you convince me otherwise."

We're not immune to having to justify our recommendations. We use well vetted frameworks and ruleset as our starting point. What's ridiculous is that under every rock is another ignorant developer that thinks the rules are stupid, the security guys are arrogant, and everyone is preventing them from getting real work done.

[boomzilla]

@Jaime said in A critical look at Marvel vs. Capcom....:

We're not immune to having to justify our recommendations. We use well vetted frameworks and ruleset as our starting point. What's ridiculous is that under every rock is another ignorant developer that thinks the rules are stupid, the security guys are arrogant, and everyone is preventing them from getting real work done

Maybe you didn't notice this wasn't work and people were asking questions because they were interested in finding out the answers.

[Bulb]

@MrL said in A critical look at Marvel vs. Capcom....:

@Kamil-Podlesak said in A critical look at Marvel vs. Capcom....:

@Groaner said in A critical look at Marvel vs. Capcom....:

@Unperverted-Vixen said in A critical look at Marvel vs. Capcom....:

@Groaner said in A critical look at Marvel vs. Capcom....:

What's a good name, then, for a design where you not only have models, views, and controllers, but viewmodels and mappers and services and repositories, not just on the backend, but the frontend as well?

if by "frontend" you mean "ASP.NET MVC or ASP.NET Core code"?

By "frontend" I mean "any code that directly handles user input, comprised of HTML and Javascript or things that compile to Javascript, and ends just before a MVC Controller method (which, from there on out, is where the 'backend' lives)."

And yes, as it happens, there are Angular controllers, repositories, services, views, in addition to the controllers, repositories, services, etc. on the ASP.NET MVC side. Having fun yet?

You should have started with this, because this is definitely
Actually, having two frontends on top of each other is a front-page material.

Js framework on top of C# MVC? That's pretty normal.

You have a JS front-end on top of a C# back-end, but then you shouldn't have all those layers in both of them.

[MrL]

@Bulb said in A critical look at Marvel vs. Capcom....:

@MrL said in A critical look at Marvel vs. Capcom....:

@Kamil-Podlesak said in A critical look at Marvel vs. Capcom....:

@Groaner said in A critical look at Marvel vs. Capcom....:

@Unperverted-Vixen said in A critical look at Marvel vs. Capcom....:

@Groaner said in A critical look at Marvel vs. Capcom....:

What's a good name, then, for a design where you not only have models, views, and controllers, but viewmodels and mappers and services and repositories, not just on the backend, but the frontend as well?

if by "frontend" you mean "ASP.NET MVC or ASP.NET Core code"?

By "frontend" I mean "any code that directly handles user input, comprised of HTML and Javascript or things that compile to Javascript, and ends just before a MVC Controller method (which, from there on out, is where the 'backend' lives)."

And yes, as it happens, there are Angular controllers, repositories, services, views, in addition to the controllers, repositories, services, etc. on the ASP.NET MVC side. Having fun yet?

You should have started with this, because this is definitely
Actually, having two frontends on top of each other is a front-page material.

Js framework on top of C# MVC? That's pretty normal.

You have a JS front-end on top of a C# back-end, but then you shouldn't have all those layers in both of them.

Which ones?

[Bulb]

@Jaime said in A critical look at Marvel vs. Capcom....:

You don't get to say "I'm doing it my way until you convince me otherwise."

Except many, many developers out there just say that anyway.

@Jaime said in A critical look at Marvel vs. Capcom....:

We're not immune to having to justify our recommendations. We use well vetted frameworks and ruleset as our starting point. What's ridiculous is that under every rock is another ignorant developer that thinks the rules are stupid, the security guys are arrogant, and everyone is preventing them from getting real work done.

The big risk is that the developers will get the work done, avoid overstepping the rules, but create even more serious security issues in the process. It will most likely be application-specific, but a risk that is well understood is still easier to mitigate.

There are things where saying to just not do this is perfectly fine, because they don't really bring any advantage. For example building queries from strings. Because the recommended solution is safer all around and does not really have any disadvantages except that you have to know about it.

But when the alternative also has security implications, like various alternatives of where to put logic, then just saying always do it this way does not work well. Because there are cases where the other option is actually better, and you have to look at the specific application design to be able to decide. And sometimes the decision is really tricky, because estimating how difficult a breach through specific attack surface is is.

[Unperverted Vixen]

@Bulb said in A critical look at Marvel vs. Capcom....:

For example building queries from strings. Because the recommended solution is safer all around and does not really have any disadvantages except that you have to know about it.

And that you’re limited to however many parameters the SQL server supports. I think for Microsoft the limit is 3000?

(Which, yes, for one row at a time is not a problem. I’ve hit that limit doing large batch saves and had to reduce my batch size. I don’t really think that’s a reason to not use parameterized queries. )

[Bulb]

@Unperverted-Vixen With parameters the insert statement itself is cached, so it's probably more efficient even with smaller batches because you save on the parsing and a bit on the transfer. You should still keep it in one transaction, but that shouldn't be a problem.

[Zenith]

@Bulb said in A critical look at Marvel vs. Capcom....:

@Jaime said in A critical look at Marvel vs. Capcom....:

You don't get to say "I'm doing it my way until you convince me otherwise."

Except many, many developers out there just say that anyway.

So somebody else decides you'll do it their way until they're convinced otherwise. Seems like authority is often at odds with burden of proof. In other words, those that have authority don't have to answer/explain/prove anything.

Edit: My work environment leaks into every post, doesn't it? So tired of being punished for doing stuff wrong like I was told even though I knew better...

[boomzilla]

@Zenith said in A critical look at Marvel vs. Capcom....:

@Bulb said in A critical look at Marvel vs. Capcom....:

@Jaime said in A critical look at Marvel vs. Capcom....:

You don't get to say "I'm doing it my way until you convince me otherwise."

Except many, many developers out there just say that anyway.

So somebody else decides you'll do it their way until they're convinced otherwise. Seems like authority is often at odds with burden of proof. In other words, those that have authority don't have to answer/explain/prove anything.

Edit: My work environment leaks into every post, doesn't it? So tired of being punished for doing stuff wrong like I was told even though I knew better...

Having actual security constraints is a legitimate reason not to do something (even if the underlying reasons are nonsense, like with expiring passwords). It's out of your control. Still, it's good for the developers to understand the reasons behind the constraint so that they don't reimplement the same vulnerability in another way that the security guideline didn't think about.

Stuff like, "Don't sftp to China" is a real concern, but you're not really preventing that in a meaningful way by not allowing some particular kind of code to be deployed. That's just security theater. Better to have defined network connections / firewalls and monitored ways to pierce through them (e.g., only the ports that talk to the DB, web server is the only thing that can talk to the outside world, etc). Because I have a bunch of other places to hide nefarious code than inside the DB (which as already mentioned is already behind several firewalls so trying to exfiltrate data from there is a non-starter).

[error]

@Unperverted-Vixen said in A critical look at Marvel vs. Capcom....:

And that you’re limited to however many parameters the SQL server supports. I think for Microsoft the limit is 3000?

Wha...? I've never gone past 8.

Raymond Chen  /  Mar 1, 2007

If you have to ask, you're probably doing something wrong - The Old New Thing

If you have to ask about various operating system limits, you’re probably doing something wrong. If you’re nesting windows more than 50 levels deep or nesting menus more than 25 levels deep or creating a dialog box with more than 65535 controls,

---

Filed under:

[error]

@boomzilla said in A critical look at Marvel vs. Capcom....:

Stuff like, "Don't sftp to China" is a real concern

Psh, like China would allow an encrypted data connection they can't monitor.

[dkf]

@boomzilla said in A critical look at Marvel vs. Capcom....:

Stuff like, "Don't sftp to China" is a real concern

Yeah, make sure they've paid for access first.

[Jaime]

@Unperverted-Vixen said in A critical look at Marvel vs. Capcom....:

And that you’re limited to however many parameters the SQL server supports. I think for Microsoft the limit is 3000?

(Which, yes, for one row at a time is not a problem. I’ve hit that limit doing large batch saves and had to reduce my batch size. I don’t really think that’s a reason to not use parameterized queries. )

Use an xml parameter. I've done ten thousand row upserts in a single call. You also get amazing performance by joining the existing rows to the xml data blob.

One of the key features of my data layer is that I can do this:

public List<Person>(IEnumerable<int> personIDs)
{
    return DB.Fetch<Person>("PersonID IN (@ids)", personIDs);
}

The Fetch method converts the IEnumerable to an xml parameter and rewrites the query to something like:

SELECT column1, column2 FROM People WHERE PersonID IN (SELECT l.i.value('@val', 'int') FROM @ids.nodes('l/i') AS l(i))

It converts the enumerable to xml data that looks like this:

<l>
   <i val="22" />
   <i val="33" />
   <i val="44" />
</l>

[error]

@Jaime said in A critical look at Marvel vs. Capcom....:

Use an xml parameter. I've done ten thousand row upserts in a single call.

I've done the same with table-valued parameters.

[Jaime]

@error said in A critical look at Marvel vs. Capcom....:

@Jaime said in A critical look at Marvel vs. Capcom....:

Use an xml parameter. I've done ten thousand row upserts in a single call.

I've done the same with table-valued parameters.

TVPs are schema-bound, making them more finicky to use and leaving crap all over the schema. XML parameters usually perform better and can be used against a database that you don't own.

[error]

@Jaime said in A critical look at Marvel vs. Capcom....:

public List<Person>(IEnumerable<int> personIDs)
{
    return DB.Fetch<Person>("PersonID IN (@ids)", personIDs);
}

I miss writing code that was this clean and concise. I'm in a Java hell where even the queries themselves are built from XML.

[boomzilla]

@error said in A critical look at Marvel vs. Capcom....:

@Jaime said in A critical look at Marvel vs. Capcom....:

public List<Person>(IEnumerable<int> personIDs)
{
    return DB.Fetch<Person>("PersonID IN (@ids)", personIDs);
}

I miss writing code that was this clean and concise. I'm in a Java hell where even the queries themselves are built from XML.

Huh. I use Java and can do the equivalent of that code (using Hibernate).

public List<Person>(List<String> personIDs){
    return getEm().createQuery("from Person where id in :ids")
        .setParameter("ids", personIDs)
        .getResultList();
}

[error]

@boomzilla I guess it's not the language's fault (though I really hate Java) that I'm stuck with

mybatis – MyBatis 3 | Mapper XML Files

[boomzilla]

@error

[Jaime]

@boomzilla said in A critical look at Marvel vs. Capcom....:

Huh. I use Java and can do the equivalent of that code (using Hibernate).

public List<Person>(List<String> personIDs){
    return getEm().createQuery("from Person where id in :ids")
        .setParameter("ids", personIDs)
        .getResultList();
}

Interestingly, you seem to have the same limitation as @Unperverted-Vixen mentioned above. See https://stackoverflow.com/questions/7758198/hibernate-oracle-in-clause-limitation-how-to-solve-it

If I'm reading the StackOverflow thread correctly, Hibernate seems to be simply replacing the parameter with a comma delimited literal list.

[Bulb]

@Zenith said in A critical look at Marvel vs. Capcom....:

@Bulb said in A critical look at Marvel vs. Capcom....:

@Jaime said in A critical look at Marvel vs. Capcom....:

You don't get to say "I'm doing it my way until you convince me otherwise."

Except many, many developers out there just say that anyway.

So somebody else decides you'll do it their way until they're convinced otherwise. Seems like authority is often at odds with burden of proof. In other words, those that have authority don't have to answer/explain/prove anything.

… and the people who would be able to understand good reason just call it quits if they think no such reasons exist and the poorly trained monkeys left do it their way, but still worse than the original. Authority often ends up getting what it asked for, not what it wanted.

[boomzilla]

@Jaime said in A critical look at Marvel vs. Capcom....:

@boomzilla said in A critical look at Marvel vs. Capcom....:

Huh. I use Java and can do the equivalent of that code (using Hibernate).

public List<Person>(List<String> personIDs){
    return getEm().createQuery("from Person where id in :ids")
        .setParameter("ids", personIDs)
        .getResultList();
}

Interestingly, you seem to have the same limitation as @Unperverted-Vixen mentioned above. See https://stackoverflow.com/questions/7758198/hibernate-oracle-in-clause-limitation-how-to-solve-it

If I'm reading the StackOverflow thread correctly, Hibernate seems to be simply replacing the parameter with a comma delimited literal list.

More or less. The IN clause is the real limiting factor there because it can't take more than 1,000 elements, whether hard coded or as parameters, which for the places I've done that isn't a problem in practice.

[HardwareGeek]

@Bulb said in A critical look at Marvel vs. Capcom....:

Authority often ends up getting what it asked for, not what it wanted.

Malicious compliance

[Kamil Podlesak]

@MrL said in A critical look at Marvel vs. Capcom....:

@Bulb said in A critical look at Marvel vs. Capcom....:

@MrL said in A critical look at Marvel vs. Capcom....:

@Kamil-Podlesak said in A critical look at Marvel vs. Capcom....:

@Groaner said in A critical look at Marvel vs. Capcom....:

@Unperverted-Vixen said in A critical look at Marvel vs. Capcom....:

@Groaner said in A critical look at Marvel vs. Capcom....:

What's a good name, then, for a design where you not only have models, views, and controllers, but viewmodels and mappers and services and repositories, not just on the backend, but the frontend as well?

if by "frontend" you mean "ASP.NET MVC or ASP.NET Core code"?

By "frontend" I mean "any code that directly handles user input, comprised of HTML and Javascript or things that compile to Javascript, and ends just before a MVC Controller method (which, from there on out, is where the 'backend' lives)."

And yes, as it happens, there are Angular controllers, repositories, services, views, in addition to the controllers, repositories, services, etc. on the ASP.NET MVC side. Having fun yet?

You should have started with this, because this is definitely
Actually, having two frontends on top of each other is a front-page material.

Js framework on top of C# MVC? That's pretty normal.

You have a JS front-end on top of a C# back-end, but then you shouldn't have all those layers in both of them.

Which ones?

The frontend ones. MVC is a frontend architecture.

It's perfectly fine to have full-blown Javascript framework with fancy MVN, connected to C# (Java, python, PHP) server which serves data and implements the business logic layer via some kind of RPC-over-HTTP (usually called "REST" today, "REST-like" by those less pretentious).

It's also perfectly fine (but unfashionable) to have C# (Java, python, PHP) MVC framework with some light Javascript (plain, maybe JQuery or something similar).

But MVC on top of MVC does not make any sense.

[HardwareGeek]

@Kamil-Podlesak said in A critical look at Marvel vs. Capcom....:

But MVC on top of MVC does not make any sense.

Obligatory "Yo dawg" joke.