[
https://issues.jboss.org/browse/TEIID-2863?page=com.atlassian.jira.plugin...
]
Ramesh Reddy commented on TEIID-2863:
-------------------------------------
* Instead of fixed patterns like "GSS", I see that you delegated them back to
session service and user, which is fine.
* I see that user has to decide now during the deploy time what authentication they
support. USERPASSWORD or GSS, my previous code was trying accommodate both at same time
during connection. User has choice of logging into one or other. I thought that was the
intent of this issue. With jdbc that still seems to be the case based on configured
properties on client side, not with ODBC.
* "authType", negotiation with JDBC is good, but IMO that path is 100%
guaranteed to end up with failure as no "jassName", so we might as fail to begin
with.
Possible that I may be reading something wrong from what u intended.
Allow both gssapi and username/password authentication on the same
transport
----------------------------------------------------------------------------
Key: TEIID-2863
URL:
https://issues.jboss.org/browse/TEIID-2863
Project: Teiid
Issue Type: Enhancement
Components: Server
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Attachments: auth.patch
With GSSAPI support enabled, username/password support on the same transport is
effectively disabled. JDBC/ODBC should ideally support both on the same transport.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira