Hello, At least under Windows, it's common for the ODBC driver to show a dialog box to the user asking to enter the missing information when connecting via a predefined DSN. Typically, the password is not stored in the DSN, where it could be easily seen, but entered during connection time in this dialog box.
Unfortunately this is impossible with SOCI right now as SQLDriverConnect()
call in backends/odbc/session.cpp uses SQL_DRIVER_NOPROMPT as its last
parameter which, as its name indicates, suppresses all prompts. So if the
password is not stored in the DSN, connection simply fails.
I'd like to be able to at least optionally change this. Unfortunately
there is no really obviously best way to do it as we can't pass any
parameters to the code calling SQLDriverConnect() directly, it only takes
the connection string. So I see several alternatives, let me list them here
with their pros and cons:
0. Just replace the hard-coded SQL_DRIVER_NOPROMPT with equally hard-coded
SQL_DRIVER_COMPLETE.
+ Simple.
+ Probably more useful than current behaviour by default.
- In some situations the prompt can really need to be suppressed
(although I don't really know in which ones and we haven't run into
any of them while using libodbc++, which uses SQL_DRIVER_COMPLETE, for
several years before switching to SOCI).
1. Allow having "PROMPT=0" or "PROMPT=1" in the ODBC connection string.
+ Configurable.
- Not obviously discoverable and inconsistent with other SOCI backends
as we'd be using something that is not a valid connection string for
the underlying library.
- "PROMPT" could conflict with driver-defined attribute keywords allowed
by ODBC specification (standard ones are DSN, UID and PWD).
2. Add static odbc_session_backend::enable_driver_prompt() method which
would affect the behaviour of the next session::open() calls.
+ Configurable.
- Introduces a global variable.
- While not being really inconsistent with the other backends, it's very
ODBC-specific and wouldn't help if we need to provide any other such
"out of band" connection parameters in the other backends.
3. Add some generic way to pass connection parameters other than those
specific by the connection string. E.g. add an optional
std::map<std::string, std::string> argument to session::open() which
would contain arbitrary key/value pairs that would be passed to the
backend.
+ Generic.
- Untyped (i.e. too generic) and still difficult to discover.
- Most complex.
Which approach do you think would be preferable? Or do you see some other
one, not listed above? I'm leaning towards (2) but not sure at all if it's
really the best idea.
Also, if any approach other than (0) is chosen, we'd need to decide what
should be the default value of the "prompt" option. IMHO we should allow
prompting by default, i.e. use SQL_DRIVER_COMPLETE by default, as the
current approach forces people to store the password in clear text in the
registry in the most common case which is hardly ideal from the security
point of view.
Thanks in advance for any thoughts about this,
VZ
pgpy2mSSLatUT.pgp
Description: PGP signature
------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________ soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
