I have a lot of resistance about using LLBLGen pro at my work by some DBa’s.

The latest resistance is dealing with security. (the first argument is that stored procedures are the way to go)

LLBLGen pro is a layer on top of ADO.Net and since it generates more code it violates the “less is more” philosophy. They would rather write custom code. Then someone cannot learn the “patterns’ that the code uses to hack the code.

They want the customer to sign off that they are not “at fault” if they get hacked because we used LLBLGen pro. Of course the customer is not going to say okay to that and this will force us not to use LLBLGen for any future projects.

I love LLBLGen and want to continue using it.

I would really appreciate any arguments about how LLBLGen is secure and how to over come their arguments?

Rich

richardcherry wrote:

I have a lot of resistance about using LLBLGen pro at my work by some DBa’s.

The latest resistance is dealing with security. (the first argument is that stored procedures are the way to go)

The only way in which stored procedures are more secure is when you supply a unique secret key with every call which is checked internally in the proc.

Otherwise anyone with access to the procs can actually harm your data (like calling pr_DeleteCustomer with some random ID).

LLBLGen pro is a layer on top of ADO.Net and since it generates more code it violates the “less is more” philosophy. They would rather write custom code. Then someone cannot learn the “patterns’ that the code uses to hack the code.

Convenience in usage requires some code, yes, though the DBA's don't write your .NET code, I think. So they might say "Hey, I don't like your way of connecting to the DB", though they should work WITH you, not AGAINST you. YOU want convenience to work with the data, to get more done in less time. So what YOU need is also important, perhaps more important than what a DBA has to say, as they're not in charge of your project.

Though it's mainly politics. Giving away the right to write SQL to the developers is degrading the importance of a DBA in the organization. Unless you can overturn these politics, it's a lost battle. We've seen this before with the sysadmin's a couple of years ago: a 3rd party develops a database driven website and requires a webserver and a database system. The Sysadmin then said: "no way that database will be directly accessable from the webserver", so he adds a firewall, limiting performance and distributed transaction behavior. (true story). What can you do? Unless the organization the website was for tells the sysadmin to HELP instead of work against the people who did work for the organization, it's a lost battle.

They want the customer to sign off that they are not “at fault” if they get hacked because we used LLBLGen pro. Of course the customer is not going to say okay to that and this will force us not to use LLBLGen for any future projects.

All queries are fully parameterized, so no sql injection attacks are possible. In fact, with procedures injection attacks ARE possible, as in a lot of cases 'general' search procs are implemented for searches, which perform string concatenation and rely on input filtering done by the caller.

Btw, I find it a bit strange that the customer has to sign a contract that the developer isn't eligable when something bad happens. That can also happen when procs are used, and the customer will then sign the contract? That's not very erm... nice, as the customer doesn't have enough info.

I love LLBLGen and want to continue using it.

I feel your pain, and you're not the first, nor the last, who has these problems. Sadly for you, organisations who have these stubborn DBA's (or stubborn Sysadmins) who work against anyone and anything which can (in their eyes) harm their sacret world, will lose a lot of money over this, directly and indirectly. Instead of using DBA's to consult with the development team to get proper software, faster time-to-market and more time for the DBA's to do work they're hired for, like creating indexes and keeping up the box, the development team has to fight for every inch and the dba's are fighting for their space as well... Very counterproductive.

I would really appreciate any arguments about how LLBLGen is secure and how to over come their arguments?

I hope this is enough, but I know from the past it isn't. Half a year ago, I stopped answering questions about this subject as it's of no use: the real cause is politics-based, not a rational way of thinking what's best for all of the people involved.

Debating these things is IMHO a bit useless and I'm very bitter in this. Not because DBA's stop sales of O/R mappers, but because of the sillyness of it: both groups work for the same organisation and it's in both groups best interest that they work together. DBA's have more knowledge of the relational model, let they be the people who assist developers what to do: use relations (joins) or fieldcompareset predicates (subqueries) for example. let them be the people who create views for the developers so they can write easier report code etc. Let them work together with the developers so when something is slow, they will profile in conjunction with the developer, the queries, and see if an index will help, a different setup or advice for the developer how to rewrite the query perhaps.

sticking with procedures won't help, it will only slow down the development process and make the whole project more vulnerable to failure as any change to code during development (and nothing is designed in full for 100% before the project starts) takes several stages and people and can break for example if a DBA refuses to adjust a proc.

