I've registered a domain with www.domain101.com. We'll call it www.example.com. I used their 'cloaked forwarding' option on my heroku app, which we'll call example.herokuapp.com. If I want to navigate to the posts index page, I would go to example.herokuapp.com/posts, of course; however, when I try this with my cloaked domain - www.example.com/posts - it takes me to the landing page. What's more, the url is constantly set to 'www.example.com' and the title of each page is "EXAMPLE.COM". I can click buttons on the pages and navigate through my website, but the url remains strictly at 'www.example.com'.
I used the forwarding option available on the website. What else should I be doing?
Domain cloaking uses a frame to make visitors' browsers show the cloaking domain in the location bar, while having the actual content hosted somewhere else. That's why the location bar never changes when you navigate around the site; and it isn't surprising that domain101's cloaking implementation doesn't forward path information to your Heroku app.
What you should do instead is configure a DNS server to direct traffic for your domain directly to Heroku. The simplest option for that on Heroku is the Zerigo DNS Add-on, which is free if you're hosting a single domain. You can also find DNS servers provided by lots of other people if you prefer.
Once you've configured a DNS server, you also need to tell your registrar that the DNS server you chose is the primary DNS for your domain. The way to do that varies between registrars, so you should check domain101's documentation for details.
Related
(how) is this possible:
I have 2 netlify sites main-app and sub-app.
main-app has a custom domain (www.main.com).
I now want to make the 2nd site sub-app using the custom domain sub.main.com but Netlify forbids this and notes that I already use the respecity domain main.com.
Any help?
It is possible to use subdomains. It is discussed in detail in their docs: https://docs.netlify.com/domains-https/custom-domains/
You already have a Netlify subdomain where your app is hosted, of type myapp.netlify.app. Now you need to point your subdomain to this instance. If you use for example Namecheap, you do it like this: https://www.namecheap.com/support/knowledgebase/article.aspx/9776/2237/how-to-create-a-subdomain-for-my-domain/
Here is Netlify's instructions for doing this if you don't host your domain with them (aka not using Netlify DNS) https://docs.netlify.com/domains-https/custom-domains/configure-external-dns/
Similar DNS editing as in Namechrap will be seen on all other domain hosts. Once this is set up and has had time to propagate (give it 10 minutes to an hour) you proceed with hooking it up in Netlify. Your error message should now be gone.
Remember that you need different DNS records on your domain host for the main app and the sub app.
You can add a subdomain in the netlify panel and in you DNS manager / hosting provider add the records as CNAME with the domain provided by netlify.
I have a system whenever user upload an image, it will send an email to the registered user's gmail. But in the email, i see something like this, the thumbnail is not viewable.
I inspect on the element, and found the src linked to this url:
https://ci5.googleusercontent.com/proxy/VI2cPXWhfKZEIarh-iyKNz1j9q7Ymh8ty4Yz19lXh82RjSlACBzS0aRajfIj913uXAsX2ylcLEDs5FBsj4cR9TcU75Pw5djdHx4htxdCAQxs_ue1Q1wi5TV43uLLBpigpjH1xN747mUHSRdTBJmXQWFyykInJCRXicM1KhNk=s0-d-e1-ft#https://www.somedomain.com/files/1658/thumbnail_71JtDozxS1L._SY450_.jpg
Obviously it is being cached by google proxy
But i can view the image without google user content, by accessing https://www.somedomain.com/files/1658/thumbnail_71JtDozxS1L._SY450_.jpg (i masked the domain so the image might not available to you).
I tried to clear browser cache but the problem still persist. How can i bypass the googleusercontent thingy or at least make the thumbnail able to display.
I checkout on this link Images not displayed for Gmail but im not using localhost and the image itself is accessible outside of my local network.
How does Google Image Proxy work
The Google Image Proxy is a caching proxy server. Every time an image link is included in email the request will go to the Google Image Proxy first to see if it has been cached, if so it should serve it up from the proxy or it will go fetch it and cache it there after.
The solution for most issues
The Google Image Proxy server will fetch your images if this images:
have extensions like .png, .jpg/.jpeg or .gif only. May be .webp too. But not .svg.
do not use any kind of query string part in the image URL like ?id=123
have an URL which is mapped onto the image directly.
have not a long name.
Requirements for image server:
The response from image server/proxy server must include the correct header like Content-Type: image/jpeg.
File extension and content-type header must be in the same type.
Status code in server response must be 200 instead of 403, 500 and etc.
What could help too?
Google support answer:
Set up an image URL proxy whitelist
When your users open email messages, Gmail uses Google’s secure proxy
servers to serve images that might be included in these messages. This
protects your users and domain against image-based security
vulnerabilities.
Because of the image proxy, links to images that are dependent on
internal IPs and sometimes cookies are broken. The Image URL proxy
whitelist setting lets you avoid broken links to images by creating
and maintaining a whitelist of internal URLs that'll bypass proxy
protection.
When you configure the Image URL proxy whitelist, you can specify a
set of domains and a path prefix that can be used to specify large
groups of URLs. See the guidelines below for examples.
Configure the Image URL proxy whitelist setting:
Sign in to your Google Admin console. Sign in using your administrator account (does not end in #gmail.com).
From the Admin console Home page, go to Apps > G Suite > Gmail > Advanced settings. Tip: To see Advanced settings,
scroll to the bottom of the Gmail page.
On the left, select your top-level organization.
Scroll to the Image URL proxy whitelist section.
Enter image URL proxy whitelist patterns. Matching URLs will bypass image proxy protection. See the guidelines below for more details and
instructions.
At the bottom, click Save.
It can take up to an hour for changes to propagate to user accounts.
You can track prior changes under Admin console audit log.
Guidelines for applying the Image URL proxy whitelist setting
Security considerations
Consult with your security team before configuring the Image URL proxy
whitelist setting. The decision to bypass image proxy whitelist
protection can expose your users and domain to security risks if not
used with care.
In general, if you have a domain that needs authentication via cookie,
and if that domain is controlled by an administrator within your
organization and is completely trusted, then whitelisting that URL
should not expose your domain to image-based attacks.
Important: Disabling the image proxy is not recommended. This option is available to provide flexibility for administrators, but
disabling the image proxy can leave your users vulnerable to malicious
attacks.
Entering Image URL patterns
To maintain a whitelist of internal URLs that'll bypass proxy
protection, enter the image URL patterns in the Image URL proxy
whitelist setting. Matching URLs will bypass the image proxy.
A pattern can contain the scheme, the domain, and a path. The pattern
must always have a forward slash (/) present between the domain and
path. If the URL pattern specifies a scheme, then the scheme and the
domain must fully match. Otherwise, the domain can partially match the
URL suffix. For example, the pattern google.com matches
www.google.com, but not gle.com. The URL pattern can specify a
path that's matched against the path prefix.
Important: Enter your actual domain name as you enter the image URL pattern. Always include a trailing forward slash (/) after the
domain name.
Examples of Image URL patterns
The following patterns are examples only. The following patterns:
http://rule_fixed_scheme_domain.com/
rule_flex_scheme_domain.com/
rule_fixed_subpath.com/cgi-bin/
... will match the following URLs:
http://rule_fixed_scheme_domain.com/
http://rule_fixed_scheme_domain.com/test.jpg?foo=bar#frag
http://rule_fixed_scheme_domain.com
rule_flex_scheme_domain.com/
t.rule_flex_scheme_domain.com/test.jpg
http://t.rule_flex_scheme_domain.com/test.jpg
https://t.rule_flex_scheme_domain.com/test.jpg
http://rule_fixed_subpath.com/cgi-bin/
http://rule_fixed_subpath.com/cgi-bin/people
Note: The URL scheme (http://) is optional. If the scheme is omitted, the pattern can match any scheme, and allows partial matches
on the domain suffix.
Previewing the image URL patterns
Click Preview to see if the URLs match the image URL patterns
you've set. If the image URL matches a pattern, you'll see a
confirmation message. If the image URL does not match, an error
message appears.
Bharata has a great and detailed answer on this, but just wanted to add one addition that I identified with a similar issue.
We had a x-webkit-csp content security header that turned out to be the culprit.
Removing it and all worked through the image proxy.
Google's response was that x-webkit-csp is deprecated and to use the Content-Security-Policy header instead.
However this seems like a bug that an unsupported header throws a fatal error rather than simply ignoring it.
TL;DR: Make sure your server isn't blocking external connections (through AWS or .htaccess or some other firewall)!
I was having this problem too. I ran through every solution I could think of and every one I found online. Nothing fixed it.
Finally, I inspected the image in Gmail so that I could get the full CDN address Google creates for it. I tried to open that in a new tab and it failed. So I realized that Google wasn't able to grab the image.
In the end, I'd forgotten that I have the server locked down from all traffic except for my own (just a basic .htaccess IP deny). It's just a simple security layer I use while I'm in my development. Keep in mind that you might have it locked down within AWS or something more rugged like that.
I opened up all IPs for a minute, tested it, and sure enough it worked as expected. The old emails that were previously failing also worked, so it seems that Google tries to work their magic anytime the email is opened and they don't have the image saved. Once I closed the IP address again, the image continued to work whatever Google. I'm guessing once they write it to their CDN is remains there indefinitely.
So if you're certain that you've done everything else correctly, I would suggest making sure that the server is indeed open to the outside world so Google can process the image.
I had the same problem and I solved it by specifying the "https://" protocol in the "src" url of the img, otherwise by default "http" is prepended
I've set up my custom domain with firebase hosting using their CNAME and A record details. Visiting http://sub.example.com redirects to https://example.com (not what I wanted)
I want to persist my subdomain (https://sub.example.com) in the address bar without the 301 redirect to (https://example.com) that I'm currently getting. Is this possible to set up this behavior within firebase hosting itself? I'd also like to point this sub domain to a certain html file/directory that I configure.
Basically, we have a site and a store already setup (not using WorldPay), but we’re changing to an entirely new website design, with a new store, using WorldPay this time (but using the same domain name as before).
Everything is all tested and ready on a temporary URL, so all that is left to do is have WorldPay activated and switch the domain over, but how can we give WorldPay access to test and activate our installation WITHOUT letting customers see the site at the same time (as we want to launch it on a set time/date).
The options from our perspective were:
WorldPay tell us the IP address they will be checking over the installation with, and we can limit access by IP address using htaccess or similar.
We change the URL temporarily to something like “/store38382882” which no one will know about, then once everything is activated, we would need to switch back to just “/store”. But from what I can see in the WorldPay docs, the URL you provide them with isn't easily changeable.
Are either of these possible? And if not, how is this usually handled? Just hoping for advice from people who've done this before!
I put site on a sub domain, in the worldpay admin area, you set the callback URL and passphase specific for the sub domain.
Once you are ready for live, you just need to make sure that your settings also match up with the live configuration of your account on worldpay
for example:
live callback http://www.site.com/worldpay/callback
Testing and demo http://test.site.com/worldpay/callback
You should have bindings in your code to detect the Host URL to pick up if its www. or test. this will enable you to have settings for live and test without having to do many changes to your code, or worse, having two versions of the code base.
hope this helps
I want our app to show the online help page (so it's always up to date) or even a local page. However, it's likely to be blocked by the Firewall (Zone Alarm).
BTW, I tested this with Zone Alarm. It blocked access to a local .html file as well as to an .asp file on the internet. (I.e., tried to display a page in Internet Explorer and got the Zone Alarm dialog asking if I wanted to give permission to display
Is there a way around this?
Perhaps displaying the web page in the Web Browser Control?
It's actually very unlikely that web traffic is blocked at the firewall (unless you mean the file type is blocked?). What you may need to do in such a setting, however, is use the same proxy that IE uses, because direct traffic may be blocked.
The simplest way to do that is to use a high level windows API or IE itself, and HTTP download the latest helpfile if there is a new one - these mechanisms should know about any proxy.
Of course, your users may not be using IE, even if most are. So you might need to allow the user to specify the proxy, or be able to auto configure the proxy in the same way that the browser does it.
edit: I see you mean zonealarm is part of the problem. yes, that is tricky as you will have to either get your application 'blessed' centrally by whoever manages zonealarm in the customer organisation, or (if there is no central management) then the user will have to allow the app to communicate. Perhaps you should bite the bullet and have the online help simply be a website, and spawn the preferred browser via 'executing' the URL as suggested in another answer.
If the web browser isn't blocked the firewall then they probably open port 8080 for any app and thus your app shouldn't be blocked.
If the firewall only allowed port 8080 to IE; you would have to punch a hole in the firewall to use a new browser like firefox or chrome.
To open a web page using the user's preferred browser (with appropriate proxy and authentication settings), use something like ShellExecute with the URL of the document to load. Something like this would do it (where page is the URL to load):
HINSTANCE r = ShellExecute(NULL, "open", page, NULL, NULL, SW_SHOWNORMAL);