I want to perform a query using the SQL LIKE operation with a string parameter.
Example:
coffee <- Coffees if coffee.name like s"%$queryString%"
Is it safe?
From Slick documentation :
Slick’s key feature are type-safe, composable queries. Slick comes with a Scala-to-SQL compiler, which allows a (purely functional) sub-set of the Scala language to be compiled to SQL queries [...]
The fact that such queries are type-safe not only catches many mistakes early at compile time, but also eliminates the risk of SQL injection vulnerabilities
I did no try myself, but I think you are safe even when using user params
Related
I'm new to Scala and Slick and was surprised by something in the Slick documentation:
The following primitive types are supported out of the box for
JDBC-based databases in JdbcProfile
...
Unit
...
I don't get why this list contains Unit. From my understanding, Unit is similar to Java's void, something I neither can save to nor receive from my database. What is the intention behind it?
edit: you can find it here.
One way to look at Slick is running Scala code on your database as the execution engine. We are working on allowing more Scala code over time. An expression that contains a unit, e.g. in a tuple is a valid Scala expression and thus should be runnable by Slick unless there is a good reason why not. So we support unit.
I'm building a Java Web Application using Java EE 6 and JSF-2.0, using the persistence API for all database operations.
The back-end is MySQL, but I have used the EntityManager functions and Named Queries in EJB-QL for all operations. Are SQL injection attacks possible in this case?
It's only possible if you're inlining user-controlled variables in a SQL/JPQL string like so:
String sql = "SELECT u FROM User u WHERE id=" + id;
If you aren't doing that and are using parameterized/named queries only, then you're safe.
Yes, it is possible. It depends on the way you implement.
Have a look at Preventing injection in JPA query language.
If your JPA provider processes all input arguments to handle injection attacks then you should be covered. We do thin in EclipseLink.
As the previous poster mentioned piecing together your own JPQL or SQL (for native queries) could expose you.
I would recommend using named queries with parameters over concatenating strings to build JPQL/SQL.
Doug
In case you're asking from an offensive/practical perspective, if a JPQL statement is constructed from user input, consider the following user input:
blah') AND FUNCTION('user like chr(65)||chr(37) AND 42 - ', 1) > 40 AND ('42'='42
If the victim is using a JPA implementation >= 2.1, and the backend database is Oracle, something like the above may act as a boolean SQL injection to tell you if the database user starts with 'A'.
I have run into an "issue" I am not quite sure I understand with Entity Framework. I am using Entity Framework 4 and have tried to utilize a TDD approach. As a result, I recently implemented a search feature using a Repository pattern. For my test project, I am implementing my repository interface and have a set of "fake" object data I am using for test purposes.
I ran into an issue trying to get the Contains clause to work for case invariant search. My code snippet for both my test and the repository class used against the database is as follows:
if (!string.IsNullOrEmpty(Description))
{
items = items.Where(r => r.Description.ToLower().Contains(Description.ToLower()));
}
However, when I ran my test cases the results where not populated if my case did not match the underlying data. I tried looking into what I thought was an issue for a while. To clear my mind, I went for a run and wondered if the same code with EF would work against a SQL back end database, since SQL will explicitly support the like command and it executed as I expected, using the same logic.
I understand why EF against the database back end supports the Contains clause. However, I was surprised that my unit tests did not. Any ideas why other than the SQL server support of the like clause when I use objects I populate in a collection instead of against the database server?
Thanks!
John
LINQ to Entities and LINQ to Objects have different rules. It's that simple. For example, in LINQ to Entities, I can run a query like this:
var foo = Context.Foos.Where(f => f.Bar.Something == bar);
... And if f.Bar happens to be a null reference, this statement will still work just fine, because f.Bar.Something will coalesce to null. If you think about how SQL works, with a LEFT JOIN, this should not be surprising. In LINQ to objects, on the other hand, the same Where expression would throw a null reference exception.
As you've found, there are other areas of difference. Case sensitivity is one. When a LINQ to Entities query is executed, it is transformed to SQL. Equality comparisons are performed based on the collation rules defined in the database, as well as in the SQL. To customize a collation for a database, you generally select a specific collation for a column. On the other hand, to customize collations for objects, you generally pass a comparison function, which would never be accepted in LINQ to Entities, as functions (as opposed to expressions) cannot be transformed into SQL.
There is, however, a way to do case-insensitive comparisons which works in both LINQ providers:
var foo = Context.Foos.Where(f => f.SomeString.Equals(someValue, StringComparison.OrdinalIgnoreCase));
can anyone give some reference for non-sql database query interface design pattern?
For sql-based database, the query can be achieved by combining the query token.
but for non-sql, how to design the query, given that the query could be very complex.
EDIT:
I am using db4o to store some objects, I may need to query according to a certain Id, time range, or the combination of them.
How to design the query method?
public IEnumerable<Foo> GetFoos(int id);
public IEnumerable<Foo> GetFoos(int id, TimeRange range);
To build a lot of overloads seem stupid, what if a new query is needed?
In C#, it's definitely best to use Linq. Native Queries often fail to optimize, which will lead db4o to hydrate all objects and actually call the lambda expression on the instantiated object. That is nothing but an automated fallback to linq-to-objects and it's damn slow in comparison. Merely hydrating 60k of our typical objects takes multiple seconds.
Hint: A breakpoint on the lambda expression must never be invoked.
Even when using Db4oTool.exe to optimize native queries as a post-build step, even simple queries lead to problems when using properties or auto-properties in domain objects.
The linq provider always gave the best results for me. It has the most concise syntax and it's optimizations work. Also the linq provider is very complete, only it might fall back to linq-to-objects more often than you expect.
Also, it's important for the linq provider to have certain dlls in the project folder. Which these are depends on the version a bit. If you are using builds >= 14204, make sure Mono.Reflection.dll is in your app folder.
For older versions, all of the following must be present:
Db4obects.Db4o.Instrumentation.dll
Db4objects.Db4o.NativeQueries.dll
Mono.Cecil.dll
Cecil.FlowAnalysis.dll
Note that for native queries these are still required even in newer builds.
It looks like db4o uses its own queries, which Versant calls Native Queries (note: there's a separate syntax for .Net and Java native queries). Something like:
IObjectContainer container = Database();
container.Query(delegate(Foo foo) {
return foo.id == id;
});
container.Query(delegate(Foo foo) {
return foo.id == id;
},
delegate(Foo foo) {
return range.IsIn(foo.time);
});
When using the Entity Framework, does ESQL perform better than Linq to Entities?
I'd prefer to use Linq to Entities (mainly because of the strong-type checking), but some of my other team members are citing performance as a reason to use ESQL. I would like to get a full idea of the pro's/con's of using either method.
The most obvious differences are:
Linq to Entities is strongly typed code including nice query comprehension syntax. The fact that the “from” comes before the “select” allows IntelliSense to help you.
Entity SQL uses traditional string based queries with a more familiar SQL like syntax where the SELECT statement comes before the FROM. Because eSQL is string based, dynamic queries may be composed in a traditional way at run time using string manipulation.
The less obvious key difference is:
Linq to Entities allows you to change the shape or "project" the results of your query into any shape you require with the “select new{... }” syntax. Anonymous types, new to C# 3.0, has allowed this.
Projection is not possible using Entity SQL as you must always return an ObjectQuery<T>. In some scenarios it is possible use ObjectQuery<object> however you must work around the fact that .Select always returns ObjectQuery<DbDataRecord>. See code below...
ObjectQuery<DbDataRecord> query = DynamicQuery(context,
"Products",
"it.ProductName = 'Chai'",
"it.ProductName, it.QuantityPerUnit");
public static ObjectQuery<DbDataRecord> DynamicQuery(MyContext context, string root, string selection, string projection)
{
ObjectQuery<object> rootQuery = context.CreateQuery<object>(root);
ObjectQuery<object> filteredQuery = rootQuery.Where(selection);
ObjectQuery<DbDataRecord> result = filteredQuery.Select(projection);
return result;
}
There are other more subtle differences described by one of the team members in detail here and here.
ESQL can also generate some particularly vicious sql. I had to track a problem with such a query that was using inherited classes and I found out that my pidly-little ESQL of 4 lines got translated in a 100000 characters monster SQL statetement.
Did the same thing with Linq and the compiled code was much more managable, let's say 20 lines of SQL.
Plus, what other people mentioned, Linq is strongly type, although very annoying to debug without the edit and continue feature.
AD
Entity-SQL (eSQL) allows you to do things such as dynamic queries more easily than LINQ to Entities. However, if you don't have a scenario that requires eSQL, I would be hesitant to rely on it over LINQ because it will be much harder to maintain (e.g. no more compile-time checking, etc).
I believe LINQ allows you to precompile your queries as well, which might give you better performance. Rico Mariani blogged about LINQ performance a while back and discusses compiled queries.
nice graph showing performance comparisons here:
Entity Framework Performance Explored
not much difference seen between ESQL and Entities
but overall differences significant in using Entities over direct Queries
Entity Framework uses two layers of object mapping (compared to a single layer in LINQ to SQL), and the additional mapping has performance costs. At least in EF version 1, application designers should choose Entity Framework only if the modeling and ORM mapping capabilities can justify that cost.
The more code you can cover with compile time checking for me is something that I'd place a higher premium on than performance. Having said that at this stage I'd probably lean towards ESQL not just because of the performance, but it's also (at present) a lot more flexible in what it can do. There's nothing worse than using a technology stack that doesn't have a feature you really really need.
The entity framework doesn't support things like custom properties, custom queries (for when you need to really tune performance) and does not function the same as linq-to-sql (i.e. there are features that simply don't work in the entity framework).
My personal impression of the Entity Framework is that there is a lot of potential, but it's probably a bit to "rigid" in it's implementation to use in a production environment in its current state.
For direct queries I'm using linq to entities, for dynamic queries I'm using ESQL. Maybe the answer isn't either/or, but and/also.