Unauthorized Exception on message with https link body

Hi,

We are having some issues on our clients internal domain when connecting to their Exchange 2010. Everything works will untill we try to process a message containing a body with an https link. The issue only occurs when we convert the body to pdf. The generated pdf is correct and contains the https linked image.

However when performing the next call to the IEWSClient object, whether it is a download of another message, setting this message as read/moving it to another mailfolder or even connecting to a different account (with different credentials) on the same mailserver, it always returns an Unauthorized error and keeps on doing so indefinately.

I have tried disposing and recreating the IEWSClient object but the same unauthorized error pops up on every attempt. Only restarting the service solves the issue and everything works fine again untill it tries to process the https message again, after which the server can no longer connect.

When connecting to the mailserver from outside the domain, with the same user credentials, same message and same processing the issue doesn't occur and even when using an
external proxy from inside the domain. Everything points to the https link being blocked by security, but then how is the pdf generated correctly if it cannot be reached.

Any idea on what could be causing this behavior, which is a production stopper. Is there a way to completely reset the EWS client, further then a dispose and recreate, to simulate a service restart?

Best Regards


Hi Johan,

Thank you for contacting Aspose support team.

We have discussed this issue in detail and need further information. Please inform if the firewall is on or off during the testing. Also you may set the firewall off, log the Exchange client activity as mentioned here and provide us the generated log. We will investigate it and provide assistance accordingly.

Hi Muhammad,


The windows firewall was already turned off.

I asked the customer to reproduce the error and they provided me with the attached log.

Best Regards

Hi,


Thank you for sharing the log files. We have forwarded these to our product team via issue id: EMAILNET-35034 and shall update you here once there is some information available about this problem.

Hi Johan,


Our product team is currently investigating this issue but are unable to reproduce the problem for a fix. Could you please share your sample code and test messages with us as soon as possible so that we can test with these and share our feedback with you? If possible, please create a test account on your Exchange 2010 server, place some sample messages in its mailbox and share its credentials with us for our testing. It may help us identify the issue and fix it.

Hi Muhammad,


I will ask our client if it is possible to provide a test account for you. However even with such an account I don’t think you will be able to reproduce the issue. When I connect to their exchange server from outside their internal network I cannot reproduce it either. They claimed they could reproduce it when adding the https address to the restricted sites in IE, but I couldn’t reproduce this on my end.

It seems that adding the domain of the https linked image to the trusted sites section in IE solves the issue, but offcourse only for images linked to that url.

I will try to create a small sample application that can reproduce the issue at the clients end.

Best Regards

Hi,


Thank you for sharing your feedback. We shall wait for your feedback to further test this issue at our end and share the same with our Product team for analysis.

Hi Muhammad,


I attached a small testapplication we used to reproduce the issue on the customers internal network. As you will see in the source I added several checkboxes to exclude certain pieces of code in order to pinpoint the cause of the issue.

It seems the key to reproducing the issue is the line:

doc = new Aspose.Words.Document(ms, loadOptions);
or
doc = new Aspose.Words.Document(Path.Combine(txtFolder.Text, removeInvalidPathChars(message.Subject) + “.html”), loadOptions);

We have tried a lot of different approaches, like saving all messages to disk first and reloading them from disk before further processing, in order to prevent the generation of the pdf to cause the unauthorized issue but without success.

It seems that somehow generating the pdf, when the body contains a https link triggers something in the network security that prevents reconnecting to the exchange server.
The unauthorized exception occurs the first call to the EWSClient object after the generation of the pdf, no matter what call it is and remains until the application is restarted.

Providing access to the exchange server won’t be of much use as we are unable to reproduce the issue when connecting from outside the customers network to the exchange server. Even when using a tunnel.

Do you have any idea what Aspose.Words does when rendering the html body that could cause this kind of behavior?

Best Regards

Hi,

Thank you for providing additional information. I have shared it with the product team for their consideration. We’ll update you here once there is some additional information available in this regard.

Hi,

We have further investigated this issue at our end but could not reproduce the issue at our end by any means. Could you please test the scenario on another computer in the same network and share your feedback with us?

Hi,


We managed to do some further testing on the clients domain and booked some interesting results.

First I saved the message body (with https link) to disk as a html file. Then ran the testapplication and converted this html to pdf using the code in the sample using Aspose.Words. The result was a correct pdf. However if I now try to connect to the exchange server in the same application instance I immediately and indefinately get the unauthorized error, no matter what else I try.

Opening a second instance of the application (even when the first one is still running) and trying to connect to the exchange server with the same credentials works perfectly fine until we convert the body to pdf again.

To us it seems Aspose.Words is triggering something in the windows security that prevents the current application (and not a specific exchange user) from connecting to exchange.

Another strange part is that, even though the first instance cannot connect to exchange, reconverting the html to pdf again works without issues.

We have tested this issue on 3 systems. It was reproducable on both the customers Acceptance and Production environment, both Windows Server 2008R2 64bit Enterprise, but it was not reproducable on a Win7 client system in the same domain.

Do you have any suggestion what security setting on the servers could be responsible for this behavior? As explained before, adding all the https links to the IE Trusted Sites works as a temporary workaround.

Best Regards

Hi,

Thank you for sharing the additional details.

Rendering to PDF using Aspose.Words requires access to Windows default Fonts folder. Could you please check if the website has been deployed on IIS server and it has access to read-permissions of the Fonts folder? Meanwhile, we are establishing test environment based on Windows Server 2008 R2 for testing this issue at our end. We’ll soon share our findings here with you.

Hi,

We have further tested this issue on Windows Server 2008R2 and were not able to reproduce the problem at our end. The following sample code was tested that accessed a sample message having “https://www.google.com” in body from the test Office365 account, converted it to PDF using Aspose.Words, and then again listed the messages from the same account. It didn’t raise any such problem as you have mentioned. Though we have tried it with HTML body as well, the correct way of converting emails is to convert them to MHTML rather than HTML Another possibility may be any antivirus installed on your test machine that may be playing its part in raising this issue. Or it may be that as suggested above, there is some permissions issue for the font-directory access.

Sample Code:

IEWSClient client = EWSClient.GetEWSClient("https://outlook.office365.com/ews/exchange.asmx", "UserOne@AsposeDec2015.onmicrosoft.com", "Aspose1234");

ExchangeMessageInfoCollection msgsColl = client.ListMessages(client.MailboxInfo.InboxUri);

foreach (ExchangeMessageInfo msgInfo in msgsColl)

{

MailMessage msg = client.FetchMessage(msgInfo.UniqueUri);

//save as MHTML

msg.Save("output.mhtml", Aspose.Email.Mail.SaveOptions.DefaultMhtml);

//now load in Aspose.Words for conversion to Pdf

Aspose.Words.Document doc = new Aspose.Words.Document("output.mhtml");

doc.Save("Output.pdf", Aspose.Words.SaveFormat.Pdf);

}

Console.WriteLine(client.ListMessages(client.MailboxInfo.InboxUri));

The issues you have found earlier (filed as ) have been fixed in this update. This message was posted using BugNotificationTool from Downloads module by MuzammilKhan