Powershell and SOAP
Answered
When I run the script below:
==========================
$PSUserCred = Get-Credential
$CerberusFtpSvc = New-WebServiceProxy -Uri "C:\Program Files\Cerberus LLC\Cerberus FTP Server\webadmin\admin\wsdl\Cerberus.wsdl" -Class CerberusFtp -Namespace CerberusFTPService -Credential $PSUserCred
$CerberusFtpSvc.Url = 'http://127.0.0.1:10001/service/cerberusftpservice'
$CerbCreds = New-Object -TypeName CerberusFTPService.Credentials
$CerbCreds.user = $PSUserCred.UserName
$CerbCreds.password = $PSUserCred.GetNetworkCredential().Password
$GetUserListRequest = New-Object -TypeName CerberusFTPService.GetUserListRequest
$GetUserListRequest.credentials = $CerbCreds
$UserList = ($CerberusFtpSvc.GetUserList($GetUserListRequest)).UserList
==========================
I receive the following error:
New-WebServiceProxy : Exception has been thrown by the target of an invocation.
At C:\Script\GetSFTPUsers\GetSFTPUsers.ps1:3 char:19
+ ... rusFtpSvc = New-WebServiceProxy -Uri "C:\Program Files\Cerberus LLC\C ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [New-WebServiceProxy], TargetInvocationException
+ FullyQualifiedErrorId : System.Reflection.TargetInvocationException,Microsoft.PowerShell.Commands.NewWebServiceProxy
The property 'Url' cannot be found on this object. Verify that the property exists and can be set.
At C:\Script\GetSFTPUsers\GetSFTPUsers.ps1:4 char:1
+ $CerberusFtpSvc.Url = 'http://<servername>:10001/service/cerberusftpservice ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : PropertyNotFound
==========================
I confirmed that:
> I am using the admin account, and the creds are correct.
> The path to the WSDL file is correct
> I have use the SOAP Service URL provided by the Remote tab in the latest Cerberus version
I have used the following articles as references:
> https://www.cerberusftp.com/phpBB3/viewtopic.php?f=2&t=3874&p=11496&hilit=powershell#p11496
Any help appreciated,
Thanks.
-
Official comment
The most recent change to Cerberus modified the Cerberus.wsdl file. Near the bottom of the file you'll see a default SOAP service endpoint that reads like this:
<service name="CerberusFTPService">
<port name="CerberusFTPServicePort" binding="tns:CerberusFTPServiceSoapBinding">
<soap12:address location="{{WSDL_PROTOCOL:xml_escape}}://{{WSDL_HOSTNAME:xml_escape}}:{{WSDL_PORT:xml_escape}}/service/cerberusftpservice" />
</port>
</service>When you request (for example) 'https://localhost:8443/wsdl/Cerberus.wsdl', Cerberus FTP Server replaces the fields surrounded by double-braces, {{ FOR_EXAMPLE }}, with the current SOAP service endpoint configuration.
However, you're accessing the file directly, so Cerberus server doesn't have the chance to fill with your current config. In this case, New-WebServiceProxy gets confused by the double-braces and fails to parse the .wsdl file, throwing an exception.
The simplest solution is to use the web admin listener to access the wsdl file. Cerberus will tell New-WebServiceProxy the correct default listener currently configured for your server and you won't need to set $CerberusFtpSvc.Url explicitly in your script.
You might have a good reason not to use the URL, though. Perhaps you're optimizing and want to eliminate the extra request to the server, or your Cerberus FTP Server doesn't have a running Web Administration port, or Web Administration port is inaccessible to your SOAP client due to firewall isolation.
In that case, you will need to make a copy of Cerberus.wsdl and replace the template parameters with the current configuration. Or, if you are setting the $CerberusSvc.url explicitly in your script (as you are), you may remove the <service> element entirely.
Thanks for bringing this to our attention. We made this change to make Cerberus.wsdl appear dynamic as server configuration changed, but we did not anticipate the problem it causes when accessing the file directly. We'll take a closer look at this system and possibly change it in the future.
Finally, please take a look at a recently-released document on our support site, Calling Cerberus SOAP API from PowerShell
-
Hello.
I will see if the development team has any availability to review your script. In the meantime, I would suggest taking a look at a new walkthrough we just posted on PowerShell and SOAP. I think this will help you work out your issue.
https://support.cerberusftp.com/hc/en-us/sections/360001417940-Cerberus-SOAP-API-with-PowerShell
0 -
Thank you Vincent.
The only reason I used the local directory option was because reference the URL in the New-WebServiceProxy returns the following error:
New-WebServiceProxy : The HTML document does not contain Web service discovery information.
In fact, this is the error I am getting in the official HelloCerberus.ps1 script (with the $WSDLUrl variable set to the web address, not the local file address)
I imagine once the sample script (or environment) is configured to work correctly then I would be in a good place to further troubleshoot my own script.
I'm not sure what else to try here? Any further insight would be great.
0 -
Hi Jmurray,
Sorry you're having trouble with your script.
It certainly sounds New-WebServiceProxy is able to reach the URL you're providing it with, but it isn't receiving any WSDL file. I suggest you try opening your Web Administration console in a browser, from the same computer you're doing your scripting from. Click the link for the WSDL file, which is along the left navigation bar (See below):
If that works and you receive an xml file, great! Copy that URL to your script source in the $WSDLUrl variable.
If that doesn't work, then something strange is happening. It's probably best to open a support ticket if this is the case.
You should still be able to make a local copy of Cerberus.wsdl file with the double-brace fixups I mentioned in my earlier post, though, if you're eager to make progress.
0 -
Thank you Vincent!
This helped specify the correct URL and the script works! The difference between what was in the script and what was shown in the web-gui link was very subtle, but significant.
0 -
Great!
I just want to note that I highly recommend testing your scripts in a non-production environment. The SOAP API is quite powerful. Mistakes can be quite... destructive. :-D
-V
0
Please sign in to leave a comment.
Comments
6 comments