I need to take a MySQL query and insert a string before each table name. The solution doesn't need to be one line but obviously it's a regex problem. It will be implemented in PHP so having programming logic is also fine.
Rationale and Background:
I'm revamping my code base to allow for table prefixes (eg: 'nx_users' instead of 'users') and I'd like to have a function that will automate that for me so I don't need to find every query and modify it manually.
Example:
SELECT * FROM users, teams WHERE users.team_id = teams.team_id ORDER BY users.last_name
Using the prefix 'nx_', it should change to
SELECT * FROM nx_users, nx_ teams WHERE nx_ users.team_id = nx_ teams.team_id ORDER BY nx_ users.last_name
Obviously it should handle other cases such as table aliases, joins, and other common MySQL commands.
Has anybody done this?
How big of a code base are we talking about here? A regular expression for something like this is seriously flirting with disaster and I think you're probably better off looking for every mysql_query or whatever in your code and making the changes yourself. It shouldn't take more than the hour you'd spend implementing your regex and fixing all the edge cases that it will undoubtedly miss.
Using a regex to rewrite code is going to be problematic.
If you need to dynamically change this string, then you need to separate out your sql logic into one place, and have a $table_prefix variable that is appropriately placed in every sql query. The variable can then be set by the calling code.
$query = "SELECT foo from " . $table_prefix . "bar WHERE 1";
If you are encapsulating this in a class, all the better.
This example does not take into consideration any escaping or security concerns.
First off, regular expressions alone are not up to the task. Consider things like:
select sender from email where subject like "from users group by email"
To really do this you need something that will parse the SQL, produce a parse tree which you can modify, and then emit the modified SQL from the modified parse tree. With that, it's doable, but not advisable (for the reasons Paolo gave).
A better approach would be to grep through your source looking for either the table names, the function you use to sent SQL, the word from, or something like it at script something to throw you into an editor at those points.
Related
This comment made me worried that the way I am searching my databases may result in an injection attack. Bellow is the query I'm currently using:
return db.query("SELECT * FROM customers
WHERE ( num LIKE ? AND name LIKE ? )",
[customer.num + "%", customer.name + "%"], callback)
Should I be adding the % symbol in my call to the API, or how would this be properly implemented?
The comment you're referring to uses string concatenation, whereas you are using prepared statements
This means that the intention is that the db.query function should be applying filtering and escaping to the inputs you provide, and hopefully they would be fairly extensive, and protecting you well.
It doesn't mean that you're immune to SQLI attacks, because there are just so many of them, but you have followed good practices in using prepared statements.
To check and/or improve your security against SQLI attacks, you could:
Audit the database connector library you are using to see whether it has known issues. npm audit is your friend here
Consider using another system for the queries, like an ORM like Sequelize, which tend to use querying systems even further separated from the actual SQL.
No, you misunderstood it. The problem comes when you concatenate a string with the SQL Query . e.g db.query("SELECT * FROM customers WHERE ( num LIKE "+ var +"AND name LIKE "+ var2+" )". You are safe here because you are using placeholders that will escape them.
Sorry about the title, I wasn't sure how to word it
I'm wanting to make a instant messaging system with PHP (I've done ajax for it) but I'm not sure how to get the query, I'm wanting something like this:
"SELECT * FROM messages WHERE user='$to' AND sender='$username' OR user='$username' AND sender='$to'"
Does anyone know if this is possible? Or a mysqli_fetch_array for two invididual queries on the same variable.
You can use parenthesis to use multiple operations to work as single operation in query. This is the typical approach anyway, and very useful for using multiple AND, OR operators in a query.
For you case, query should be like
"SELECT * FROM messages WHERE ( user='$to' AND sender='$username' ) OR ( user='$username' AND sender='$to' )"
Notice that tho we used 4 conditions, but with parenthesis we shrieked it into 2 separate conditions and ultimately one OR operation in the query.
Some good reading about this stuff at this article in case you want to dig it more
This is a request from my client to tweak an existing Perl script. However, it is the actual database structure on their end that confuses me.
The requirement looks pretty simple:
only pull records where _X begins with 1, 2, or 9.
However, the underlying database is not that simple, here is the guideline from their DBA:
"_X is a custom metadata field. The database stores this data in rows, not columns, within the customData table. In order to query the custom data table in an efficient manner you need to know the Field_ID for the custom field you get that from the fielddef table:
SELECT Field_ID FROM FieldDef WHERE Name = "_X";
This returns:
10012
"Now you can query CustomData. For example:
SELECT Record_ID FROM CustomData where Field_ID="10012" AND StringValue="2012-04";
He also suggests that in my case, probably it would be:
"SELECT Record_ID FROM CustomData where Field_ID="10012" AND (StringValue LIKE '1%' || StringValue LIKE '2%' || StringValue LIKE '9%')
The weird thing is that the existing Perl script doesn't contain anything like "Select Record_ID FROM" but all like "SELECT StringValue FROM".
So that is why I am very confused here: What is "store in rows, not in columns"? Why first query the Field_ID table then CustomData? I would not be able to communicate with any of them during this weekend but really wish to get some idea on the whole thing, hope experts can help me a little on sorting out the whole structure.
More info(Table schema):
http://pastebin.com/ZiDTCCC0
The existing perl script:(focus on lines 72-136)
http://pastebin.com/JHpikTeZ
Thanks in advance.
What they seem to be using is some kind of Entity-Attribute-Value model, with the entities stored as ints and explained in another table (FieldDef).
You explained pretty well how you queried it (although you can do it in one query, with a join or a subquery), and your problem seems to be that you don't know how the Perl script does it. Unfortunately, without us seeing the Perl script, we can't either :]
I am setting a cookie. Something like:
$_COOKIE['test'] = SHA1('124'.'mysalt');
Now 124 is my id which I want. So in my MySQL table, I am trying to run a query like:
$sql = ("SELECT * FROM users WHERE SHA1(`id`) = '".mysql_real_escape_string($_COOKIE['test'])."'");
How to add the "mysalt" to the SQL query? Because else I want get the correct id.
Use can use Concat() for that.
SELECT ... Sha1( Concat(`id`, 'mysalt') )=...
The query should be:
$sql = ("SELECT * FROM users WHERE SHA1(CONCAT(`id`,`mysalt`)) = '".mysql_real_escape_string($_COOKIE['test'])."'");
if I understand correctly what you're trying to do.
The solutions already provided probably will work just fine, however are you certain you want to do this? If the field "id" is really a distinct identification you can use "LIMIT 1" to stop mysql from searching thru all your items. Another thing is, why don't you use a separate precomputed field for this? I mean in every query mysql unnecessarily needs to compute all these sha1 values.. One last thing. I'm uncertain why you are using your approach, but my best guess is to implement some sort of session key. I thing this is a bad idea for a couple of reasons: If someone gets holds on your salt, he has access to all your accounts. If someone sniffs one "session" he can reuse it whenever he wants to. Choosing a weak salt could have serious consequences. HTH.
Use CONCAT:
$sql = ("SELECT * FROM users WHERE SHA1(CONCAT(`id`,'mysalt')) = '".mysql_real_escape_string($_COOKIE[''test''])."'");
The following doesn't work, but something like this is what I'm looking for.
select *
from Products
where Description like (#SearchedDescription + %)
SSRS uses the # operator in-front of a parameter to simulate an 'in', and I'm not finding a way to match up a string to a list of strings.
There are a few options on how to use a LIKE operator with a parameter.
OPTION 1
If you add the % to the parameter value, then you can customize how the LIKE filter will be processed. For instance, your query could be:
SELECT name
FROM master.dbo.sysobjects
WHERE name LIKE #ReportParameter1
For the data set to use the LIKE statement properly, then you could use a parameter value like sysa%. When I tested a sample report in SSRS 2008 using this code, I returned the following four tables:
sysallocunits
sysaudacts
sysasymkeys
sysaltfiles
OPTION 2
Another way to do this that doesn't require the user to add any '%' symbol is to generate a variable that has the code and exceute the variable.
DECLARE #DynamicSQL NVARCHAR(MAX)
SET #DynamicSQL =
'SELECT name, id, xtype
FROM dbo.sysobjects
WHERE name LIKE ''' + #ReportParameter1 + '%''
'
EXEC (#DynamicSQL)
This will give you finer controller over how the LIKE statement will be used. If you don't want users to inject any additional operators, then you can always add code to strip out non alpha-numeric characters before merging it into the final query.
OPTION 3
You can create a stored procedure that controls this functionality. I generally prefer to use stored procedures as data sources for SSRS and never allow dynamically generated SQL, but that's just a preference of mine. This helps with discoverability when performing dependency analysis checks and also allows you to ensure optimal query performance.
OPTION 4
Create a .NET code assembly that helps dynamically generate the SQL code. I think this is overkill and a poor choice at best, but it could work conceivably.
Have you tried to do:
select * from Products where Description like (#SearchedDescription + '%')
(Putting single quotes around the % sign?)
Dano, which version of SSRS are you using? If it's RS2000, the multi-parameter list is
not officially supported, but there is a workaround....
put like this:
select *
from tsStudent
where studentName like #SName+'%'
I know this is super old, but this came up in my search to solve the same problem, and I wound up using a solution not described here. I'm adding a new potential solution to help whomever else might follow.
As written, this solution only works in SQL Server 2016 and later, but can be adapted for older versions by writing a custom string_split UDF, and by using a subquery instead of a CTE.
First, map your #SearchedDescription into your Dataset as a single string using JOIN:
=JOIN(#SearchedDedscription, ",")
Then use STRING_SPLIT to map your "A,B,C,D" kind of string into a tabular structure.
;with
SearchTerms as (
select distinct
Value
from
string_split(#SearchedDescription, ',')
)
select distinct
*
from
Products
inner join SearchTerms on
Products.Description like SearchTerms.Value + '%'
If someone adds the same search term multiple times, this would duplicate rows in the result set. Similarly, a single product could match multiple search terms. I've added distinct to both the SearchTerms CTE and the main query to try to suppress this inappropriate row duplication.
If your query is more complex (including results from other joins) then this could become an increasingly big problem. Just be aware of it, it's the main drawback of this method.