I have a Silverlight 5 application trying establish a socket connection to a server as follows:
var targetEndpoint = new DnsEndPoint("subdomain.maindomain.com", 443);
var clientSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
var socketAsyncEventArgs = new SocketAsyncEventArgs {RemoteEndPoint = targetEndpoint};
socketAsyncEventArgs.Completed += AsyncConnectCallback;
clientSocket.ConnectAsync(socketAsyncEventArgs);
I have the following clientaccesspolicy.xml file at https://subdomain.maindomain.com/clientaccesspolicy.xml :
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="*" http-methods="*">
<domain uri="https://subdomain.maindomain.com"/>
<domain uri="*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
<socket-resource port="4502" protocol="tcp"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
I am able to run a local instance of the Silverlight application from visual studio and can establish the socket connection, both running in-browser as well as out-of-browser. When I deploy the application, I am still able to connect using the out-of-browser version, but the in-browser version errors out with the following message:
AccessDenied: An attempt was made to access a socket in a way forbidden by its access permissions.
Within my local environment, where I am running from Visual studio, if I create an hosts file entry:
127.0.0.1 myapp.local
and update my localhost in-browser instance (running from VS) to use myapp.local, I can reproduce the same error, which suggests that the error occurs when the root domain is not localhost, regardless of where the application is hosted.
I have checked my firewall and antivirus software's event logs for signs that they could be blocking the connection request, but do not see any evidence of that.
Has anyone else experienced this issue and offer suggestions of what my problem could be?
According to the description of the problem as well as comments and the article "Relaxed Cross-Domain Access Restrictions", I think that most likely, the problem is with access restriction when the application is run in "in-browser" mode.
To verify that your application is run with trusted privileges you can check that property Application.HasElevatedPermissions is true.
Also, try to follow this guide How to: Enable Trusted Applications to Run Inside the Browser
Make sure that your server's firewall does not block "policy server" port 943
If you still unable to connect to server, try to change port that your service work on to some port that in range 4502 to 4534.
For Silverlight, you need a socket policy server in the mix.
See for details http://msdn.microsoft.com/en-us/library/cc645032%28v=vs.95%29.aspx for details.
Related
The organization has a integration service layer built on .NET 4.5.2. It has several WCF services running. One service uses SFTP to connect to SFTP server in the same machine to read and move some files. It uses simple username and password authentication. All works well in the production environments.
I'm trying to debug the solution in Visual Studio 2019 (16.8.6) and having trouble connecting to the SFTP server. It uses Renci SSH.NET v2016.0.0. Upgrading is not an option. I just want to debug it on the development environment.
The development environment (Windows Server 2012 R2) already had OpenSSH installed (OpenSSH_for_Windows_8.9p1, LibreSSL 3.4.3). And I'm running Visual Studio as administrator.
I can connect to the SFTP using the specific user and password in CMD, and in FileZilla. I also created a simple console application and it is also able to connect, navigate to the relevant folder and read the files.
I then created a simple WCF service and a service host and tried to connect, but this fails. It gives the error, "An existing connection was forcibly closed by the remote host", when it tries to connect.
Sample of console app connect code, This one works.
SftpClient _client = new SftpClient(host, u1, password1);
_client.Connect();
This is the code sample from the WCF service.
public string GetSFTPConnection(ConnectionDetails connectionDetails)
{
try
{
SftpClient _client = new SftpClient(connectionDetails.Host, connectionDetails.UserName, connectionDetails.Password);
_client.Connect();
if (_client.IsConnected)
{
return "SFTP Connected Successfully!";
}
return "SFTP Connection Failed!";
}
catch (Exception e)
{
return $"SFT Connection Error# {e}";
}
}
Error:
InnerException = An existing connection was forcibly closed by the remote host
StackTrace = at Renci.SshNet.Session.WaitOnHandle(WaitHandle waitHandle, TimeSpan timeout)
at Renci.SshNet.Session.Connect()
at Renci.SshNet.BaseClient.Connect()
at SFTPServiceNew.Service1.GetSFTPConnection(ConnectionDetails connectionDetails) in C...
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header />
<s:Body>
<GetSFTPConnectionResponse xmlns="http://tempuri.org/">
<GetSFTPConnectionResult>SFT Connection Error# Renci.SshNet.Common.SshConnectionException: An existing connection was forcibly closed by the remote host ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
at Renci.SshNet.Abstractions.SocketAbstraction.Read(Socket socket, Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout)
at Renci.SshNet.Session.SocketRead(Int32 length, Byte[] buffer)
at Renci.SshNet.Session.ReceiveMessage()
at Renci.SshNet.Session.MessageListener()
--- End of inner exception stack trace ---
at Renci.SshNet.Session.WaitOnHandle(WaitHandle waitHandle, TimeSpan timeout)
at Renci.SshNet.Session.Connect()
at Renci.SshNet.BaseClient.Connect()
at SFTPServiceNew.Service1.GetSFTPConnection(ConnectionDetails connectionDetails) in C:...</GetSFTPConnectionResult>
</GetSFTPConnectionResponse>
</s:Body>
</s:Envelope>
It also returns different errors depending on the host.
localhost:
An existing connection was forcibly closed by the remote host
127.0.0.1:
Server response does not contain SSH protocol identification.
Environment IP address (10.xx.xx.xx):
Permission denied (password).
Computer name:
An existing connection was forcibly closed by the remote host
I have a feeling that this could be something to do with how a WCF service and it's host is run in the debug mode. And the user configuration in SSH. But I'm stumped as to how to figure it out. I don't have a lot of experience with WCF services or OpenSSH.
I've also tried to add my user account into OpenSSH using the blow command. But it fails.
mkpasswd -l -u [my_user_account] >> etc\passwd
The system cannot find the path specified.
And there doesn't seem to be any etc\passwd file in the OpenSSH folder either.
Sample WCF service application structure
Sample WCF service when debugging
OpenSSH folder in server
Very grateful if someone can point me in the right direction.
I found out recently that this machine had both OpenSSH and Cerberus running and configured for SFTP. Cerberus had a different set of users defined. I turned off OpenSSH and tried connecting to the Cerberus SFTP in the WCF service and it was successful.
I'm guessing this was due to some kind of conflict between OpenSSH and Cerberus SFTP.
I have the Mosquitto 2.0.5 snap (version 511) running on an Ubuntu Core 18 system. I made no modifications to the configuration, nor pass another configuration to Mosquitto.
On that same system I am running a .NET 5 application, that uses MQTTnet to connect to Mosquitto. I do not pass any credentials to connect to Mosquitto. However, I am unable to connect to Mosquitto 2.0.5, where I was able to connect to Mosquitto 1.6.12 before.
I do know of the increased security of Mosquitto 2.0 (and that is also the reason to upgrade), but the upgrade documentation clearly states that in the default configuration (no listeners) anonymous connections are still possible on localhost:1883. The strange thing is, that it all works when I run Mosquitto 2.0.5 and my application on Windows, but it does not work on Ubuntu Core (the target system).
Mosquitto 2.0.5 is logging the following when I attempt to make the connection:
New connection from 127.0.0.1:57362 on port 1883.
Client <unknown> disconnected, not authorised.
I use the following C# code (using MQTTnet) to make the connection:
var factory = new MqttFactory();
var client = factory.CreateMqttClient();
var builder = new MqttClientOptionsBuilder().
WithTcpServer("localhost", 1883);
client.ConnectAsync(builder.Build(), CancellationToken.None).Wait(MQTTBROKER_TIMEOUT);
Am I not understanding something, am I doing something wrong?
Any help is appreciated.
EDIT: I have been playing around a bit more, and it seems that by default the dynamic security plugin is loaded when using the snap, however I did not find anything in the configuration files about this. I guess that due to this, the authentication fails.
Then the next question arises, how can I find out what the default administrator user and its password are in this situation, as I need those to be able to add groups, clients and roles to the plugin.
So it looks like Mosquitto 2.0.2 and above has had some security changes, just add this to your mosquitto.conf file as it is mentioned here
listener 1883
allow_anonymous true
"System.Net.Sockets.SocketException (0x80004005): An attempt was made to access a socket in a way forbidden by its access permissions"
OK I know this problem has occurred many times before on S.O., but I cannot find a solution. Here is my question: what are possible causes of this.
Points:
Happens irrespective of firewall
Ports are open
Destination is open and connections have been working in the past
Since working connections, no changes to firewalls or virus scanners, can rule those out.
Running as administrative user
Source port is 23876
Destination port is variable, depends on detected client from another source
Windows 8.1
One more point - this error also happened after porting to .NET Core.
The only change is that I am trying to share ports but I can't see the connection between that and the error.The code to connect is
client = new TcpClient();
client.Client.SetSocketOption(
SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);
client.Client.SetSocketOption(SocketOptionLevel.IPv6, SocketOptionName.IPv6Only, 0);
client.Client.Bind(ipLocalEndPoint);
client.Client.Connect(ep);
where the local endpoint is reused.
What are the possible causes of this error? It is happening on every BIND call.
OK this all turned out to be me being incredibly stupid.
What I had done, and forgotten I had done, is establish a TcpListener on the same port, with this code _tcpListener.ExclusiveAddressUse = false; not working as I expected.
I am trying to connect to a remote queue using c#.
I tried many ways to connect to the remote queue but it always fails with common errors like: MQRC_CHANNEL_CONFIG_ERROR or MQRC_HOST_NOT_AVAILABLE.
What I am doing is this:
string channel = "QM_TEST.SVRCONN";
string hostname = "<serverIp>";
string queueName = "QM_TEST";
string port = 1414;
props.Add(MQC.HOST_NAME_PROPERTY, hostname);
props.Add(MQC.CHANNEL_PROPERTY, channel);
props.Add(MQC.PORT_PROPERTY, port );
props.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_MANAGED);
MQQueueManager mqQueue = new MQQueueManager(queueName, props);
I have tried changing this but all failed.
I think that my problem is the server configurations..
can you point me to a full guide to how to configure a server and connect to it with .net?
My problem is connecting to a REMOTE server using .net and not to a local server.
Thank you!
The problem was that the CCSID between the client and the server were different.
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=%2Fcom.ibm.mq.csqzaf.doc%2Fcs12480_.htm
On the client side I had to put
Environment.SetEnvironmentVariable("MQCCSID", "437");
Thats why I got:
MQRC_CHANNEL_CONFIG_ERROR
I'm guessing the problem (or at least a problem) is here:
MQQueue mqQueue = new MQQueueManager(queueName, props);
This should be
queueManager = new MQQueueManager(queueManagerName, properties);
If you have installed the WebSphere MQ client to the default location, there are many sample programs under the following directory:
C:\Program Files (x86)\IBM\WebSphere MQ\tools\dotnet\samples\cs\base\
There are a number of sample programs there for various tasks. If you have the latest V7.1 client installed then you will see the following programs:
SimpleAsyncPut
SimpleClientAutoReconnectGet
SimpleClientAutoReconnectPut
SimpleGet
SimpleMessageProperties
SimplePublish
SimplePut
SimpleReadAhead
SimpleSharingConversation
SimpleSubscribe
SimpleXAGet
SimpleXAPut
There are also WCF and XMS samples.
If you need the client code, please see my response to another SO question here for links.
Update:
Here's the normal diagnostic process.
If the WMQ components were installed by relocating libraries or classes from somewhere else, perform an install using the full vendor-supplied client media. This includes troubleshooting utilities such as trace, dspmqver, etc. It also resolves any library or class mismatch issues.
Use the pre-compiled client programs to test the connection. The amqsputc, amqsgetc and amqsbcgc programs require the MQSERVER environment variable as described here. The Q program from SupportPac MA01 is a separate download but has the advantage of NOT requiring any environment variables, CCDT files or other dependencies.
If the sample programs fail, check the QMgr's error logs at [WMQ install]/qmgrs/[QMgr name]/errors/AMQERR01.LOG for messages. Also check for FDC files and errors in [WMQ install]/errors.
If no errors on the QMgr side, attempt the connection again while using a client-side trace as described here and here.
Most client problems are resolved through installation of the full WMQ client as supplied by IBM. (Conversely that implies most people are installing by grabbing DLL or JAR files.) If the problem persists, error log inspection on the QMgr and client side usually reveals the underlying cause. If these do not work then tracing usually diagnoses the remaining issues.
UPDATE 2:
Per the error messages posted at MQSeries.net, the channel has a security exit set. A security exit is external code that the channel calls out to when starting a channel. There is no way to know what the exit expects or does without having access to the code or docs of the exit. If the exit is written in-house, you'll need to talk to the programmer to figure out what it requires. If the exit is a commercial product then you will need to get the documentation for it.
Alternatively, alter the channel so that SCYEXIT is blank to disable the exit.
The data posted at MQSeries.net was as follows:
MQ9575: DCE Security: failed to get the user's login name.
EXPLANATION:
System call 192.168.50.55 to get the login name of the user running WebSphere
MQ client application process 5 failed with error value -1. This occurred in
security exit function create_cred. The exit will now attempt to open channel
using the DCE default login context.
ACTION:
If you wish to run using the DCE default login context take no action. If you
wish to run using the user's login name as the DCE security exit principal
examine the documentation for the operating system on which you are running MQ
clients and reconfigure the operating system as necessary to allow the
192.168.50.55 call to succeed.
Note that it states the call is failing in the security exit.
I had an XMLDocument loading a document from a server with no problems till, almost randomly, I started getting a connection refused error.
It also doesn't matter what host I put in, whether it's a legit one or unresolvable. It always gives the same result.
Here's the code:
XmlDocument doc = new XmlDocument();
doc.Load("http://doesnotmatterifIresolveornot.com");
And here is the error:
{"No connection could be made because the target machine actively refused it 127.0.0.1:8888"}
I've turned off any applicable firewalls I can find in Win7, but it's weird cause it happened while I was testing it.
Find out why it's trying to go to 127.0.0.1:8888.
My guess is that for some reason, it thinks that's your HTTP proxy. Did you run something like Fiddler recently? Fiddler runs on 8888 and changes your default proxy settings - maybe they got stuck incorrectly?
Look in Control Panel, or in the Internet Explorer settings.
Are you serving your XML document using IIS? If so, you may need to add a mime-type definition to IIS to serve XML files. This article should help with that (if it is indeed the problem).
you may also try the HTTP loader to get a more detailed picture of what the server is responding with (HTTP headers, in particular, could be useful for troubleshooting).
I suspect the primary issue is that you're trying to connect to a socket (server + port) that the server isn't configured to listen on -- that means you'll get this error regardless of whether or not the URL resolves, since the server isn't configured to deal with a socket connection of the sort you're sending it.