When connecting to a remote server (e.g., proxy table) via an ODBC DSN, does the middleware ever make use of a user id and password that is recorded in the DSN registry entry? I think the answer is no, not even for a SQL Anywhere remote server... you must either define an EXTERNLOGIN or specify UID and PWD values in the remote server connection string. If you do neither, it will use the user id and password that was used to make the current connection (on the source or client database). Related question: How can DSN EncryptedPassword / ENP values be handled? |
Just to add a later answer (actually a comment) from Karim on a related question:
So the answer does fit Breck's expectation (or at least his impression...): No, the credentials from the DSN are never used, and as a consequence (to cite from Breck's question):
CAVEAT: AFAIK, this does also apply to remote calls from within stored procedures and the like: It's still the current user (and not the procedure owner) who does make the remote connection - and therefore needs his own externlogin or needs fitting remote credentials (unless the remote credentials are already specified in the remote server connection string). 2
Volker, With regards to your CAVEAT above, the behavior that you have correctly observed with respect to remote calls from within stored procedures has been corrected in the next release of SQL Anywhere (SA 16). SA 16 now respects the "effective user" when establishing remote connections. Hence if a user logs in as A, queries a proxy table, then calls procedure B.p1() which was created as DEFINER, and if B.p1() then makes a remote request to the same remote server, then two remote connections will be established, one with A's external credentials and the second one with B's external credentials. There is also an option to revert back to SA 12 and below behavior to ensure that current applications do not break.
(24 Jan '13, 13:03)
Karim Khamis
Replies hidden
That's good news - we usually face the situation that user A (a normal "user") does not make direct remote connections but may use procedures owned by B (i.e. the DBA...) that do remote calls - and then in V16 only B would need remote credentials. Today, I still have to create externlogins for A, too. - So yes, I consider this a clear improvement. BTW: I haven't found that change listed in the v16 beta docs. Have I missed a point?
(25 Jan '13, 03:24)
Volker Barth
Volker, Have a look at the write up for the new extern_login_credentials option. I will, in the meantime, make sure the documentation team adds a new feature note.
(25 Jan '13, 15:33)
Karim Khamis
Replies hidden
Thanks for the hint. Currently, that option is only listed as a new option (as "Beta: under construction") which made me oversee this one - but its own doc page does make the usage clear.
(27 Jan '13, 15:32)
Volker Barth
|