You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Proposal: Define a SQL driver unwrapping method #46
I am the lead developer of Sqreen's Go agent, and some users are unfortunately experiencing integration issues when using your driver wrapper ocDriver with our SQL-injection protection.
The problem simply comes from the fact the underlying wrapped driver gets hidden and our SQL dialect detection function no longer gets the underlying driver package path.
Describe the solution you'd like
Simply define a new ocDriver method Unwrap returning the wrapped driver so that we can detect it and unwrap it:
So yes we could do such a thing but thinking about the use case I think you should also consider allowing consumers of your Agent to force a particular dialect instead of needing to always rely on your detection algo. I have seen these problems firsthand with sqlx even without driver wrapping but using alternative drivers.
So yes we could do such a thing but thinking about the use case I think you should also consider allowing consumers of your Agent to force a particular dialect instead of needing to always rely on your detection algo. I have seen these problems firsthand with sqlx even without driver wrapping but using alternative drivers.
Detecting the SQL dialect based on the package path is unfortunately the only option we have today, as discussed here golang/go#12600
As of manually enforcing the dialect, we don't provide such option today and we rather made the package path list dynamic so that we can update it at run time without releasing the agent nor restarting the app. But when the driver is wrapped, there's nothing we can do about it unless we have such unwrapping method available ^^'
Activity
basvanbeek commentedon Nov 12, 2020
So yes we could do such a thing but thinking about the use case I think you should also consider allowing consumers of your Agent to force a particular dialect instead of needing to always rely on your detection algo. I have seen these problems firsthand with
sqlxeven without driver wrapping but using alternative drivers.Julio-Guerra commentedon Nov 12, 2020
Detecting the SQL dialect based on the package path is unfortunately the only option we have today, as discussed here golang/go#12600
As of manually enforcing the dialect, we don't provide such option today and we rather made the package path list dynamic so that we can update it at run time without releasing the agent nor restarting the app. But when the driver is wrapped, there's nothing we can do about it unless we have such unwrapping method available ^^'