It seems keeping all the browsers happy is a challenging task, what with all the security they are adding and the complexities of certificates.
I have a SPA (Vuejs) which is using oidc-client.js to implement OIDC, communicating with an Identity Server (Identity Server 4).
First thing to note is that everything works if I run both client and server on localhost.
It is when I deploy the Identity Server to a Staging Server inside our network that things go awry.
So, the hostname of the Idp now differs to that of the SPA (which would be normal in production).
After much work, I've got everything working except IE11 (yep IE).
I had to do several things to get me there such as:
solve the samesite cookie issue of Chrome
create self-signed certificates and install the root certificate in the Trusted Certificates
add Babel config code and Core.js at the client, to enable IE to not throw errors when promises come into play
So, it's been a long road, yet still, I have to deal with this (see animation):
I just can't quite figure out why IE is doing that.
It is not possible to use the dev tools to see any info.
The logs at the server do not contain any information that seems relevant.
Has anyone else seen these "Browser symptoms" in IE.
Happy to provide more information (code, logs etc.) if people think that will help. Just didn't want to dump all that in the initial question, as many people don't like that.
Here are a couple of Fiddler screenshots. The first is from Chrome:
The second on is for IE11.
For some reason, the Silent Refresh is being invoked over and over again with IE11.
I think I can see what is happening, but not sure how to fix it.
There appears to be 2 calls to the Authorize endpoint which fail, conspicuously missing the .AspNetCore.Antiforgery cookie. This results in 2 invocations of silent-refresh.html.
Then, for some reason there is some king of GET request to the base url of the Idp and immediately following on the heels of that request is a request to the Authorize endpoint which does have the .AspNetCore.Antiforgery cookie.
The ship is set straight until the next call to the Authorize endpoint which is the beginning of the next cycle.
However, with Chrome, after the user is logged in, the next call to the Authorize endpoint does contain the cookie.
So, I guess it is the missing cookie which is the issue.
Perhaps this has something to do with the code which I used from this post to solve the Chrome samesite cookie issue?
Cheers
I've a running Django app served on Google App Engine standard under a custom domain: mysite.com.
My site was running pretty well for days but suddenly it stopped serving content using the custom domain.
In summary:
www.mysite.com => works
mysite.com => stopped working
There were no changes in either the DNS nor the app deployment.
What I've tried:
First I checked the DNS lookup for these names:
a) nslookup my-app.appspot.com <== the GAE canonical site name
b) nslookup mysite.com <== custom domain FAILING, ip resolved
c) nslookup www.mysite.com <== custom domain working, ip resolved
d) nslookup ghs.googlehosted.com <== the recommended GAE DNS entry for www subdomain
Surprisingly not only all the names are resolved correctly but also they map to different IP addresses.
Actually, c) and d) map to the same IP (as expected). Anyway its not a DNS problem as stated here.
Second, I checked GAE settings to see the custom domain and tried to add another domain: mysite.com. But it claimed it was already mapped.
Third, according to this answer:
- I deleted the naked domain mapping and re-added later.
Fourth, I've checked documentation and don't find any missing thing in my setup:
https://cloud.google.com/appengine/docs/standard/python/mapping-custom-domains?hl=en#top_of_page
Both naked (mysite.com) and 'www.mysite.com' custom domains were working for days!
The current behavior is a bit weird. Running:
wget mysite.com
Produces:
Connecting to mysite.com (mysite.com)|xxx.yyy.zzz.ddd|:443... connected
Then it hangs for a while and ends with Unable to establish SSL connection.
The same happens using the web browser.
Anyone facing the same problem?
Any help is appreciated.
In case it is useful for someone else:
The problem has gone away suddenly, after an hour or so.
The only change I am aware of is to delete and register again the mysite.com custom domain entry in the GAE Web cloud console.
The naked domain is now working perfectly.
To avoid getting your site offline:
How to be alerted about your site's availability
Enable Stackdriver monitoring by entering into
https://console.cloud.google.com/monitoring
Create an uptime check using your site URL
In Policies: Create an alert policy to be notified by email or app push messages.
I'm trying to write a VSCode extension where users could log into Google AppEngine with a google account, and I need to get their SACSID cookie to make appengine requests.
So I'm opening a browser window at
https://accounts.google.com/ServiceLogin?service=ah&passive=true&continue=https://appengine.google.com/_ah/conflogin%3Fcontinue%3Dhttp://localhost:3000/
(generated by google.appengine.api.users.create_login_url)
The user logs in and is redirected to my local webserver at
localhost:3000/_ah/conflogin/?state={state}
Now I try to forward the request to my AppEngine app (since it knows how to decode the state parameter), so I do a request to
https://my-app.appspot.com/_ah/conflogin/?state={state}
basically just replacing localhost with the actual app.
but it doesn't work, presumably because the domain is different. I assume this is on purpose, for security.
Is there any way I can make this work ?
Not ideal, but the only solution I've found is to have an endpoint on my GAE instance that does the redirection. Then I can set that as the continue url, when I'm starting the authentication process
https://accounts.google.com/ServiceLogin?service=ah&passive=true&continue=https://appengine.google.com/_ah/conflogin%3Fcontinue%3Dhttps://my-app.appspot.com/redirect?to=http://localhost:3000
I think you should center the attention on the protocols you are using, since it’s known that the cookie name is based on the http protocol (HTTP : ACSID, HTTPS:SACSID), and that’s the security perspective till this point for me.
Having the error you are facing now would be helpful to understand the problem better. Also, how are you performing the call to the API and the code you are using would be helpful too.
We've got a website:
www.feeltracker.com
This is running on Google App Engine
On Google App Engine, we have Naked Domain forwarding setup, so that:
http://feeltracker.com
redirects to
http://www.feeltracker.com
However, when we try to open the following address in Chrome:
https://feeltracker.com (notice the HTTPS)
We get a Google error page with the following message:
Google
404. That’s an error.
The requested URL / was not found on this server. That’s all we know.
Does anyone know how we can ensure https://feeltracker.com redirects to www.feeltracker.com?
Note that in Firefox we get the following additional information when trying to open https://feeltracker.com:
feeltracker.com uses an invalid security certificate.
The certificate is only valid for the following names:
*.google.com , *.android.com , *.appengine.google.com , *.cloud.google.com , *.google-analytics.com , *.google.ca , *.google.cl , *.google.co.in , *.google.co.jp , *.google.co.uk , *.google.com.ar , *.google.com.au , *.google.com.br , *.google.com.co , *.google.com.mx , *.google.com.tr , *.google.com.vn , *.google.de , *.google.es , *.google.fr , *.google.hu , *.google.it , *.google.nl , *.google.pl , *.google.pt , *.googleapis.cn , *.googlecommerce.com , *.gstatic.com , *.urchin.com , *.url.google.com , *.youtube-nocookie.com , *.youtube.com , *.youtubeeducation.com , *.ytimg.com , android.com , g.co , goo.gl , google-analytics.com , google.com , googlecommerce.com , urchin.com , youtu.be , youtube.com , youtubeeducation.com
(Error code: ssl_error_bad_cert_domain)
Note that we are using the SNI SSL certificate capability on Google App Engine with our uploaded certificate.
When we run SSL diagnostics via http://www.digicert.com/help/ we get the following:
Certificate does not match name feeltracker.com
Subject *.google.com
Valid from 02/Jul/2013 to 31/Oct/2013
Issuer Google Internet Authority
Subject Google Internet Authority
Valid from 12/Dec/2012 to 31/Dec/2013
Issuer Equifax
Any ideas why https://feeltracker.com fails to use the correct certificate, whereas www.feeltracker.com and http://www.feeltracker.com work as expected with our SSL certificate?
Update 16 Sept 2015
It appears this may now work as per Forum post and Issue 10802
Previously applicable info below...
Currently it's not supported. The naked domain redirect is a workaround only for http and you'll probably notice that specific IP addresses you need to be put in your DNS for that differ from the approach and IP addresses for ghs.googlehosted.com.
This seems to indicate that it's different parts of Google's infrastructure and they haven't yet managed to make them consistent or work together. I haven't seen any details on when they will resolve this so it might be a long wait. e.g. Related post from 2009
There is an "acknowledged" issue for Naked domain support so when that's fixed then likely this issue also resolved.
As Google is not going to correctly serve your certificate on their naked domain redirector then for now there are these options that I see:
Make/provide your own reverse proxy (Apache httpd, varnish etc) or use a reverse proxy service (eg. CloudFlare) and point your naked domain there. You'd install your SSL on the reverse proxy, clients would connect there for your naked domain (no certificate errors) and you'd proxy all traffic to your real site. It might create a single point of failure and costs depending what you use.
Rent a cheap VPS where you install a web server, your cert and a redirect script to https://www.feeltracker.com. In DNS map your naked domain to that server. It can be a really cheap linux server as requirements just to redirect are very low.
Find a domain redirect service that supports https and allows you to upload your certificate. Sadly I'm not aware of any.
Use VIP (Virtual IP) SSL and configure it in DNS for your naked domain. I haven't tested myself but it seems it should work, although I did find a old comment here that it may not. Has someone tested? NOTE however as far as I could see the DNS entry has a TTL of just 300 (5mins) and Google doesn't advise it, so even if it did work you might need some scripts to update your DNS entries as there's a strong chance it changes from time to time. If it does work then DNS providers like DNSSimple have an API so it would be possible.
Probably the second option is most applicable in your case as you don't seem to mind about the naked domain (which for many is an issue).
I recently found a good example: https://khanacademy.org/ They appear to use an Amazon EC2 host as per the second option above.
https://khanacademy.org/ Resolving khanacademy.org... 107.20.223.238
Connecting to khanacademy.org|107.20.223.238|:443... connected.
WARNING: cannot verify khanacademy.org’s certificate, issued by “/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287”: Unable to locally verify the issuer’s authority. WARNING: certificate common name “*.khanacademy.org” doesn’t match requested host name “khanacademy.org”.
HTTP request sent, awaiting response... 301 Moved
Permanently Location: https://www.khanacademy.org/ [following]
https://www.khanacademy.org/ Resolving www.khanacademy.org...
72.14.249.132 Connecting to www.khanacademy.org|72.14.249.132|:443... connected.
whois 107.20.223.238
OrgName: Amazon.com, Inc.
OrgId: AMAZO-4
Address: Amazon Web Services, Elastic Compute Cloud, EC2
As of 12 April 2014 it looks like Google makes some progress and now allows mapping of non Google Apps domains (seeissue 8517), although SSL appears not to work for that method yet (see issue 10794 for tracking that).
Best free SSL redirect service I found was CloudFlare. To get it working:
Add your domain and switch your name servers to CloudFlare (signup process walks you through it)
Once added goto CloudFlare Settings and down to SSL. Change the setting to 'Full SSL (Strict)' this requires you to have a valid cert on the subdomain your redirecting to (SNI works fine).
Go back to your websites list, select the domain again and on the options goto page rules. Add a 'Forwarding' rule that redirects https://yourdomain.com/* to https://www.yourdomain.com/$1 (replace www with any subdomain), make sure the redirect is set to 301.
Save your settings and sit back and wait for everything to propagate.
Done. Free and secure SSL redirection for your naked domain.
I had to switch my domain management and nameservers from GoDaddy(G-Suite) to Cloudflare to solve this naked domain redirect issue. I followed Parkers instructions and used the free Cloudflare account and it worked after I turned the redirect rule off and then back on. I switch back from Full(strict) to Full because you now need to pay to upload your own SSL certificate. I am ok with the shared universal SSL certificate from Cloudflare for the time being.
GAE doesn't officially support naked domains. What you're seeing is a limitation of GAE, you're not doing anything wrong. https://developers.google.com/appengine/kb/general#naked_domain
Apparently naked domain redirect on HTTPS is not supported. There is no mentioning of this in official docs. If you look at support docs you see in screenshots that naked redirect specifically states http://.
Judging from Google Groups threads, SSL naked domain redirect is not possible: here, here.
I'm doing https web requests in silverlight using "WebRequest"/"WebResponse" framework classes.
Problem is: I do a request to an url like: https://12.34.56.78
I receive back a versign signed certificate which has as subject a domain name like: www.mydomain.com.
Hence this results in a remote certificate mismatch error.
First question: Can I somehow accept the invalid certificate, and get the WebBresponse content ? (even if it involves using other libraries, I'm open to it)
Additional details: (for those interested on why I need this scenario)
I'm trying to give a client access to a silverlight app deployed on a test server.
Client accesses the silverlight app at: www.mydomain.com/app
Then I do some rest requests to: https://xx.mydomain.com
Problem is I don't want to do requests on https://xx.mydomain.com, since that is on our productive server. For this reason I use https://12.34.56.78 instead of https://xx.mydomain.com.
Client has some firewalls/proxies and if I simply change his hosts file and map https://xx.mydomain.com to 12.34.56.78, web requests don't resolve to the mapped IP.
I say this because on his network webrequests fail if I try that, on my network I can use the hosts changing without problems.
UPDATE: Fixed the problem by deploying test releases to an alternative: https://yy.domain.com and allowing the user to configure for test purposes, the base url to which I do requests to be: https://yy.domain.com.
Using an certificate that contained the IP in the subject or an alternative subject would've probably worked too, but would have cost some money to be issued by a certified provider and would not be so good because IP's might change.
After doing more research looks like Microsoft won't add this feature too soon, unless there's a scenario for non-testing/debugging uses.
See: http://connect.microsoft.com/VisualStudio/feedback/details/368047/add-system-net-servicepointmanager-servercertificatevalidationcallback-property