Consider removing qops option for DSEGSSAPIAuthProvider


My understanding is that DSE only supports a qops of 'auth' anyway, so it would simplify the api to not offer the qops option and hard-code it to 'auth' when creating the GSSAPIAuthenticator.

From a consistency angle, Java, NodeJS, nor Ruby support/expose this option. (Not sure about other drivers.)



Pull Requests



Sandeep Tamhankar
June 11, 2016, 5:04 AM

The way I see it, we're release v1 of these drivers. Anything we ship with, we have to live with for a long time (possibly forever), and we don't know what the future holds. If DSE never adds more values for qops options, then we'll have this stale param in the api for a very long time. To address your reasons to keep it:

1. Yeah, but all of that is internal to us. No external users / customers are affected; even if they are using beta's/RCs, that's life with pre-release software. Shouldn't be much work to tweak that.
2. Sure, but it's actually defaulting to None, not 'auth'. Your example in auth.rst explicitly specifies qops=['auth']. Users shouldn't have to do that.
3. Sure, but the chances of adding another arg in DSEGSSAPIAuthProvider constructor after service is pretty small; and even if you did, it would be have something to do with gss-api, so it wouldn't be foreign.
4. Hmm...maybe.

So, you did say one thing to really give me pause: can DSE be configured to run with a different qops value than 'auth'? My rudimentary understanding is that the server (DSE) is configured to offer various levels of protection, declared in the qops option (though the docs are fuzzy about this; they say the server must offer just one, but that the client must match one of those specified in the server). When a client connects, it receives that list of supported protection levels with the server, and it finds the set intersection of server-qops levels and client-qops levels and responds to the server with the highest qops level that both support. So if the server supports all qops levels, the client isn't required to do so. I'm not sure other qops values would make sense for us anyway since I believe those higher qops values apply to other messages sent between the client and server, and we don't send any messages that way...unless they mean messages between client and DSE that occur during authentication. Like I said, my understanding of this is somewhat rudimentary.

With all that, what do you think?

Adam Holmberg
June 11, 2016, 8:02 AM

There are at least two integrations that use this parameter. Internal, yes, but they would be broken nonetheless, by removing something "just because". cqlsh actually has this as a configurable attribute.

This corresponds to a server-side setting:

My current understanding is that it doesn't matter what this is set to, but they do have to match. If the client qops set does not include the single setting specified on the server, the negotiation fails (at least with the puresasl implementation). We can avoid issues with that by defaulting to all, but I'm still not sure why we would remove configurability. I can't say why this was included in the server configuration, but as long as it's there I think it's valid configuration for the client side, and I don't think it's causing any problems being there.

I do agree that users should not have to specify it by default.

Sandeep Tamhankar
June 14, 2016, 11:21 AM

Ok, so how about changing the default value from None to 'auth'? I don't think removing this configurability is a "just because"; it's a "the user will never tweak this because DSE will never support a different value because if they did they'd break all of their Java users because the Java driver doesn't let users specify the qops," so what's the point. Also, if two internal applications break, we fix them minutes later..or maybe fix them earlier to not rely on this option that no one in the foreseeable future can or will change.

In any case, if you feel that removing code that you might have to add again in the future is undesirable, keep it, default it to auth, but remove it from the docs / public interface. Then as time passes, if it seems like this really is never going to change, you can excise it without backward-compatibility concerns. Then the public api is clean, which was my nit in the first place, but you're still in a position to officially add it back in with almost zero effort because you didn't remove the meat of the logic.

Adam Holmberg
June 15, 2016, 1:11 AM
Greg Bestland
June 16, 2016, 4:34 AM

+1 LGTM,

Updated test to use default values here.

Moving this to done.





Sandeep Tamhankar

Fix versions



PM Priority


External issue ID


Doc Impact






Pull Request



Affects versions