Make custom query parameter literal vs string

[brad]

@psweb

The setup in Wappler is just another database connection, and whenever I do read type stuff only I use that connection instead of the main one.

That makes sense. Thank you!

[JonL]

@TomD

Would this be a valid use of such dynamic queries?

It’s a valid use.

@TomD

Here’s an example of a feature which could be implemented using dynamic custom queries (using the method suggested above).

Is it safe? No
Would I use it? No.
Would I build it if you paid me money? No. I have standards.

Please guys. Do not encourage this horrible practice.

[brad]

@JonL

Please guys. Do not encourage this horrible practice.

I have been following this thread to try and learn but it seems it has taken a couple different directions. Which horrible practice are you referring to? I’m kinda lost.

[JonL]

Make custom query parameter literal vs string

Heres a secret: you can use direct Wappler expression in custom query. Don’t use params. Just bind expression like you would in a set value. select '{{column_name}}' from '{{table_name}}' ; WARNING: Do not use this for user submitted value. This type of query is a huge security risk.

This but ignoring the disclaimer.

[psweb]

The whole idea right from the start was a bad idea in a production environment, even just accessing the information_schema etc.
Just terrible from a security standpoint.

The only reason i had for even doing this in the first place was because i needed to find all image paths on a database I have not fully created, so I knew what tables had any dealings with images.
Now that I know what tables are used of the 50 I can target each properly.
The alternate would have been a mysql dump and find in a text editor of choice.

[psweb]

@JonL

Please guys. Do not encourage this horrible practice.

Just to clarify, I am in no way encouraging using this type of idea from my side, however in the same way that nuclear bombs were invented which was clearly a bad idea, many smart people used it’s research to create things like nuclear submarines which I suppose could be arguably good/bad. Therefore in the vein of knowledge expansion, its still valid information.
However I am for one very grateful for the warning labels you give us before I blow my own hands off.

[sid]

The security issues around direct parameters make it dangerous.
That said, I am using it in an app. Although its an internal use app with security stuff in place, but its still dangerous.

The information_schema use case that you have @psweb, is exactly where I am using it too. But I found a way to use it in a manner that my inputs get “checked” before being run in the query.
0. Security Restrict!

1. First, I set a custom query, and pass all the params that I am going to use - table name, column name etc. - via regular PDO Parameter mechanism to check agains info_schema table itself.
   
2. Then I have a condition in place which checks if the output from above query matches the inputs or not.
   
3. In true part of this condition, I have the dangerous custom query with direct expression binding.

These steps ensure that the inputs will always be what I want them to be. So even in case of a security restrict compromise (although I am yet to see that happen in my Wappler projects), inputs will still be validated before the queries execute.