I'm using C# and on my IIS I'm sending smtp messages (using local host)
the server have a SSL certification when people browse to it (https)
I wanted to improve the mail sending that is will be Send with SSL
so I added this lines :
`client.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials;`
`client.UseDefaultCredentials = true;`
`client.EnableSsl = true;`
just after creating the client:
var client = new System.Net.Mail.SmtpClient("127.0.0.1");
and before:
client.DeliveryMethod = SmtpDeliveryMethod.PickupDirectoryFromIis;
but now when I send the mails I get:
"SSL must not be enabled for pickup-directory delivery methods"
Please help :)
you have to set the delivery method to network in your code :
client.DeliveryMethod = SmtpDeliveryMethod.Network;
According to the SendAsync method's MSDN page's Exception section, you'll get SmtpException if "EnableSsl is set to true but the DeliveryMethod property is set to SpecifiedPickupDirectory or PickupDirectoryFromIis". For me the DeliveryMethod is set to Network by default (it's a desktop client though). From the error message it seems that it is specific or IIS pickup for you. Is your software desktop or ASP.NET web app? Tell us more. Are you using Send or SendAsync? The "client.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials;" is redundant, UseDefaultCredentials should do something like that automatically under the hood.
I would like to add an extra bit if #badr slaoui solution doesn't work for you. Check your web.config for <mailSettings>, commenting that solved my issue.
<mailSettings>
<smtp deliveryMethod="SpecifiedPickupDirectory" from="no-reply#global.ca">
<network host="localhost" port="25" />
<specifiedPickupDirectory pickupDirectoryLocation="C:\inetpub\mailroot\Pickup" />
</smtp>
</mailSettings>
Related
i'm trying to call my api flask on postman or on google chrome and i always get this:
POSTMAN :
Could not get any response
There was an error connecting to 192.168.1.178:5000/.
Why this might have happened:
The server couldn't send a response:
Ensure that the backend is working properly
Self-signed SSL certificates are being blocked:
Fix this by turning off 'SSL certificate verification' in Settings > General
Proxy configured incorrectly
Ensure that proxy is configured correctly in Settings > Proxy
Request timeout:
Change request timeout in Settings > General
Google chrome
Ce site est inaccessible
192.168.1.178 a mis trop de temps à répondre.
This looks like an issue with your flask server or could be related to the authentication method or missing data in your request.
What you can do is use the Postman Console to debug your outgoing request to the server.
What you can look for is:
Check the URL (in your case I think it's an IP address) of the request
Check the request method, for eg. 'GET', 'POST' - you might be calling the request with the wrong method.
Check the authentication method and credentials
Check the request body and headers.
And so on.. make sure you fulfill all the requirements of a complete request.
You can also put print statements in your flask server and see if the endpoints are being called (if it's a local server).
I have a web app developed using DJANGO. Everything works well on the DJNAGO testing server. However, I tried to host it on IIS web server and it works only one problem I am having.
I have one form (user input) and I want to allow the users to input wildcard such as SCA80%. The problem is that I get 404 error and it seems that IIS blocks it because the URL contains % sign.
How can I make IIS don't check for the % regardless of the security issue concerns? Is there any simple solution to fix it?
That's how the URL looks like when I send my request with a wildcard:
/pareto/article-description/SAC80%25/?type=failure&is_article_desc=True
If I remove the %25 and I put the entire SAC80RKEU211 everything works. Even if I am on the django developing server the %25 works. But not on IIS.
As far as I know, the IIS has introduced URL filtering rules for security reasons.'%' is blocked by default as part of security reason in URL.
I suggest you could try to use below config setting to allow the '%'.
<system.webServer>
<security>
<requestFiltering allowDoubleEscaping="true">
</requestFiltering>
</security>
</system.webServer>
If this don't solve your issue, please post the details error message and status codes for us to find out the solution.
I solved the problem by encoding the values that I am sending such as % and decoding it so it will replace the value %
I have added AppTransportSecurity key in info.plist , and
added a Subkey called AllowsArbitraryLoads as boolean and set its value to YES as like following image.
But still showing this error:
{Error Domain=kCFErrorDomainCFNetwork Code=-1022 "(null)"},
NSErrorFailingURLKey=http://dtcws.azurewebsites.net/ShowImg.aspx?params=dtc_376_0_True_False_22,
NSLocalizedDescription=The resource could not be loaded because the
App Transport Security policy requires the use of a secure
connection.})
Can anybody help?
Can you add "Exception Domains" under App Transport Security and specify the domains.
The best solution is to use a secure connection (https instead of http) as Apple will begin to reject apps that do not support this in the future, if they haven't begun already. WWDC 2015 session 703, “Privacy and Your App” is a great session to watch if you haven't already.
The good news is that the website you are requesting natively supports https so all you have to do is add an s to the link.
I am using jetty version 7.5.1 .
My webservice works fine with a "http://..." endpoint, but when I change it to "https://..." things go wrong.
Endpoint e = Endpoint.create(webservice);
e.publish("https://localhost:" + serverPort + "/ws/mywebservice);
I get the following error message:
"https protocol based address is not supported".
I've tried using an SslChannelConnector, a SelectChannelConnector and the combination of both.
Connector connector = new SelectChannelConnector();
connector.setPort(59180);
SslContextFactory factory = new SslContextFactory();
factory.setKeyStore("keystore");
factory.setKeyStorePassword("password");
factory.setKeyManagerPassword("password");
factory.setTrustStore("keystore");
factory.setTrustStorePassword("password");
SslSelectChannelConnector sslConnector = new SslSelectChannelConnector(factory);
sslConnector.setPort(443);
sslConnector.setMaxIdleTime(30000);
server.setConnectors(new Connector[]{connector, sslConnector});
I also tried modifying the port in the publish path. But without success.
Could it be that something went wrong with the creation of my keystore file?
Even I put the wrong password though, it does show a different error message, explaining that my password is wrong.
My options are running out. Any ideas?
EDIT: More information:
Servlets work fine with HTTPS now. But the webservices are not. Am I maybe publishing it the wrong way ?
I found several threads on various forums with similar problems. But never found a solution. I would like to write down my solution for future victims:
The publish method only accepts the http protocol. Even if you are publishing for https, this should still be "http://...". On the other hand, you should use the port of your SSL connector.
Endpoint e = Endpoint.create(webservice);
e.publish("http://localhost:443/ws/mywebservice);
Use any other protocol and you will always get the "xxx protocol based address is not supported" exception. See source code.
Note 1: The webservice already works fine at this point. However there is a point of discussion: The generated wsdl file (at https://localhost:443/ws/mywebservice?wsdl) will reference the http://... path. You could argue if the wsdl file is a requirement or just documentation.
Correcting a hostname in a WSDL file is not that hard, but replacing the protocol is harder. The easiest solution is probably to just edit the wsdl file and host the file, which is not very "dynamic" of course.
Alternatively, I solved it by creating a WsdlServlet which replaces the address. On the other hand, it does feel bad to create an entire class just to fix 1 character. :)
Note 2: Another bug in this jetty release, is the authentication. It's impossible to offer the webservice without any authentication. The best thing you can get, after turning off all possible authentication: you will still have to use 'preemptive authentication' and enter a random username and password.
I am getting an error when trying to connect to an Exchange server using the cfexchangeconnection tag. First some code:
<cfexchangeconnection action="open"
server="****"
username="****"
password="****"
connection="myEX"
protocol="https"
port="443">
I know its the right server because it fails when not processing via https. I have tried:
Following all the instructions here http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WSc3ff6d0ea77859461172e0811cbec14f31-7fed.html
Prefixing username with a domain name, adding #domain name, etc and no luck.
The error I get is:
**Access to the Exchange server denied.**
Ensure that the user name and password are correct.
Any ideas
Here's an idea - this is what I needed to do to make my cfexchange connection work. Not entirely sure if it's the same problem. I think I had a 440 error, rather than your 401 error.
I'm using:
https
webdav
forms based auth
Exchange 2007
Coldfusion 8
Windows 2003 servers
Here's the connection string that worked for me. What was keeping my connection from working was the need for the formBasedAuthenticationURL. This is a poorly documented attribute by both Adobe and Microsoft.
<cfexchangeconnection action="open"
username="first.last"
password="mypassword"
mailboxname="myAcctName"
server="my.mail.server"
protocol="https"
connection="sample"
formBasedAuthentication="true"
formBasedAuthenticationURL="https://my.mail.server/owa/auth/owaauth.dll">
<cfexchangecalendar action="get" name="mycal" connection="sample">
<cfexchangefilter name="startTime" from="#theDate#" to="#theEndDate#">
</cfexchangecalendar>
<cfexchangeConnection action="close" connection="sample">
Additional notes:
IIS and WebDAV are enabled on the target Exchange server.
The username and password you're using has the appropriate permissions for
a WebDAV connection. (I'm not the Exchange admin, so I'm not sure what they
are, but I think the account needs to be allowed to connect to OWA. - Please
correct me if I am wrong.)
Optional: (don't use if you don't have to)
IF HTTPS is required, use the appropriate argument.
IF Forms Based Authentication is on in Exchange 2007 (as was my case),
you'll have to work around it using the formBasedAuthenticationURL argument.
Not sure if that's it, but I hope it is!