Tests

[Lukasa]

As with requests-ntlm, we need to work out how to test this functionality. This is kind of a huge pain in the neck, because ideally we'd want some kind of Kerberos-enabled server to bounce these requests off.

My ideal solution would be a single dyno (aka. free) Heroku app, but my suspicion is that it's probably a huge pain to sort that out, so we might need to do something else.

@sigmavirus24, thoughts?

[sigmavirus24]

The single dyno Heroku App would work fine. I just need to see if I can implement a server with pyKerberos.

[Lukasa]

So, while you're doing that, I'm going to try to set up a CentOS VM running a Kerberos daemon so I can test off that. I'll try to make it easy to point the tests elsewhere for the future.

[sigmavirus24]

I'm going to rescind my conjecture that deploying to Heroku should be possible until I'm certain they have some version of Kerberos installed so that the kerberos module will work without error. We might also be able to set up our own server via Flask for testing similar to how requests-ntlm is designing tests.

[Lukasa]

Yeah, that might work. Still requires that any tester has a suitable Kerberos install though, doesn't it?

[sigmavirus24]

Yeah, but to run the client-side tests on their side they need it anyway, so if they're going to need it for that, they'll already have it to run the flask server.

The kerberos package on PyPI just wraps the kerberos API for C. (I considered it for a work project this summer.)

[Lukasa]

Ah, cool.

[sigmavirus24]

And this is what I get for writing that after driving for ~6 hours, so now I'm not entirely sure if my half-asleep self was entirely correct. As I'm still on the road, I don't have a chance to look into it, but I will more in the coming weeks. It may still be easiest to try this avenue, but setting up an EC2 instance may work just as well. I would have to check if Heroku even has Kerberos available.

[sigmavirus24]

And from what I can tell, Heroku doesn't come with Kerberos. An EC2 instance would be easy to run the server (if we need one) from since we'd be able to manage our own installation. I still have to look into running it locally.

[Lukasa]

Yeah, it was a bit of a pipe dream that we could get Heroku to do this for us. I'm going to keep looking into getting a VHD set up that we can pass around that will at least allow local testing.

[Lukasa]

@sigmavirus24 Ok, so I think I've got a decent CentOS VM set up for Kerberos testing on my local box. Do you have a Flask app that uses Kerberos written already?

[sigmavirus24]

I haven't had consistent or reliable internet and don't have kerberos installed on my machine yet so no. But I should in a few days. Sorry for the delay

[Lukasa]

No worries man. =) Was just enquiring.

[sigmavirus24]

So I stalled on this personally. I've been busy with finals and the like, but I'm going to start researching this again. I'm also going to look into an EC2 instance. I think it's possible to get one for free for a year or so, but I don't recall what the qualifiers are for that.

[Lukasa]

Join the club. VirtualBox kept clobbering my Win8 registry (stupid Windows 8), so I've called a halt to that. Might run a VM on my Mac Mini instead and just bridge it through to my local network.

Free EC2 instance: yes, sort of. You need a new account though. I might have most of my free year left though if that helps.

[sigmavirus24]

I don't have an account at all. (Never used EC2 so I would have a free year starting whenever.) I just want to make sure I don't waste any more than a day of that year setting up the box with kerberos, so I'm going to use local VMs first.

[sigmavirus24]

@roguelynn, no chance of Red Had volunteering a test server for this, is there? :-P

[sigmavirus24]

How about mock testing?

[roguelynn]

You should use my other github, econchick.

Happy to test.

Sent from my cloud device.
On Jan 5, 2013 1:44 PM, "Ian Cordasco" notifications@github.com wrote:

How about mock testing?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-11920398.

[sigmavirus24]

Derp yes. I'm too used to Twitter. But I think we might be able to resolve this with the mock library, so it might be unnecessary. I'll let you know though. Thanks!

[mkomitee]

So I started playing around with generating a test suite using mocks. I haven't done much with python testing or mocks before and I don't want to go too far with something that won't be of any real value, so if someone has a chance to take a peek at https://github.com/mkomitee/requests-kerberos/blob/master/test_requests_kerberos.py and let me know if I'm wasting my time, please do. I'm open to any and all comments.

[sigmavirus24]

It looks like you're doing fine @mkomitee. My only word of warning is that in the past, the patch decorator hides tests when using the standard unittest library. You can patch like Michael explains in the documentation for starting the patches in the setUp method and stopping them in the tearDown method. An example is here. You don't need to do it in the setUp/tearDown methods. Since that looks like a one-time deal, you can do it in the test itself.

[mkomitee]

Thanks for the warning, but as to the solution I'm not sure I follow.

This doesn't work:

