Our company is enabling Enhanced Domains in our Salesforce production org. We've done plenty of testing on sandbox but due to the differences in environment, it's basically not possible to be sure that production won't break or properly test 3rd party vendors that don't run on sandbox.
I noticed on sandbox that I can disable Enhanced Domains.
If I enable Enhanced Domains on production, if something breaks which can't be fixed quickly can I undo it and go back to my original domains?
Related
While I'm working with webpack-dev-server, I found a configuration called disableHostCheck. I am new to React and frontend development and I really like to know that What is host checking when to bypass hosts checking and why react developers should aware of that?
Disable Host checking prevents DNS rebinding attacks and a good explanation can be found here.
When disableHostCheck is disabled (sorry for the double negation, simply when host checking is enabled) same-origin policy is enforced. Which means when a script is run, the browser verifies whether the source of the script is in the same domain where the app is hosted.
We need to bypass host checking especially when an app is hosted locally and the app refers scripts hosted in other domains
Web pack documentation can be found here
I deployed a site but I cannot visit it due to HSTS.
I've tried contacting Namecheap, who I purchased the domain from, but they said the problem is with the hosting I am using. I am using surge.sh and have followed their custom domain instructions.
A picture of the error:
A picture of Namecheap:
I expect to be able to visit my site, but I cannot.
The issue isn't the dns configuration. HSTS (HTTP Strict Transport Security) means that the site can only be accessed over an encrypted (HTTPS) connection. Probably due to using a TLD (top-level-domain) like *.dev that requires the use of HSTS. To make this work you need to set up a certificate on your host.
Apparently surge.sh provides free certificates for <my-subdomain>.surge.sh, but you'd need one for your custom domain and Securing your custom domain with SSL is part of surge plus. So you'd have to purchase it and follow the instructions or use a different host that works better for you.
I know many people like to use surge.sh as nice free host for static sites, but in this case you need their paid plan. There are other platforms that allow certificates for custom domains on the free plan though. I'm using netlify with custom domain and https myself on a free plan.
Whiles playing around with GAE custom domain setup in hopes of building a multi-tenant application. I noticed that wildcard sub domains don't quit work as documented.
for example, if one configures domain *.dev.example.com *.qa.example.com you would expect dev.example.com to automatically serve default services deployed in appengine, I however noticed that recently I would have to explicitly enter default.dev.example.com. This however is not what has been documented.
Anyone understands why this is now the case? the domains are verified with DNS configuration on Google DNS service. All works as expected, meaning that I can reach all other services on domain, but default service is not automatically been served.
After various attempts, I eventually purchased some Google support time. And the solution to this is that you need to create and map both a wildcard domain and naked domain. Therefore, one will need to have both
*.dev.example.com and dev.example.com
This is of course tedious, the good news is that Google is running alpha testing on API that allows domain mapping to happen automatically, register at here
Soon multi tenancy application deployments will require no manual intervention.
Problem I want to solve
I want to be able to send different users to different versions of my Google App Engine application, on a custom domain, with SSL enabled. This needs to be done in a controlled way, i.e., even landing page should be different, and it has to work on multiple units for the user.
Solution I can't get to work
I am trying to setup a custom domain with sub-domains, and want to be able to access different versions of the application. For example, I have myapp.mydomain.com, and I want to run one version (alpha) on alpha.myapp.mydomain.com, and one version (beta) on beta.myapp.mydomain.com (where alpha is default).
I use the Google Developers Console to set up custom domains, using myapp.mydomain.com, and *.myapp.mydomain.com as custom domains.
This works perfectly as long as I don't try to add on SSL as well, i.e., beta.myapp.mydomain.com serves the version named beta. When I set up SSL I start by adding my application to Google Apps, (per https://developers.google.com/appengine/docs/ssl) and then set up my domain to point to my app. First I add myapp.mydomain.com, then alpha.myapp.mydomain.com, and last beta.myapp.mydomain.com.
When that is done beta.myapp.mydomain.com start to serve the default version instead. Except that it sometimes also serves the beta version (this happens one in every 20 tries or so, I assume it's a glitch for now).
My questions:
a) Should I set up my domains in both Google Apps and Google Developer Console? Or should I remove the setup from Google Developer Console? I tried both, seems to give the same results.
b) It seems like it is possible to get it done by using modules as indicated in
Google App Engine custom domains, subdomains and SSL and in Appengine modules dispatch.xml routing with custom domain. Is this the only way, or am I doing something wrong in my setup?
Suggestions I have received so far
One suggestion is to use traffic splitting and set a unique cookie depending on what version I want the user to end up with. I did not know about this, and it will solve some other issues I have been looking at. It does not solve my current problem though, as I need to have this set before log in. The answer is useful though.
I'll answer with what I did to make this work for me.
Instead of sending users to different versions of the app, I created a new module called alpha, and directed users using alpha.myapp.mydomain.com to that module using dispatch.xml.
<dispatch>
<url>*alpha.myapp.mydomain.com/*</url>
<module>alpha</module>
</dispatch>
I set up custom domains in the App Engine Console (https://console.developers.google.com) under Compute->App Engine->Custom Domains, for *.myapp.mydomain.com and alpha.myapp.mydomain.com. I also added the URL alpha.myapp.mydomain.com to the accepted URLs for my App Engine app on Google Apps (https://admin.google.com). This allowed me to run over SSL as well.
I intend to run the app under another domain (domain alias to my primary domain), so I tried that as well. To make this work I ONLY added the domain alias in Google Apps as www.mydomainalias.com and alpha.mydomainalias.com, because if I added it to Google App Engine custom domains I got an error message ("We are unable to process your request at this time. Please try again later. (Error #1000)"). I have no idea why it that did not work out.
The easier approach is to do traffic splitting on a cookie level compared to setting up extra subdomains AND extra SSL certificates.
The domain name to access your alpha version does not have to change using this approach.
from the docs :
The response from your app does not already contain a Set-Cookie:
GOOGAPPUID=... header. This allows your app to control which version a
user gets.
I have been used the Google App Engine for multiple hobby projects and I have even published a few of them and setup associated domains with moderate success. Of the few, one of those apps even uses sub-domain mapping.
In spite of the multiple setup attempts, I have still had a bit of difficulty setting up my domains for new projects and I've had to cross-reference multiple help articles (many found on SO). Some times those solutions, however, are close to what I've needed because of setup mistakes or variations in my application.
Even with a bit of experience, it still feels like I'm hacking the domain implementation together because there is no good start-to-finish setup for a GAE application that involves creating the necessary Google Apps application, the App engine application, domain registration and DNS setup.
So, could someone please offer a very high-level walk-through of setting up a GAE application from start to finish with the following requirements.
Requirements
A domain should point to the GAE application
The application should allow for sub-domain integration, pointing to different application handlers.
Can dynamic sub-domains be easily handled in the application? If so, what must you do in the setup process to assure that all requests to your domain are forwarded to the GAE app?
Forward "Naked" domain requests are forwarded to the right place. (There are multiple response to this requirement. What is the best approach to solving this requirement.)
If you must create a Google Apps application, when should it be created? Include this in the instruction list at the appropriate place.
Again, many of the above requirements have been asked on many forums, including this one. Usually it comes from someone who is in the middle of a problem setting up there domain with their application. Some of these requirements can be easily fulfilled if certain "gotchas" are avoided in the early stages of setup or application requirements are slightly modified to work around (or with) the limitations of the GAE.
In a nutshell, what I'm looking for is a very simple, straight forward response that provides a list of steps should be followed in order to setup a domain with a GAE application.
Thanks gurus.
All of the steps are independent - setting up a Google Apps account is the same whether you're going to add an App Engine app to it or not - except mapping the domain, which is documented here. Domain registration and DNS setup depends on your registrar, so it's not possible to write a universal guide to those. Handling subdomains in your app, meanwhile, is something that's not App Engine specific - it's just standard WSGI (or Servlets, depending on language).