Assume that we have data inside the DTOObject
public void loginUser(UserDTO)
{
String name = UserDTO.getName();
String pwd = UserDTO.getPassword();
String sql = "select UNAME , PWD from LoginTable where uname='"+name+"' and PWD='"+pwd+"';
}
Please tell me in this code , how can we prevent SQL Injection ?? How can we check for Malicious characters ??
Your best bet is to move SQL from the DTO, where it doesn't belong, to the DAO, where it belongs, and use PreparedStatement there.
Here is the official tutorial on using PreparedStatement in JDBC. There are also plenty of others if you search around.
For the record, I must say that I disagree with the claim that the main advantage of a prepared statement is that it can be (though isn't necessarily) sent to the database in advance. The main advantage is parameters.
Related
I am new to OData, so any help would be appreciated.
I created a test ASP .Net Web API project to query data from SQL Server using OData and Drapper is used instead of EF. I found that the query filter does not get pushed into the query which is executed on the database.
q1. Does the push down work only with EF ?
q2. would OData work for any source which has a ODBC driver.
code snippet
public class InboundMetaDataController : ODataController
{
DapperContext db = new DapperContext();
[EnableQuery]
public IQueryable<InboundMetaData> Get()
{
return GetInboundMeta();
}
public IEnumerable<InboundMetaData> GetInboundMetaRecords()
{
var query = "SELECT Id, DataSource, Client, DataPath FROM Datalake.InboundMetaData ";
using (var connection = db.CreateConnection())
{
return connection.Query<InboundMetaData>(query).AsEnumerable();
}
}
public IQueryable<InboundMetaData> GetInboundMeta()
{
IEnumerable<InboundMetaData> qry = GetInboundMetaRecords();
return qry.AsQueryable();
}
}
public class DapperContext
{
private readonly string _connectionString = #"server=server1; database=test_db; Integrated Security=true; Encrypt=false";
public IQueryable<InboundMetaData> InboundMetaData { get; internal set; }
public IDbConnection CreateConnection()
=> new SqlConnection(_connectionString);
}
Thanks
Manoj George
The .Net OData implementation translates the incoming OData query into a LINQ expression tree. Unfortunately this can't easily be mapped into a Dapper query because it is not translated directly into an SQL query string.
q1. Does the push down work only with EF ?
So the direct answer is NO, this push down doesn't only work with EF, OOTB it will only work with a provider that supports IQueryable expression trees. otherwise you will need to manually parse the expression to SQL.
q2. would OData work for any source which has a ODBC driver.
You can make it work with any backend provider, but depending on the implementation you might have to do a lot of mapping or query building work yourself.
Technically, EF can be made to work with ODBC drivers, the ability to be vendor agnostic is often a reason to use EF in the first place. You can write your own custom implementation when needed, and for many ODBC drivers you might need to.
In regard to Dapper however, Dapper does not support IQueryable. Other users have found specific solution to this: Dapper, ODATA, and IQueryable in ASP.NET by iterating through the expression tree to build the SQL.
The problem with a solution like that, is that you've now manually replicated similar logic to what EF provides for you, and it is likely to take longer to execute than EF that has been specifically optimised for this type of processing. So the only argument that you might have to use Dapper has been invalidated.
In most implementations OData using Dapper will either have significantly reduced query features and possibly will not support aggregates or expansions, but will take longer to execute or will consume significantly more operational memory than if you had used Entity Framework as the ORM.
this is the line that first breaks the concept:
return connection.Query<InboundMetaData>(query).AsEnumerable();
At that point, before the request arguments are evaluated, the raw query without a filter is loaded into memory. .AsEnumerable() is the same as using .ToList() or .ToArray() in terms of moving the data execution into the API and out of the underlying data store.
This is the second anti-pattern in the same method:
using (var connection = db.CreateConnection())
{
return connection. Query<InboundMetaData>(query).AsEnumerable();
}
Because the DB Connection is closed before the controller method has completed execution, even if the output supported an IQueryable expression tree, the EnableQueryAttribute can only operate on the data that is in memory. If the query had not yet been executed, the whole call would fail because the connection has been closed before the query was executed.
For that reason, in OData controllers be tend to declare the DbContext or DbConnection for the lifetime of the request and do not dispose of it before the response content has been serialized.
If you're interested, I've written up a blog article that might help: Should I use Dapper?
I read that getOne() is lazy loaded and findOne() fetches the whole entity right away. I've checked the debugging log and I even enabled monitoring on my sql server to see what statements gets executed, I found that both getOne() and findOne() generates and executes the same query. However when I use getOne() the values are initially null (except for the id of course).
So could anyone please tell me, if both methods executes the same query on the database, why should I use one over the other? I'm basically looking for a way to fetch an entity without getting all of its children/attributes.
EDIT1:
Entity code
Dao code:
#Repository
public interface FlightDao extends JpaRepository<Flight, Long> {
}
Debugging log findOne() vs getOne()
EDIT2:
Thanks to Chlebik I was able to identify the problem. Like Chlebik stated, if you try to access any property of the entity fetched by getOne() the full query will be executed. In my case, I was checking the behavior while debugging, moving one line at a time, I totally forgot that while debugging the IDE tries to access object properties for debugging purposes (or at least that's what I think is happening), so debugging triggers the full query execution. I stopped debugging and then checked the logs and everything appears to be normal.
getOne() vs findOne() (This log is taken from MySQL general_log and not hibernate.
Debugging log
No debugging log
It is just a guess but in 'pure JPA' there is a method of EntityManager called getReference. And it is designed to retrieve entity with only ID in it. Its use was mostly for indicating reference existed without the need to retrieve whole entity. Maybe the code will tell more:
// em is EntityManager
Department dept = em.getReference(Department.class, 30); // Gets only entity with ID property, rest is null
Employee emp = new Employee();
emp.setId(53);
emp.setName("Peter");
emp.setDepartment(dept);
dept.getEmployees().add(emp);
em.persist(emp);
I assume then getOne serves the same purpose. Why the queries generated are the same you ask? Well, AFAIR in JPA bible - Pro JPA2 by Mike Keith and Merrick Schincariol - almost every paragraph contains something like 'the behaviour depends on the vendor'.
EDIT:
I've set my own setup. Finally I came to conclusion that if You in any way interfere with entity fetched with getOne (even go for entity.getId()) it causes SQL to be executed. Although if You are using it only to create proxy (eg. for relationship indicator like shown in a code above), nothing happens and there is no additional SQL executed. So I assume in your service class You do something with this entity (use getter, log something) and that is why the output of these two methods looks the same.
ChlebikGitHub with example code
SO helpful question #1
SO helpful question #2
Suppose you want to remove an Entity by id. In SQL you can execute a query like this :
"delete form TABLE_NAME where id = ?".
And in Hibernate, first you have to get a managed instance of your Entity and then pass it to EntityManager.remove method.
Entity a = em.find(Entity.class, id);
em.remove(a);
But this way, You have to fetch the Entity you want to delete from database before deletion. Is that really necessary ?
The method EntityManager.getReference returns a Hibernate proxy without querying the database and setting the properties of your entity. Unless you try to get properties of the returned proxy yourself.
Method JpaRepository.getOne uses EntityManager.getReference method instead of EntityManager.find method. so whenever you need a managed object but you don't really need to query database for that, it's better to use JpaRepostory.getOne method to eliminate the unnecessary query.
If data is not found the table for particular ID, findOne will return null, whereas getOne will throw javax.persistence.EntityNotFoundException.
Both have their own pros and cons. Please see example below:
If data not found is not failure case for you (eg. You are just
verifying if data the data is deleted and success will be data to be
null), you can use findOne.
In another case, you can use getOne.
This can be updated as per your requirements, if you know outcomes.
I am using derby embedded database for my Maven test cases. And I am not able to use SUBSTR inside TO_DATE, its giving error.
Actually it was used for original application which is connected to oracle db. Now I am writing Maven test cases, with derby embedded db and unable to execute this one. The thing is I should not modify the original query and I need some workaround to rectify this issue.
My query will be like this.
SELECT TO_DATE (SUBSTR (testdate, 1, 9), 'DD-MM-RR') FROM testtable
Please help me on this issue. Thanks.
Substr cannot be used with DATE. You cannot not override it. SQL is not easily re-used between database. The easiest part is to change the sql.
The harder part is to step deep into derby:
If you want to make this work without changing the query, you could wrap the connection or the DataSource and change the sql on a lower Level.
For this to work you need access to the Connection Object in your test:
Connection wrapped = new WrappedConnection(originalConnection);
This is a short example of a wrapped Connection, with a migrate function (this is basically the Adapter Pattern:
public class WrappedConnection implements Connection
{
private final Connection origConnection;
public WrappedConnection(Connection rv)
{
origConnection = rv;
}
//I left out other methods, that you have to implement accordingly
public PreparedStatement prepareStatement(String pSql) throws SQLException
{
//this you have to implement yourself
//this will serve as a bridge between oracle and derby
String sql = migrate(sql);
return sql;
}
}
The migrate function could to something like this:
public String migrate(String sql)
{
return sql.replace("SUBSTR", "SUBSTR_DATE");
}
But you would have to create your own Derby Function SUBSTR_DATE.
I can think of 2 options... I don't know how much sense either makes but...
Create a sub class of the original, and (assuming that the line is only used in one method of that class) simply override that single method. and leave the rest of the code the same.
If the class that calls this SQL send the message to a customised 'sendSQLStatement(String sql) tpe method, this would handle all the creation of the statement object, surround with try / catch error handling etc, and return the result set, you could set an overide in the method to check for the DB engine being used.
This info is obtainable from the databaseMetaData.getDatabaseProductName(), or alternatively from the get .getDriverName() method. you then test this string to see if it contains the word 'derby' and if yes send a different type of SQL.
Of course later on down the road you will need to perform a final test to ensure that the original Oracle code still works.
You may even take the opportunity to modify the whole code snippet to make it more DB agnostic (ie cast the value to a string type (or a date from a long) and then do the substring function.
I have defined a GenericRepository class which does the db interaction.
protected GenericRepository rep = new GenericRepository();
And in my BLL classes, I can query the db like:
public List<Album> GetVisibleAlbums(int accessLevel)
{
return rep.Find<Album>(a => a.AccessLevel.BinaryAnd(accessLevel)).ToList();
}
BinaryAnd is an extension method which checks two int values bit by bit. e.g. AccessLevel=5 => AccessLevel.BinaryAnd(5) and AccessLevel.binaryAnd(1) both return true.
However I cannot use this extension method in my LINQ queries. I get a runtime error as follows:
LINQ to Entities does not recognize the method 'Boolean BinaryAnd(System.Object, System.Object)' method, and this method cannot be translated into a store expression.
Also tried changing it to a custom method but no luck. What are the workarounds?
Should I get all the albums and then iterate them through a foreach loop and pick those which match the AccessLevels?
I realize this already has an accepted answer, I just thought I'd post this in case someone wanted to try writing a LINQ expression interceptor.
So... here is what I did to make translatable custom extension methods: Code Sample
I don't believe this to be a finished solution, but it should hopefully provide a good starting point for anyone brave enough to see it through to completion.
You can only use the core extension methods and CLR methods defined for your EF provider when using Entity Framework and queries on IQueryable<T>. This is because the query is translated directly to SQL code and run on the server.
You can stream the entire collection (using .ToEnumerable()) then query this locally, or convert this to a method that is translatable directly to SQL by your provider.
That being said, basic bitwise operations are supported:
The bitwise AND, OR, NOT, and XOR operators are also mapped to canonical functions when the operand is a numeric type.
So, if you rewrite this to not use a method, and just do the bitwise operation on the value directly, it should work as needed. Try something like the following:
public List<Album> GetVisibleAlbums(int accessLevel)
{
return rep.Find<Album>(a => (a.AccessLevel & accessLevel > 0)).ToList();
}
(I'm not sure exactly how your current extension method works - the above would check to see if any of the flags come back true, which seems to match your statement...)
There are ways to change the linq query just before EF translates it to SQL, at that moment you'd have to translate your ''foreign'' method into a construct translatable by EF.
See an previous question of mine How to wrap Entity Framework to intercept the LINQ expression just before execution? and mine EFWrappableFields extension which does just this for wrapped fields.
As title. I didn't find one via google, at any rate.
Update: thanks for the links from the two answers; this is very useful, but not what I was after - I am curious to see whether it is possible to query an IRepository backed by memcached (or some other distributed cache), backed by a RDBMS. I've really no idea how that might work in practise; I don't know very much about the internals of either distributed caches or LINQ providers.
I'm maybe envisaging something like the cache LINQ provider generating cache-keys based on the query automatically (where query could be Expression> or some kind of Specification pattern implementation), and basically can be plumped down inbetween my app and my DB. Does that sound useful?
If you don't mind throwing NHibernate between them, you can use LINQ to NHibernate to query entities which can be set to use memcached as their cache.
I dont if this is what you want, you can check in this website. In there you can query Memcached as well as query linq to object.
public static IEnumerable<User> GetAllUsers()
{
// Retrieve from cache if it exists, otherwise run the query
return (from u in ctx.Users select u).CachedQuery("allusers");
}
Is this what you want ?
Here is the source code
public static IEnumerable<T> CachedQuery<T>
(this IQueryable<T> query, string key) where T : class
{
if (cache.KeyExists(key))
{
return (IEnumerable<T>)cache.Get(key);
}
else
{
IEnumerable<T> items = query.ToList();
cache.Set(key, items);
return items;
}
}
Because I didn't know what memcached is I googled around and found this link:
http://latebound.blogspot.com/2008/10/using-memcached-from-c.html
Which has a section near the bottom on using LINQ queries over memcached.
I encounter some problem with linq for memcached also. But you should check out the serialization of your linq DBML whether it's Unidirectional or not.
you might have luck for this solution, worth to try out. For me, i sitll having problem with linq, but other object that have [Serilizable] attribute works fine.