Session Authentication in NSX and the Bad XSRF Token

Well, it's been a while since I posted here, but this one was a real head scratcher with ultimately a simple solution, so I figure that I should put it out there!  I've been working with the NSX API lately and wanted to do session based authentication rather than throwing credentials at the system for every operation.  I followed the official guide (as best I could, given that I'm working in PowerShell), so then I followed some really helpful blog posts, and it looked like I had everything right... but I was getting this Bad XSRF Token error that I didn't understand.

I did a bunch of fruitless research before I noticed something.  My $headers variable had the XSRF token enclosed in curly brackets, as it came from the value of a hashtable (as seen in Lorenzo's script here):

$xsrftoken = $response.headers["X-XSRF-TOKEN"]
...
$script:headers.Add("X-XSRF-TOKEN", $xsrftoken)

That didn't look right to me.  I was grasping at straws, so I tried populating my $headers hashtable with the copy-pasted values from that response, which was basically all of the characters without the enclosing curly brackets... and it worked like a champ!  I'm not sure why PowerShell was baking those curly brackets into the string, but it was messing everything up.  My solution to it was a little piece of duct tape:

$script:headers.Add("X-XSRF-TOKEN", "$($response.headers["X-XSRF-TOKEN"])")

Given that the hashtable was already returning a string without curly brackets for the value of the X-XSRF-TOKEN entry, I'm not sure why the original method was populating with them... but throwing that value into a string when adding it to my $headers variable got everything working!


Comments

Post a Comment

Sorry guys, I've been getting a lot of spam recently, so I've had to turn on comment moderation. I'll do my best to moderate them swiftly after they're submitted,

Popular posts from this blog

Clone a Standard vSwitch from one ESXi Host to Another

One of my customers is standardizing the configurations on their HP C7000 enclosures (they've been set up at various sites by various administrators with varying involvement from the architecture team).  As such, we need to stand up some temporary resources so that we can take down the main enclosure for reconfiguration.  That's fine, we can easily ship a smaller enclosure to each site for temporary compute resources.  Some of the sites are using Standard vSwitches, so we need to be able to quickly copy the networking configuration over from their existing blades to these new, slightly different blades.  As I see it, we had 2 good options: 1) Capture a Host Profile with the desired vSwitch configuration.  Delete every other component of the Host Profile so that only the networking section is applied; design the new ESXi hosts so that the vSwitches'll work with the old vmnic-to-vswitch configurations. 2) Write a script to clone the vSwitch from ones ESXi host...
Read more

Orphaned VMDK Files

(8/10/2015)  Update:  Unfortunately, some backend things have changed since I originally cobbled this script together and it doesn't work any more.  I'll fix it if I get the chance, but in the meantime, there's a free utility called  RVTools  that can identify orphaned VMDK files (which are entertainingly called Zombie VMDKs on the vHealth tab of the application).  That's a great application to be aware of anyway, as it makes it very easy to get access to a lot of important information that the vSphere client obscures. (11/9/2015) Update: I went ahead and put together a post detailing how I used RVTools and a helper script to identify, rename and then delete orphaned VMDK files . Every organization has to wrestle with orphaned VMDK files.  What is an orphaned VMDK file, you ask?  It's a VMDK file that's sitting on your SAN, consuming expensive storage, but isn't actually being used by any VM.  They're notoriously hard to find (especially...
Read more

ESXi Syslog to Multiple Servers

 Hey guys - just a quick note today.  I was configuring a second Syslog server for a customer's ESXi via the Syslog.global.logHost advanced setting, but was getting a generic "Internal Error" error whenever I tried to save my configuration.  Some quick googling made it look like this might be related to the scratch directory configuration having a problem or possibly the Syslog.global.logDir setting pointing at a folder that didn't exist, but in this case it was much simpler. When setting up multiple logHosts, the example shows "udp://hostName:514, hostName2, ssl://hostName3:1514" but that's not actually the correct syntax to use.  It should be "udp://hostName:514,hostName2,ssl://hostName3:1514" to get it working.  Note that the servers are separated only by commas, instead of by a comma and a space.
Read more