def test_generate_request_header(self):
    mockInit = mock.patch.object(kerberos.authGSSClientInit, clientInitComplete)
    mockStep = mock.patch.object(kerberos.authGSSClientStep, clientStepContinue)
    mockResponse = mock.patch.object(kerberos.authGSSClientResponse, clientResponse)
    *SNIP*
    mockResponse.stop()
    mockStep.stop()
    mockInit.stop()

... where clientInitComplete, clientStepComplete, and clientResponse are my mock.Mock objects which return my desired values.

The real functions get called.

[sigmavirus24]

You would use it more like

def test_generate_request_header(self):
    mockInit = mock.patch('kerberos.authGSSClientInit', clientInitComplete)
    mockStep = mock.patch('kerberos.authGSSClientStep', clientStepContinue)
    mockResponse = mock.patch('kerberos.authGSSClientResponse', clientResponse)
    init = mockInit.start()
    step = mockStep.start()
    response = mockResponse.start()
    # *SNIP*
    mockResponse.stop()
    mockStep.stop()
    mockInit.stop()

[mkomitee]

Ok. That works -- do you have a link to a bug report or anything for using the decorator syntax? Using this method really clutters up everything and I want to make sure that it's really a problem. In the linked example they were grabbing the result of calling start() on the mock object and using it elsewhere.

[sigmavirus24]

I don't think there is one. I never reported it and expect that I was just
using it wrong. This was also an easier fix than decorating EVERY method on a
test class. As you can see, github3.py has a lot of tests and they're not even
complete.

[mkomitee]

You can use the @patch decorator on the TestCase as well, but just in case you're right, I'm refactoring to use patch.multiple as a contextmanager so it's not as bad and so I don't have to worry about a test raising an exception causing the patch to not be stopped. If I used the same mocks every time I'd do it in setUp and tearDown like github3.py.

def test_generate_request_header(self):
    with patch.multiple('kerberos',
                        authGSSClientInit=clientInitComplete,
                        authGSSClientResponse=clientResponse,
                        authGSSClientStep=clientStepContinue):
        response = requests.Response()
        response.url = "http://www.example.org/"
        response.headers = {'www-authenticate': 'negotiate token'}
        auth = requests_kerberos.HTTPKerberosAuth()
        self.assertEqual(
            auth.generate_request_header(response),
            "Negotiate GSSRESPONSE"
        )
        clientInitComplete.assert_called_with("HTTP@www.example.org")
        clientStepContinue.assert_called_with("CTX", "token")
        clientResponse.assert_called_with("CTX")

[mkomitee]

By the way, thanks for the advice/help.

[sigmavirus24]

Ah, yes patch multiple is glorious. I don't get to use it though. And that looks great too. And you're welcome. Thank you for writing the tests. I wish I had considered using mock and researching the proper headers that are sent back and forth.

[mkomitee]

I deal with kerberos every day, which is why I wrote this to begin with. I didn't realize that I didn't have my email set correctly at work so github didn't associate those commits with my github account so noone could find me.

[mkomitee]

So I have a test suite which passes, but it's all based on some assumptions I have which I haven't been able to test yet, I hope to take some time tomorrow where I have a functional environment to validate my assumptions. Once I've done that, I'll comment the test suite so that the assumptions are documented, and I'll send a pull request.

The original code had some problems with some redirects. Hopefully a test suite will make it easier to debug and fix.

[sigmavirus24]

Here's some 🍰 for you. You're awesome for following this up with tests.

[mkomitee]

FYI, the code in my repo functions in my office's kerberos environment && the tests pass (now with python 2.6, yay RHEL6). I need to add some more tests, but I think we're on our way.

[sigmavirus24]

🤘

[mkomitee]

I've got a significant refactor going which is almost a complete rewrite.

The changes will allow us to follow redirects to other hosts. The current code will cause problems because the kerberos context would be fully complete and bound to a single host. The new code will use a dict to store the contexts.

With authentication mechanisms like basic or NTLMv1 you typically wouldn't want to follow redirects and pass credentials on to the new host because reusable credentials could be extracted from the submitted data, but that's not the case with kerberos so we wouldn't need a separate flag for follow-redirects and follow-redirects-and-forward-credentials as is typically needed with other authentication mechanisms (curl uses --location and --location-trusted).

The test suite is approaching 90% coverage. I'm not submitting this code yet because it's currently dependent on a few changes that we need in requests proper. There's a bug which prevents Authentication mechanisms from submitting requests using all of the user supplied options. (https://github.com/kennethreitz/requests/pull/1190). I'm hoping we can get it accepted so that we can observe user supplied options like stream, etc which currently just won't work with authentication.

[mkomitee]

I just submitted #10 which introduces a test suite.

[mkomitee]

Thar be tests.