Is there any plan to add kerberos authentication to the sybase engine in sqlalchemy?
I've implemented it but it's using the creator parameter of the create_engine function, which is ok, but in certain circumstances when the application using sqlalchemy uses configuration from a text file, I'm not able to do it easily (in pylons I need to modify my templates, or add a bunch of code to each project).
It would be nice if sqlalchemy would be able to accept the server's principal specified in the connection string somehow - and if it's specified use kerberos to authenticate the client.
Is it possible to implement this modification in sqlalchemy? I'm happy to contribute my current implementation.
Thanks,
Zsolt
--------------------------------------------------------------------------
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
> --
> You received this message because you are subscribed to the Google Groups "sqlalchemy" group.
> To post to this group, send email to sqlal...@googlegroups.com.
> To unsubscribe from this group, send email to sqlalchemy+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
>
Here is an example:
conn = Sybase.connect(hostname, "", "", delay_connect=1)
conn.set_property(Sybase.CS_SEC_NETWORKAUTH, Sybase.CS_TRUE)
conn.set_property(Sybase.CS_SEC_SERVERPRINCIPAL, principal)
conn.connect()
The variable principal would come from connection string.
Zsolt
On Jun 11, 2010, at 4:50 AM, Cserna, Zsolt wrote:
>
> The DBAPI is python-sybase (http://python-sybase.sourceforge.net/).
>
> Here is an example:
>
> conn = Sybase.connect(hostname, "", "", delay_connect=1)
> conn.set_property(Sybase.CS_SEC_NETWORKAUTH, Sybase.CS_TRUE)
> conn.set_property(Sybase.CS_SEC_SERVERPRINCIPAL, principal)
> conn.connect()
>
> The variable principal would come from connection string.
OK that is fine, is the above part of some larger pattern of connection styles ? like is there some other series of things I can do ater setting NETWORKAUTH to TRUE , other options ? if we want to make a feature out of this, it would be best to suit the whole range of use cases.
You can find the properties at:
http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.mainframeconnect_12.6.occprc/html/occprc/occprc46.htm
And at:
http://infocenter.sybase.com/help/topic/com.sybase.help.sdk_12.5.1.ctref/html/ctref/X29866.htm
I think it you want to make it flexible there should be a dictionary or a two-dimensional list specifying which options should be set, so in case of kerberos it would have two elements. Unfortunatelly these options cannot be specified for the connect() function of python-sybase.
>
> Behind the scenes the c library calls ct_con_props C function:
> http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.mainframeconnect_12.6.occprc/html/occprc/X38419.htm
>
> You can find the properties at:
> http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.mainframeconnect_12.6.occprc/html/occprc/occprc46.htm
>
> And at:
> http://infocenter.sybase.com/help/topic/com.sybase.help.sdk_12.5.1.ctref/html/ctref/X29866.htm
>
> I think it you want to make it flexible there should be a dictionary or a two-dimensional list specifying which options should be set, so in case of kerberos it would have two elements. Unfortunatelly these options cannot be specified for the connect() function of python-sybase.
the goal here is so that the options can all be embedded in the URL at least as key/value pairs. How would the Sybase.XXX symbols be embedded ?
The biggest problem here is the serialization of those values to string and de-serializing them when sqlalchemy sets them to python-sybase.
It could be ok if we would know the type of the property but as far as I see it cannot be introspected from the sybase library.
We could have an algorithm serializing/deserializing the value:
- if it's starting with "CS_", we use it as the name of the variable in the Sybase module
- if we can convert it to an integer we use it as an integer
- otherwise we use it as string specified
Based on the above, my kerberos connection url would be the following (missing username+pw in this case):
sybase+pysybase://hostname/?CS_SEC_NETWORKAUTH=CS_TRUE&CS_SEC_SERVERPRINCIPAL=sybase/some_host
It's just an idea, I don't know how it could fit into the design of sqlalchemy.
Zsolt
>
>>> I think it you want to make it flexible there should be a
>> dictionary or a two-dimensional list specifying which options
>> should be set, so in case of kerberos it would have two
>> elements. Unfortunatelly these options cannot be specified
>> for the connect() function of python-sybase.
>>
>> the goal here is so that the options can all be embedded in
>> the URL at least as key/value pairs. How would the
>> Sybase.XXX symbols be embedded ?
>>
>
> The biggest problem here is the serialization of those values to string and de-serializing them when sqlalchemy sets them to python-sybase.
> It could be ok if we would know the type of the property but as far as I see it cannot be introspected from the sybase library.
>
> We could have an algorithm serializing/deserializing the value:
> - if it's starting with "CS_", we use it as the name of the variable in the Sybase module
> - if we can convert it to an integer we use it as an integer
> - otherwise we use it as string specified
>
> Based on the above, my kerberos connection url would be the following (missing username+pw in this case):
>
> sybase+pysybase://hostname/?CS_SEC_NETWORKAUTH=CS_TRUE&CS_SEC_SERVERPRINCIPAL=sybase/some_host
>
> It's just an idea, I don't know how it could fit into the design of sqlalchemy.
we can do whatever we want, this would all be local to the python-sybase dialect. The above is sort of like what I was thinking.
>
> Zsolt
>
>
> --------------------------------------------------------------------------
> NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
>