I have a very simple Jabber client, which connects to Google Talk via our "Google Apps" domain account. The connect code is as simple as it gets:
jc.User = "chatbot#ourdomain.com";
jc.Server = "ourdomain.com";
jc.Password = "password";
jc.OnMessage += new MessageHandler(jc_OnMessage);
jc.OnDisconnect += jc_OnDisconnect;
jc.OnConnect += jc_OnConnect;
jc.Connect();
This has been running fine for a couple of years, but today it's suddenly stopped working: after the Connect(), I get the exception
A first chance exception of type 'netlib.Dns.DnsException' occurred in
netlib.Dns.dll
Additional information: DNS query fails
followed by
A first chance exception of type 'System.FormatException' occurred in
System.dll
Additional information: An invalid IP address was specified.
I know that Google have indicated that XMPP support is perhaps going away, but I can still connect to the account in question using a "proper" XMPP client.
I've tried changing the Server property to different settings, including:
xmpp-server.l.google.com
alt1.xmpp-server.l.google.com
talk.google.com
but all give the same result.
Does anyone know why this error is suddenly biting me, and what I can do to resolve it?
After literally hours of fiddling around, I've figured out that changing
jc.User = "chatbot#ourdomain.com";
to
jc.User = "chatbot";
solves the issue. Quite why it's worked for years, and has now suddenly stopped, is beyond me - I guess Google flipped a switch somewhere. Problem solved anyway, hopefully this will help someone else.
Related
I have setup the IBM Websphere MQ in my localhost pc and follow the tutorial from here and here
When i run the code it always give me the same error.
Error 2035 : MQRC_NOT_AUTHORIZED
when it reach this line ;
MQQueueManager queueManager = new MQQueueManager("QM_TEST", props);
I already set the MCA UserID in the server-connection channel : mqm and use it in my code
props.Add(MQC.USER_ID_PROPERTY, "mqm");
And from what i read on the internet when we set MCA UserID it should override
what is provided by client.But still the problem occurred.
Not sure if it related, but Im using Websphere Version: 7.5.0.2 and Windows 10 Pro.
Thank you in advance
props.Add(MQC.USER_ID_PROPERTY, "mqm");
Bad idea, absolutely not recommended. That UserId is for the exclusive use of MQ and NOT applications.
ALTER QMGR CHLAUTH(DISABLED)
Really, really bad and stupid idea. You are disabling security in MQ. So, you just want anybody or hackers to get whatever they want from your messaging system.
Solved the issue by disabling chanel authentication
ALTER QMGR CHLAUTH(DISABLED)
since yesterday evening i've a problem with my "express-checkout API"
Every time if I called the uri
https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_express-checkout&token=EC-0W349......
I get the error
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster#paypal.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Yesterday in the morning everything was ok and since I didn't change anything also nothing on the API class.
My Server support the sha256 and the protocol Tls12.
I've nothing in the Logfile from server.
The Live environment works fine but the sandbox environment doesn't work since yesterday.
Is it an error on paypal site or on my side?
I've send also a mail to paypal but I get an autoresponse Message.
Please help me and sry for my bad english.
Thanks and best regards.
This may be related to the recent sandbox downtime over the past 24 hours or so. The problem was diagnosed by the team and they were able to repair the problem. Can you check again to see if it's working now please?
I've seen loads post on this forum about exchange API, but I've never found something like I have.
I' m trying to connect to Exchange using Exchange API in order to get all room's meetings.
My problem : Sometimes, it's working, I can connect and get all my informations. And 5m later, impossible to connect. I got Unauthorized.
It's not an error on code because it's working, I think it's a problem with exchange server, but I really don't know what it is...
On the next picture, there are traces.
On the left, when it's working, And the same 30m later (same identification, same room) which is not working.
http://hpics.li/2d9b216
If you have any ideas ? I really don't know what to do.
thanks (and sorry for my english !)
I notice that the working request comes from server A (look at the value of X-FEServer header), and the failing one comes from server B. Perhaps there is a configuration problem on server B.
thx for this.
I've done some tests : I've modified my host file in my computer. when the url is pointing to serveur A, it's working. When it's on the other server, not working. It's the same configuration on both, cannot find what's wrong. So I will conserve my actual host file (pointing always on serveur A).
Based on an example I found, http://weblog.west-wind.com/posts/2013/Sep/04/SelfHosting-SignalR-in-a-Windows-Service, I'm implementing a SignalR host server within a Windows Service.
It all works fine but if I try:
SignalR = WebApp.Start<SignalRStartup>("http://*:8080/");
I get an unhandled exception of type `
'System.UriFormatException'` occurred in System.dll
Additional information: Invalid URI: The hostname could not be parsed.
It works fine if I use
SignalR = WebApp.Start<SignalRStartup>("http://localhost:8080/");
Probably a dumb assumption but based on the article I took this from, I assumed the *:8080 syntax would work. My question is, have I missed something or was the article incorrect and this format won't work?
So, the + does work... (and yes, I feel dumb) During my testing I think only 1/2 the time I remembered to run as administrator, which lead to bad test results since it was failing because of trying to open the port, and not because of the address.
I got clued into this by reading the Owin/Katana source code linked by #DigitalD. Turns out that not only does it support the + syntax, there is a comment from the code saying it's assuming it...
http://katanaproject.codeplex.com/SourceControl/latest#src/Microsoft.Owin.Host.HttpListener/OwinHttpListener.cs
// Assume http(s)://+:9090/BasePath/, including the first path slash. May be empty. Must end with a slash.
Have you tried removing the port number from the URI?
try
http://localhost instead of http://localhost:8080
I had a C# application that communicates with a database using Linq to SQL and was working just fine when I last tested it a month ago. However, it is now throwing the following exception:
A first chance exception of type 'System.Data.SqlClient.SqlException' occurred in System.Data.dll
------ Exception ------
Error: A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 0 - The received certificate has expired.)
I am digitally signing the code with a Verisign key, but it has not expired. I don't digitally sign until I build the installer, and this is occurring on my dev system in debug, so the code had not been signed.
It is also happening on other systems where the software was signed and installed. These systems access the same test database as I use on my dev system, and were working previously.
The line of code that causes the error follows:
List<req> results = new List<req>();
using (var db = new MyDbDataContext(connectionString))
{
var query =
from item in db.reqs
where item.senddate == null
select item;
results = query.ToList();
}
The error happens when I call results = query.ToList();.
I use the following connection string:
Data Source=<removed>;Initial Catalog=<removed>;UID=sa;PWD=<removed>;Encrypt=true;Integrated Security=false
I am able to connect if I set Encrypt=false, but that is not a viable solution.
Again, this worked just fine the last time I tested it a couple weeks ago. Any insights as to what might be happening would be greatly appreciated.
I managed to find a solution from this post.
Basically, I added TrustServerCertificate=True to my connection text, and everything started working again. I'm not sure why it stopped working in the first place, and if anyone knows if this will be a permanent solution or not, I would love to find out more about what happened.
Thank you to Carson63000 and Jacco for the suggestions.