I am trying to run my webapp on local before hosting it on Google App Engine. I am trying to set up client credentials for using Google-OAuth. What redirect uri should I provide. I tried using "http://localhost:8000/" as redirect uri but it resulted in OS Error (OSError: [WinError 10048] Only one usage of each socket address (protocol/network address/port) is normally permitted).
are you using the gcloud dev_appserver.py? it sets up an admin console on port 8000, maybe that's what you are colliding with
Related
I am using DefaultCredential to connect to build configuration from azure keyvault.
var secretClient = new SecretClient(new Uri($"https://{keyvaultName}.vault.azure.net/"),
new DefaultAzureCredential(true)
);
IConfigurationRoot configuration = null;
configuration = new ConfigurationBuilder().AddJsonFile("appsettings.json")
.AddEnvironmentVariables()
.AddAzureKeyVault(secretClient, new PrefixKeyVaultSecretManager(environment))
.AddUserSecrets<Program>().Build();
This was working earlier but now it is failing with interactive browser authentication.
After selecting account, it is redirecting back to localhost and throwing error ("localhost sent an invalid response")
I am using "Azure.Identity" Version="1.4.1" . I also tried with latest beta package(1.5.0-beta.4).
Also Azure.Security.KeyVault.Secrets" Version="4.2.0"
I was getting a similar error from a Windows app using interactive AzureAD authentication. It turned out to be the result of the localhost domain appearing in my Edge (and Chrome) HSTS policy cache. The Azure AD signin flow was trying to redirect to http://localhost:61425/?code=.... But because I had been developing an unrelated ASP.NET application on my machine that used the HSTS middleware (i.e. called app.UseHsts) my browser was remembering that policy and forcing the AzureAD signin redirect to https://localhost:61425/?code=.... That switch from http to https broke the redirect handling in my Windows app.
The solution was to delete the localhost domain from the browser's list of domain security policies.
In edge, type this in the address bar: edge://net-internals/#hsts
In Chrome: chrome://net-internals/#hsts
See ERR_SSL_PROTOCOL_ERROR for localhost from Visual Studio debug
Check your application's redirect URI at Azure Portal. You can find it under Authentication on your application's page.
Set the redirect URI to https://login.microsoftonline.com/common/oauth2/nativeclient.
More information about redirect URIs: https://learn.microsoft.com/en-us/azure/active-directory/develop/reply-url
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]"