In CakePHP 2, MailGun API v3, PHP 7.4, I can initiate an email via a controller action (controller->model->mailgun client->send()) and when I initiate it via CLI/cronshell (CronShell->model->mailgun client->send()) it fails with all of the same parameters passed, with the exception "Mailgun's servers are currently unreachable."
Already checked the API key, general config settings, the domain setting, and it's sending the same email content with same headers to the same recipient... one works, one doesn't. I've also whitelisted the API endpoint IP with the relevant ports in the firewall.
Any nudge would be appreciated!
Related
I'm working on a project which is using PassportJS Google OAuth 2.0. When I test on my local machine (with a React client on localhost:3000 and a Express server on localhost:4000), the flow works fine. I am able to send requests to the server and deserialize the user on each request. However, when I host the client on Google Firebase Hosting and the server on Heroku, the user no longer get deserialized on each request.
Here are some specifics of the things I've done / tried / worked locally along with extra information:
The client and server and hosted on different domains.
I am using axios to send the request to the server. In the request, I make sure to set the "withCredentials" property in the options to true to make sure the cookies connected to that domain are sent on each request.
On the server I have CORS enabled for the domain the client is hosted on (as it is currently being hosted on a different domain) and I have "credentials" set to true to allow the credentials to be sent and received.
Please let me know if I've forgotten to include something in the post or if any extra information would be helpful. Thank you in advance.
I don't know if you fix this, but I got the exact same problem, in my case I added sameSite: "none" in my express session setting, it worked.
cookie: {
sameSite: "none", //add this line
...
},
On configured AKS there is docker container with application that is using AAD authentication.
Based on this article there is also configured ingress. API is working well.
When I add to Azure Active Directory application registration reply URL with https prefix I receive error "The reply url specified in the request does not match the reply urls configured for the application". And I see that in browser address line redirect_uri is starting with http.
When I add reply URL that is starting with http, then I receive "Exception: Correlation failed".
What I have tried: Add to ingress.yaml setting ingress.kubernetes.io/force-ssl-redirect: "true"
May be there is some way to force ingress run https instead of http, or there might be some AAD redirect configuration? Any ideas?
UPDATE 2: Probably http redirect is because of ADAL.
PS: Was able to find similar topic without an answer
UPDATE3:
I have decided not to use nginx as ingress. Instead I am using now Load balancer. Soon it would be possible to use Azure Application Gateway Ingress Controller
Have you tried this?
By default the controller redirects HTTP clients to the HTTPS port 443 using a 308 Permanent Redirect response if TLS is enabled for that Ingress.
This can be disabled globally using ssl-redirect: "false" in the NGINX config map, or per-Ingress with the nginx.ingress.kubernetes.io/ssl-redirect: "false" annotation in the particular resource.
More information on this on the Ingress documentation link.
You have to make a decision whether to use HTTPS or not. If this is just the start of a development cycle, start without it and get auth to work - but implement HTTPS as soon as possible.
AAD supports both http and https, but of course, the reply urls must be added to the application registration respectively.
As #mihail-stancescu says, ssl-redirect must be set to false, if you choose not to use HTTPS. In addition to this, you also have to ensure that your app does not make the redirect from HTTP to HTTPS.
Using curl with -L -k and -v options will give you a lot of information on what is actually happening with your requests.
When the http/https thing is solved, you have to remove any rewrite annotations you have in your ingress. (e.g. ingress.kubernetes.io/rewrite-target: / should be removed).
Now, if your ingress path to the service in question is e.g. /myservice, then the reply-url should also have that part of the path added ([host]/myservice/signin-oidc) - both in the AAD application registration and in the configuration of your app. (The path in the config should not contain the host)
If you are using https, then you must also have a proper certificate. You can use the free LetsEncrypt (https://letsencrypt.org/) in conjunction with KubeLego (https://github.com/jetstack/kube-lego), where you can find some nice examples on how to implement it.
SOLVED: For other people having this error, please check this:
I configured my endpoint/reply address as http:// whilst my app was running https://.. After changing it to https things worked as expected and I could login on the v2 endpoint as well as query the graph api.
It's also a restriction on the v2 endpoint, so beware of that. It just needs to be in https, see the docs:
Restrictions on redirect URIs
Currently, apps that are registered in the Application Registration Portal are restricted to a limited set of redirect URI values. The redirect URI for web apps and services must begin with the scheme https.
source: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-limitations
I have configured an application via the apps.dev.microsoft.com portal as described in this sample project.
I was running under a different port though, so when I set up the URLs in the app registrations I changed them to match my port number.
Now I'm receiving this error after the flow is trying to connect back to my application.
How can I debug this, or how do I know what is happening?
Additional technical information:
Correlation ID: 145d8f37-7229-4dce-8ace-c777e4aeef94
Timestamp: 2017-11-02 08:41:21Z
AADSTS50011: The reply address 'http://localhost:60761/signin-oidc'
does not match the reply addresses configured for the
application: '8b640f9d-e7d8-4c41-8a40-15069f5712ee'.
More details: not specified
I also get the notification that this application will be fed to the Azure AD Portal (app registrations) - but I can't find it there.
I have a dockerised web app deployed on GAE wriiten in Go. The payment module uses stripe checkout API and on success triggers an email notification.
On debugging, I observe that the following line of code is not executed. I have tried port 587 and the result is the same.
err := smtp.SendMail("smtp.gmail.com:465", auth, from, []string{to}, []byte(msg))
I have the same app on my local m/c and this feature works on it. Am not using docker on my local m/c though.
I am using the same user credentials as my GAE account in the 'from' user fields. Could that be the reason that the code fails. Or should the smtp service auth parameters along with the port to be exposed be described in the dockerfile. What would be the correct way to map port 465 or 587 in GAE given that only 4 ports are available?
I am using Golang image 1.7.1
docker logs doesn't show any errors. But the email doesn't get sent.
etc/resolv.conf of the container has the following DNS entries
search c.cloud-devshell-prod.internal. google.internal.
nameserver 169.254.169.254
options: ndots5
Would appreciate any suggestions..
Thanks
Followed instructions on the link
https://cloud.google.com/appengine/docs/flexible/go/sending-emails-with-mailgun
Set up and account with mailgun and got it to work. Mails get sent after running docker.
We are having a web application architecture where our application EAR is deployed in appServer configured with non-ssl Http Port Listener. Every request is routing via F5 Load Balancer-> Web Server-> App Server.
In Load Balancer, we have set an iRule where every Http Request is forwarded to Https set on port 443 and our application is working fine. Now we are trying to implement a SSO using OpenSSO federation solution and SAML Technology. we have deployed the opensso with the non-ssl http listener configuration in our app server.
now when we try to access the opensso using the url xhttp://domain_name/opensso(dummy protocol), it is redirected as per iRule set on the Load Balancer as xhttps://domain_name/opensso. But in the appearing configuration page of opensso, the server URL is populated as xhttp://domain_name only instead of xhttps://domain_name. Likewise, the same approach is followed to populate all the URL properties throughout the opensso configuration. So when I tried to generate the metadata using ssoadm GUI, In the form action attribute the url is formed as 'http' and the request method is passed as 'POST' only as per Opensso convention. But when it is redirected to 'https' as per the Load Balancer Rule the Request method is passed as 'GET' instead of post and the opensso validation fails and throwing the error as 'HTTP Post Protocol is required.
So the issue here is, By default the opensso URL properties should be populated with "https" instead of "http". I would like to know what is the wrong configuration done here. how we could resolve this issue? Thanks.
I think that you will find that the answer actually lies within your application server, not the application itself. You need to indicate to the servlet that it is being proxied, and that it is responsible for creating URLs with the HTTPS scheme, not HTTP.
If you're using Tomcat or a derivative, you can modify the server.xml to include the following:
proxyPort="443"
proxyName="www.domain_name.com"
scheme="https"
secure="true"
You can configure the load balancer to redirect to https with a 307 http status code which informs the client to use the original request method. If POST was the original request method then following the redirect the client will continue to use POST instead of a GET.
HTTP::respond 307 Location "https://[HTTP::host][HTTP::uri]"