Today I took a look again at what it would take to leverage the Zend_Config classes to work with dot nessus files.

I looked at this briefly in the past but was turned off by it because of a couple things. One, the nessus files can have tags which have an arbitrary number of fields in them. This caused problems because the Zend_Config objects that would be created would have arrays of Config objects in them and I wasn't sure of how to access those objects.

For example, the following code will read a value from my Config object

$config->Policy->Preference->uuid</pre>
That's great, but what happens when you have an array? Say Preference was an array of items and you want the 5th one. This won't work
$config->Policy->Preference[5]</pre>
Because those values are objects, not arrays. Likewise, this won't work
$config->Policy->Preference->5</pre>
5, after all, isn't an object. Well, as I came to find out, there are two ways to get it; the odd way, and the method way. First, the odd way
$config->Policy->Preference->{5}</pre>
That's odd to me. I guess the curly braces are an operator of some kind. Now, the method way
$config->Policy->Preference->get(5)</pre>
That's makes more sense to my brain but it took some time reading the documentation to find that functionality. The other quirk that I was spending way too much time working around is re-use of my authentication adapters in nessquik.

See, Zend_Auth only provides singleton access to the Auth class. This is a problem in my application because I use a bit of functionality that I cooked up to proxy credentials around. You log in to nessquik with your credentials, and then the underlying API account will authenticate to the system and basically become you to perform it's duties.

Using a singleton pattern in this case though really sucks because that second authentication (api as you) steps on your initial authentication (you to the system) and all sorts of things go wrong. It turns out that I was just not using the correct classes.

The Zend_Auth class ultimately just wraps around the adapters which themselves do the authentication. The obvious solution was to just call the authenticate method of my adapter. This prevents any credentials from ever being stored; definitely a "hand to head" moment *bonk*