Good luck. These debates are schoolbook examples why the IT doesn't function that efficient at times.

Well said.

Yep Frans, Hit that on the nail!

Geoff.

Otis wrote:

richardcherry wrote:

I have a lot of resistance about using LLBLGen pro at my work by some DBa’s.

The latest resistance is dealing with security. (the first argument is that stored procedures are the way to go)

The only way in which stored procedures are more secure is when you supply a unique secret key with every call which is checked internally in the proc.

Otherwise anyone with access to the procs can actually harm your data (like calling pr_DeleteCustomer with some random ID).

LLBLGen pro is a layer on top of ADO.Net and since it generates more code it violates the “less is more” philosophy. They would rather write custom code. Then someone cannot learn the “patterns’ that the code uses to hack the code.

Convenience in usage requires some code, yes, though the DBA's don't write your .NET code, I think. So they might say "Hey, I don't like your way of connecting to the DB", though they should work WITH you, not AGAINST you. YOU want convenience to work with the data, to get more done in less time. So what YOU need is also important, perhaps more important than what a DBA has to say, as they're not in charge of your project.

Though it's mainly politics. Giving away the right to write SQL to the developers is degrading the importance of a DBA in the organization. Unless you can overturn these politics, it's a lost battle. We've seen this before with the sysadmin's a couple of years ago: a 3rd party develops a database driven website and requires a webserver and a database system. The Sysadmin then said: "no way that database will be directly accessable from the webserver", so he adds a firewall, limiting performance and distributed transaction behavior. (true story). What can you do? Unless the organization the website was for tells the sysadmin to HELP instead of work against the people who did work for the organization, it's a lost battle.

They want the customer to sign off that they are not “at fault” if they get hacked because we used LLBLGen pro. Of course the customer is not going to say okay to that and this will force us not to use LLBLGen for any future projects.

All queries are fully parameterized, so no sql injection attacks are possible. In fact, with procedures injection attacks ARE possible, as in a lot of cases 'general' search procs are implemented for searches, which perform string concatenation and rely on input filtering done by the caller.

Btw, I find it a bit strange that the customer has to sign a contract that the developer isn't eligable when something bad happens. That can also happen when procs are used, and the customer will then sign the contract? That's not very erm... nice, as the customer doesn't have enough info.

I love LLBLGen and want to continue using it.

I feel your pain, and you're not the first, nor the last, who has these problems. Sadly for you, organisations who have these stubborn DBA's (or stubborn Sysadmins) who work against anyone and anything which can (in their eyes) harm their sacret world, will lose a lot of money over this, directly and indirectly. Instead of using DBA's to consult with the development team to get proper software, faster time-to-market and more time for the DBA's to do work they're hired for, like creating indexes and keeping up the box, the development team has to fight for every inch and the dba's are fighting for their space as well... Very counterproductive.

I would really appreciate any arguments about how LLBLGen is secure and how to over come their arguments?

I hope this is enough, but I know from the past it isn't. Half a year ago, I stopped answering questions about this subject as it's of no use: the real cause is politics-based, not a rational way of thinking what's best for all of the people involved.

Debating these things is IMHO a bit useless and I'm very bitter in this. Not because DBA's stop sales of O/R mappers, but because of the sillyness of it: both groups work for the same organisation and it's in both groups best interest that they work together. DBA's have more knowledge of the relational model, let they be the people who assist developers what to do: use relations (joins) or fieldcompareset predicates (subqueries) for example. let them be the people who create views for the developers so they can write easier report code etc. Let them work together with the developers so when something is slow, they will profile in conjunction with the developer, the queries, and see if an index will help, a different setup or advice for the developer how to rewrite the query perhaps.

sticking with procedures won't help, it will only slow down the development process and make the whole project more vulnerable to failure as any change to code during development (and nothing is designed in full for 100% before the project starts) takes several stages and people and can break for example if a DBA refuses to adjust a proc.

Good luck. These debates are schoolbook examples why the IT doesn't function that efficient at times.

Thanks for your response. It is politics and that is my frustration. I guess I am going to have to get better at playing the game.

the first argument is that stored procedures are the way to go)

Every time I see this I have to roll my eyes.

If we set an Application role for the specific application, and allow the user of our application to gain access to the database only via guest account, we don't have to add full access to database tables, only to add full access to the database table for the application account.

Gabor