rmbolger
Occasional 403 error in HighestVer.ps1
Every so often we get 403 errors from HighestVer.ps1 on line 24:
https://github.com/rmbolger/Posh-IBWAPI/blob/main/Posh-IBWAPI/Private/HighestVer.ps1#L24
I would say 95% of the time this works flawlessly, but every so often we get a 403 back and usually keep receiving for a certain period of time, then the error appears to clear. Not sure if the module is causing the https connection limit to be hit?
https://docs.infoblox.com/space/nios90/280855837/set+connection_limit
In this case, the Posh-IBWAPI module is being used in a workflow and these are often kicked off in succession (5 or 6 seconds in between). Each workflow run creates one connection to IB using Set-IBConfig and the connection is terminated when the container stops. However, in this case, there were six workflows prior to the errors starting, then one was successful and then one immediately after failed. There is nothing in the IB logs indicating the limit has been reached...
I believe there may be an LB in front of our IB appliances so were checking there as well.
Hey @roadbikemike, thanks for reaching out. This is a fascinatingly odd issue. The 403 error seems like it would be Infoblox explicitly rejecting the request instead of a potential load balancer sitting in front of it. The question is why.
Assuming you're on an Infoblox version that supports the _schema option in GET requests (basically anything 2018 or newer), that function only makes a single call to the WAPI to check the version. So it would be surprising if it was triggering rate limiting. And even if it were, I would've thought the rate limited response would be a 429 error rather than 403.
Are all of the workflows running with the same Infoblox credentials by chance? And does the group that user is a member of happen to have the Disable Concurrent Login option enabled or inherited? That's the only thing I can think of that might make sense if the workflows are running either in parallel or close enough together that WAPI might not consider the previous session done before the next one starts.
You could also take the _schema call out of the equation by explicitly setting a WAPI version in the Set-IBConfig call instead of using "latest". Plausibly it would still fail, but on whatever the next call being made would've been.
Hey @rmbolger. I completely agree, the endpoint service (IB) would likely have to be returning the 403 and not the LB itself. As for our IB version, were on Version: 9.0.3-50212-ee11d5834df which was recently upgraded a few months ago. So, that should not be an issue.
Yes, the workflow is using the same credential for each call. Disabling Multiple Login Sessions is interesting and going to pass that along to the team that supports IB. You may be on to something there.
At this point, I have a feeling this is an IB issue and not a Posh-IBWAPI issue. I do appreciate your prompt reply though and thoughts on the issue. Once we get this figured out, I will update this thread for awareness
If you can reliably reproduce it, you might also be able to work with your IB team to enable and monitor debug logs during the event to potentially get more context or at least proof that IB is doing the rejecting.
I've also had inexplicable auth issues in the past with automation accounts until I realized I had enabled the feature that restricts use from certain source IP ranges and the automation process had changed source networks. But unless your workflows are running from different places, that wouldn't explain the sporadic nature of this problem.
Wanted to get back to you with an update...
We ended up opening a case with IB on this issue and enabling appliance debug as you suggested. Unfortunately, this did not show us much. We could see the successful logins, but no trace of the failed logins or evidence of the 403 errors. Since these requests are originating from VMware Orchestrator workflows (WF's), wrote Python based WF's which call the IB API directly. In the course of testing this, I was able to create 100 IP's in a network back to back without a single 403. Likewise, I was able to delete these 100 IP's using Python, again without a failure. The Python based WF's for both Create and Delete follows these calls to somewhat replicate what the PS module does:
Create:
- Get supported versions (
/wapi/v1.1/?_schema&_return_as_object=1) - Create the host record (
/wapi/v2.13.1/record:host) - Lookup the host record to validate (
/wapi/v2.13.1/record:host?_paging=1&_return_as_object=1&_max_results=1&name=hostname)
Delete:
- Lookup the host record to validate (
/wapi/v2.13.1/record:host?_paging=1&_return_as_object=1&_max_results=1&name=hostname) - Get the object _ref
- Delete the host record
(/wapi/v2.13.1/record:host/ZG5zLmhvc3QkLl9kZWZhdWx0LmlvLnRrdG0uYW1zLnRlc3Rob3N0LTY:testhost-6.ams.tktm.io/default)
Since VMware Orchestrator WF's use Linux containers under the covers, I wonder if somehow Set-IBConfig is not getting set properly. If I spit out Get-IBConfig, the data all seems to be there. Running out of ideas at this point, but something with the PS module definitely seems to be the root cause especially when many many calls using Python do not experience this issue.
Ran some more tests this morning, this time with PowerShell and direct Invoke-RestMethod calls similar to the Python tests. Again, no issues with 403's while creating in excess of 100 host records. What's interesting is my cleanup workflow is still using the module and shortly after starting, 403's begin to surface (not all the time, but most of the time). So not sure if any of this helps, but again, I am leaning more on something with the module and perhaps being ran in a Linux container.
Even more interesting is if the module puts me in to a 403 state, even direct calls to the API return a 403 (but never initiate the 403) for a period of time. If I give it a minute or so, then start the direct call to remove the test IP's the request goes through without issue. Thinking the appliance blocks the client IP for a period of time because the module is passing something it does not like. So once that period of time expires, the direct API calls have no issue. Again, the direct calls never throw a 403, only the module.
Definitely a strange issue...
Hey, thanks for the follow up. Quick question about the implementation details of your tests. Following the first call which uses Basic Auth, are you saving and re-using the session cookie for subsequent calls?
I only ask because the module does this under the hood on your behalf. But with raw REST calls at least in PowerShell (not sure about python), it's not automatic. You have to use the -SessionVariable parameter to save the session and then the -WebSession parameter in subsequent calls with the saved session variable. Theoretically, it makes subsequent calls more efficient because Infoblox doesn't treat each one as a new session and the Basic Auth header also isn't sent in every request.
This is just a wild guess of a theory. But it's the first thing that popped into my head about what might be different between how the module calls WAPI and how your manual tests might be calling WAPI. Unfortunately, I don't think I built-in a way to turn off session re-use in the module. But you could sort of fake it by force re-importing the module before each call (which would wipe the internal session tracker memory). So something like this:
Set-IBConfig <call 1>
Import-Module Posh-IBWAPI -Force
New-IBObject <call 2>
Import-Module Posh-IBWAPI -Force
Get-IBObject <call 3>
Let me give your suggestion a go with the module. For the Invoke-RestMethod calls I was making it was super simple in a loop. The function Handler($context, $inputs) is part of the VMware Aria workflow instantiation for PowerShell. Will get back to you on the test results you suggested. Thank you!
function Handler($context, $inputs) {
$infobloxWapiHost = 'infoblox.appliance.url'
$infobloxWapiVersion = '2.13.1'
$username = $inputs.InfobloxUser
$password = $inputs.InfobloxPassword | ConvertTo-SecureString -AsPlainText -Force
$credential = [PSCredential]::New($username,$password)
$schema_endpoint = "https://{0}/wapi/v1.1/?_schema&_return_as_object=1" -f $infobloxWapiHost
$host_record_endpoint = "https://{0}/wapi/v{1}/record:host" -f $infobloxWapiHost, $infobloxWapiVersion
$host_endpoint = "https://{0}/wapi/v{1}/record:host?_paging=1&_return_as_object=1&_max_results=1&name=" -f $infobloxWapiHost, $infobloxWapiVersion
0..100 | %{
$newHostName = "testhost-{0}.ams.tktm.io" -f $_
# Get Schema
$schemaParms = @{
Uri = $schema_endpoint
Method = "Get"
Credential = $credential
SkipCertificateCheck = $true
Headers = @{"Content-Type" = "application/json"}
}
$schemaResult = Invoke-RestMethod @schemaParms
#Write-Host $schemaResult.result.supported_versions
# Create new record
$newHostAddress = @{
name = $newHostName
ipv4addrs = @(
@{
ipv4addr = 'func:nextavailableip:10.73.200.0/23'
mac = Generate-RandomMacAddress
configure_for_dhcp = $true
}
)
} | ConvertTo-Json -Depth 10
$newipParms = @{
Uri = $host_record_endpoint
Method = "Post"
Body = $newHostAddress
Credential = $credential
SkipCertificateCheck = $true
Headers = @{"Content-Type" = "application/json"}
}
Write-Host $newipParms
$newipResult = Invoke-RestMethod @newipParms
Write-Host $newipResult
# Get created record
$getipParms = @{
Uri = "{0}{1}" -f $host_endpoint, $newHostName
Method = "Get"
Credential = $credential
SkipCertificateCheck = $true
Headers = @{"Content-Type" = "application/json"}
}
$getipResult = Invoke-RestMethod @getipParms
Write-Host $getipResult.result
}
}
function Generate-RandomMacAddress {
$mac = ""
for ($i = 1; $i -le 6; $i++) {
$octet = Get-Random -Minimum 0 -Maximum 255
$mac += "{0:X2}" -f $octet
if ($i -lt 6) {
$mac += "-"
}
}
return $mac
}
Still getting 403's with your suggestion of re-running Import-Module Posh-IBWAPI as part of the test loop. I also tried Remove-IBConfig before re-importing.
function Handler($context, $inputs) {
Import-Module Posh-IBWAPI -Force
$username = $inputs.InfobloxUser
$password = $inputs.InfobloxPassword | ConvertTo-SecureString -AsPlainText -Force
$credential = [PSCredential]::New($username,$password)
1..50 | %{
Set-IBConfig -ProfileName 'tmgrid' -WAPIHost 'infoblox.appliance.url' -WAPIVersion 'latest' -Credential $credential -SkipCertificateCheck
$newHostName = ("testhost-{0}.ams.tktm.io" -f $_)
Write-Host "Creating host record $($newHostName)"
$newHostAddress = @{
name = $newHostName
ipv4addrs = @( @{
#ipv4addr = 'func:nextavailableip:10.73.221.0/24'
ipv4addr = 'func:nextavailableip:10.73.200.0/23'
mac = Generate-RandomMacAddress
configure_for_dhcp = $true
} )
comment = 'Created by VMware 403 Orchestrator testing'
}
$returnrec = $newHostAddress | New-IBObject -type record:host -ReturnField ipv4addrs -ErrorAction Stop
Remove-IBConfig
Import-Module Posh-IBWAPI -Force
}
#Start-Sleep -Seconds 1
}
function Generate-RandomMacAddress {
$mac = ""
for ($i = 1; $i -le 6; $i++) {
$octet = Get-Random -Minimum 0 -Maximum 255
$mac += "{0:X2}" -f $octet
if ($i -lt 6) {
$mac += "-"
}
}
return $mac
}
Inside the loop, the New-IBObject call is still using a saved session generated from the Set-IBConfig call. There needs to be another Import call just before New-IBObject.
Here's what I'd do. Move the first Import-Module call from the beginning of the handler to inside the loop just before the Set-IBConfig call. Add another one just before the $returnrec = $newHostAddress | New-IBObject line. The Remove-IBConfig and final Import-Module call at the end of the loop can also probably be removed.
Alternatively, if you change -WAPIVersion 'latest' to something explicit like -WAPIVersion '2.12', the Set-IBConfig call won't need make a REST call to check the version and you can just have a single Import-Module call right before the New-IBObject call.
Making some progress here and was able to replicate the 403 error! This was enough to do it below. Host record 0 through 3 created, the fourth failed with a 403. So something is happening with the session either on the IB appliance side or within the code (bug perhaps).
function Handler($context, $inputs) {
$infobloxWapiHost = 'infoblox.appliance.url'
$infobloxWapiVersion = '2.13.1'
$username = $inputs.InfobloxUser
$password = $inputs.InfobloxPassword | ConvertTo-SecureString -AsPlainText -Force
$credential = [PSCredential]::New($username,$password)
$schema_endpoint = "https://{0}/wapi/v1.1/?_schema&_return_as_object=1" -f $infobloxWapiHost
$host_record_endpoint = "https://{0}/wapi/v{1}/record:host" -f $infobloxWapiHost, $infobloxWapiVersion
$host_endpoint = "https://{0}/wapi/v{1}/record:host?_paging=1&_return_as_object=1&_max_results=1&name=" -f $infobloxWapiHost, $infobloxWapiVersion
# Get Schema/Build Session
$schemaParms = @{
Uri = $schema_endpoint
Method = "Get"
Credential = $credential
SkipCertificateCheck = $true
Headers = @{"Content-Type" = "application/json"}
Session = "ibSession"
}
Invoke-RestMethod @schemaParms
0..5 | %{
$newHostName = "testhost-{0}.ams.tktm.io" -f $_
# Create new record
$newHostAddress = @{
name = $newHostName
ipv4addrs = @(
@{
ipv4addr = 'func:nextavailableip:10.73.200.0/23'
mac = Generate-RandomMacAddress
configure_for_dhcp = $true
}
)
} | ConvertTo-Json -Depth 10
$newipParms = @{
Uri = $host_record_endpoint
Method = "Post"
Body = $newHostAddress
WebSession = $ibSession
SkipCertificateCheck = $true
Headers = @{"Content-Type" = "application/json"}
}
Write-Host $newipParms
$newipResult = Invoke-RestMethod @newipParms
Write-Host $newipResult
# Get created record
$getipParms = @{
Uri = "{0}{1}" -f $host_endpoint, $newHostName
Method = "Get"
WebSession = $ibSession
SkipCertificateCheck = $true
Headers = @{"Content-Type" = "application/json"}
}
$getipResult = Invoke-RestMethod @getipParms
Write-Host $getipResult.result
}
}
function Generate-RandomMacAddress {
$mac = ""
for ($i = 1; $i -le 6; $i++) {
$octet = Get-Random -Minimum 0 -Maximum 255
$mac += "{0:X2}" -f $octet
if ($i -lt 6) {
$mac += "-"
}
}
return $mac
}
Sorry for all the noise here, but want to ensure I get my test results over and findings. Taking this back to the very basics, I can get the following below to fail pretty quick. However, the same code from my desktop never fails. Soooo, perhaps this is an issue with either running the code under Linux in a container or something else, but the session is either expiring or the object is getting lost on the workflow side. Going to keep tinkering and see if there is a way to detect this and possibly regenerate the session.
function Handler($context, $inputs) {
$infobloxWapiHost = 'infoblox.appliance.url'
$infobloxWapiVersion = '2.13.1'
$username = $inputs.InfobloxUser
$password = $inputs.InfobloxPassword | ConvertTo-SecureString -AsPlainText -Force
$credential = [PSCredential]::New($username,$password)
$schema_endpoint = "https://{0}/wapi/v1.1/?_schema&_return_as_object=1" -f $infobloxWapiHost
# Get Schema/Build Session
$schemaParms = @{
Uri = $schema_endpoint
Method = "Get"
Credential = $credential
SkipCertificateCheck = $true
Headers = @{"Content-Type" = "application/json"}
Session = "ibSession"
}
Invoke-RestMethod @schemaParms
0..100 | %{
Write-Host "Executing request $_"
$url = "https://infoblox.appliance.url/wapi/v2.13.1/record:host?_paging=1&_return_as_object=1&_max_results=1&name=host.record.name"
Invoke-WebRequest -Uri $url -WebSession $ibSession -SkipCertificateCheck
Write-Host "Completed executing request $_"
}
}
Is the code on your desktop that never fails running in in-box "legacy" Windows PowerShell (powershell.exe) 5.1 or newer PowerShell 7+ (pwsh.exe)? The web cmdlets and underlying .NET HTTP libraries have changed drastically since 5.1. If you can, try to find out what version of pwsh.exe is running in the container and match your desktop to that.
I've personally not seen many differences between running pwsh.exe on Windows versus Linux, but I suppose it's possible there are differences there as well.
*Edit: Nevermind. I think I answered my own question. -SkipCertificateCheck only exists in pwsh.exe. Version matching may still be wise if possible though.
From my desktop for testing, I am using:
Name Value
---- -----
PSVersion 7.5.0
PSEdition Core
GitCommitId 7.5.0
OS Microsoft Windows 10.0.22631
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
The container within VMware is running:
Name Value
---- -----
PSVersion 7.4.3
PSEdition Core
GitCommitId 7.4.3-0-gcb9a9831420e08553f0dee5d91de0c4f5ee0c93a
OS VMware Photon OS/Linux
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
I am continuing to do some digging here. I see the WebSession is not getting lost, nor are the details about the session in the ibapauth cookie.
The other thing I keep going back to is the error code being returned by NIOS. 403 is supposed to effectively be the server saying, "You have valid credentials and I know who you are, but you're not allowed to do what you asked." So if the session were expiring or becoming invalid for whatever reason, 403 seems like the wrong response. I'd expect a 401 which is more like, "What you have asked to do requires credentials which you either haven't provided or are no longer valid. Please try again with valid credentials."
I completely agree, this entire thing is super weird and only seems reproducible via the VMware container using a web session variable. Not using the module and passing BASIC credentials through with every request works flawlessly (although not terribly efficient). I would also expect if IB was returning that 403 there would be some indication in the debug logs, but nothing. From what I understand, IB support really was not able to find anything other than the successful logins which seems odd. That pesky 403 has to be coming from somewhere especially since there is some sort of lockout for a period of time...
Here is my theory on this. When the WebSession is created as part of Set-IBConfig a cookie is returned which contains the following:
2025-06-10 16:07:33.283 -04:00info"Value": "\"client=API,group=ADGROUP-LimitedAccess,ctime=1749586053,timeout=900,mtime=1749586053,ip=1.2.3.4,auth=AD,user=account_name,NBP3b4IGfjJhnvDid+zQAi6R/5PMD+dlNV4\"",
The ip property is presumably the IP address of the machine which initiated the connection to Infoblox. Since our Aria Automation service has three appliances, this request could potentially originate from any three of these for the duration of the workflow run. If the IP address of the initial caller changes (moves to one of the other two appliances), the source IP is now different and the WebSession is now no longer valid (hence the 403). Its still perplexing IB support could not see these being returned though in the logs. Still waiting to hear back from VMware on this theory and how requests within workflows are brokered out. Also seeing if its possible to "lock" the workflow to one appliance vs bouncing around between the three.
This is also why we cannot reproduce the issue in our LAB environment which only has one Aria Automation appliance unlike production which has three appliances.
Any thoughts on adding an optional -Credential parameter and passing the BASIC header with each call as another auth method? During my testing with Invoke-RestMethod I could never get a 403 to return likely because the credentials were passed with each call vs relying on a WebSession object.
Well now that I read your docs closer, I realized all the module calls already have a -Credential option :-) Looks like you have to be a bit more specific with the version and pass the host, but this will likely fix the issue:
Get-IBObject -type record:host -Filter ("name=hostname.domain") -Credential $credential -WAPIHost $ibhost -WAPIVersion "2.13.1" -ReturnFields dns_name -SkipCertificateCheck
Going to do some more testing with this...
Well, that testing blew up my theory. Using the module in this context still gives me a 403 after X amount of requests:
1..100 | %{
$ibparms = @{
Type = "record:host"
Filter = ("name={0}" -f $hostrecord)
WAPIHost = "dns.server.name"
WAPIVersion = "2.13.1"
ReturnFields = "dns_name"
Credential = $credential
SkipCertificateCheck = $true
}
Get-IBObject @ibparms
}
However, this does not fail even after 500+ calls:
$host_endpoint = "https://dns.server.name/wapi/v2.13.1/record:host?_paging=1&_return_as_object=1&_max_results=1&name="
$host_name = "somehost.name"
1..100 | %{
$getipParms = @{
Uri = "{0}{1}" -f $host_endpoint, $host_name
Method = "Get"
Credential = $credential
SkipCertificateCheck = $true
Headers = @{"Content-Type" = "application/json"}
}
$getipResult = Invoke-RestMethod @getipParms
Write-Host $getipResult.result
}
At this point, this is still a mystery but since we know making direct IB calls outside the module resolves the issue, were going to move in that direction. If you can think of anything else that may cause this from a module standpoint, please let me know and I greatly appreciate your help to this point.
Yeah, unfortunately even with an explicit WAPIHost and Credential, Get-IBObject still creates and tries to use a session object under the hood via Invoke-IBWAPI. The session store is keyed off of a combination of the WAPIHost and Username from the credential. It's probably worth adding a switch that explicitly disables trying to use a session in general even outside of this problem.
I totally thought you had something with the theory about the IP in the cookie not matching the source IP of the request. But I tried to simulate it in my lab by essentially cloning the session object to a different machine/IP and had no luck so far.
On machine 1:
# make a valid call and save the session variable
Invoke-IBWAPI -uri 'https://gm.example.com/wapi/v2.12.1/grid' -SessionVariable sv -Credential (Get-IBConfig).Credential -verbose
# display the cookie value to copy to machine 2
$sv.Cookies.GetAllCookies()[0].Value
On machine 2:
# create a new session variable from scratch
$sv = [Microsoft.PowerShell.Commands.WebRequestSession]::new()
$sv.Credentials = [Net.NetworkCredential]::new('myuser','mypassword')
$cookie = [Net.Cookie]::new('ibapauth','<value from machine 1>','/','gm.example.com')
$cookie.HttpOnly = $true
$cookie.Secure = $true
$sv.Cookies.Add($cookie)
# call WAPI from our new session
Invoke-RestMethod -uri 'https://gm.example.com/wapi/v2.12.1/grid' -SessionVariable $sv
But the call from machine 2 worked in my lab. I'm curious if this also works for you. I'm gonna play around with it a bit more as a non-admin user and tweak some of the account specific security settings to see if I can get it reproduced.
I could not get this to work without getting a 401 from the second machine:
Machine 1
$credential = Get-Credential
Set-IBConfig -ProfileName 'grid' -WAPIHost 'internal.mygrid.com' -WAPIVersion 'latest' -Credential $credential -SkipCertificateCheck
Invoke-IBWAPI -uri 'https://internal.mygrid.com/wapi/v2.12.1/grid' -SessionVariable newsess -Credential (Get-IBConfig).Credential -verbose
$newsess.Cookies.GetAllCookies()[0].Value
Machine 2 (or in this case Orchestrator workflow)
$sv = [Microsoft.PowerShell.Commands.WebRequestSession]::new()
$sv.Credentials = [Net.NetworkCredential]::new('service_account','service_password')
$cookie = [Net.Cookie]::new('ibapauth','"group=AD-GROUP,ctime=1750073511,ip=x.x.x.x,auth=AD,client=API,user=service_account,timeout=900,mtime=1750074020,f1cHMobw1QoYAN8BgbR2WxqIqN4yBq2SCWU"','/','internal.mygrid.com')
$cookie.HttpOnly = $true
$cookie.Secure = $true
$sv.Cookies.Add($cookie)
Invoke-RestMethod -uri 'https://internal.mygrid.com/wapi/v2.12.1/grid' -SessionVariable $sv -SkipCertificateCheck
^ returns a 401. I compared the cookie from the first call on Machine 1 to the manually created cookie on Machine 2. They appear identical, but IB did not like this setup in my case on Machine 2.
I agree adding a switch to bypass session variables entirely and explicitly use credentials would definitely be a nice addition... Not sure what the LOE would be on what you already have in place to make that work though. Thinking the switch would completely bypass all the session code and simply force credentials and that would be it.
I should also note I could not get this to work from a single machine either. In other words, generate the cookie value with Invoke-IBWAPI, then create my own WebRequestSession and add that value to [Net.Cookie]::New without getting a 401.
Hi @rmbolger. I received an interesting response from VMware regarding the behavior of containers in Orchestrator:
WebSession may rely on the filesystem to persist some data. Under load new container is spawned which does not have the session data and 403 happens.
While I am relatively certain WebSession does not utilize the filesystem, I am sure this object stores information in memory so the same issue arises. However, if a new container was spun up, presumably it would create its own new WebSession object so not sure this helps us much.
In any case, I am ready to put this issue to bed. Let me know your thoughts on implementing a switch to disable WebSession and pass credentials with every request. In the interim were going to implement direct API calls to Infoblox outside the module as a workaround.
Totally understandable. I'm already working on the option to disable sessions. I'll let you know when I've got something more concrete to test.
Ok, I think I have a functional feature branch to test. It basically adds a Set-IBConfig -NoSession switch which persists in the profile like everything else. When enabled, the various public functions will pass the switch along to Invoke-IBWAPI which has a corresponding -NoSession switch of its own. Any other session related variables will be ignored and no new sessions will be saved.
I'm still debating whether to leave it as only a profile setting or adding the -NoSession flag as a per-call option to all the public functions as well like -SkipCertificateCheck.
This is great! So I am clear, when using -NoSession with Set-IBConfig its not utilizing the WebSession object and passing credentials with each subsequent call? I do not need to use -NoSession anywhere else other than Set-IBObject?
One thing I noticed. The ModuleVersion is still set to 4.1.0 which is the current production version. If its not too much trouble, could we make this 4.1.1 or similar. Also, any chance of kicking out a nupkg file? I need the newpkg file to import in our repo so the VMware Orchestrator environment can pull the module changes in.
Let me do some testing this week and get back to you...
Thank you again!!
Correct (unless I've got a bug in the implementation). Once the config profile has NoSession = $true, none of the public functions should use or save any WebSession with the underlying Invoke-RestMethod calls.
Also, in case you weren't already aware, you can have the module use an implicit profile via environment variables instead of needing to make an explicit call to Set-IBConfig. Sometimes orchestration platforms make it easier to inject secrets via environment variables than directly into the scripts being called. Here's the existing guide on using them.
https://docs.dvolve.net/Posh-IBWAPI/latest/Guides/Stateless-Mode/
The feature branch with -NoSession also supports a IBWAPI_NOSESSION environment variable.
I think I updated my previous comment after you posted yours, but thoughts on incrementing the version (maybe 4.1.1) and kicking out an updated nupkg file for testing? This is pretty much the only way I can get the updated code in to the Orchestrator workflow from our repository. Incrementing the version lets me create another repo item and not step on the current production version.
Sure. I'll try to throw a pre-release version up on PowerShell Gallery later tonight.
Ok, 4.2.0-alpha1 is up on the gallery. If you're using the PowerShellGet module to download it, you'll probably need the -AllowPrerelease switch.
Good news! I was able create and delete several hundred IP's in Infoblox without a single 403....! From what I can tell, this resolves our issue when running inside an Orchestrator container. What if anything do you need from me to push a new version to production? Happy to help where I can and not to be annoying, but thank you again.