I have a SaaS app where every user has a personal subdomain: username.domain.com. Every user has a personal blog at username.domain.com/blog.
Now I want to accept custom domains, e.g. www.mycustomblog.com would be an alias for username.domain.com/blog.
If someone browses to www.mycustomblog.com/123, the page username.domain.com/blog/123 should be served.
However, I do NOT want a redirect. The user should still see www.mycustomblog.com/123in their address bar.
How can I achieve this behaviour? I have looked into Nginx reverse proxies, DNS CNAME records... but nothing seems to suit my needs. I can access both the custom domain DNS settings and all of the server's config files.
I think what you're looking for is a rewrite. However your described logic doesn't work:
www.mycustomblog.com -> username.domain.com/blog
appears to be missing a piece of identifying information on the left side. Perhaps www.mycustomblog.com/username? After that, it's just a matter of writing out the match/map statements to change the request to match what you've got on the server.
Related
I had trouble getting AWS CloudFront to work with SquareSpace. Issues with forms not submitting and the site saying website expired. What are the settings that are needed to get CloudFront working with a Squarespace site?
This is definitely doable, considering I just set this up. Let me share the settings I used on Cloudfront, Squarespace, and Route53 to make it work. If you want to use a different DNS provide than AWS Route53, you should be able to adapt these settings. Keep in mind that this is not an e-commerce site, but a standard site with a blog, static pages, and forms. You can likely adapt these instructions for other issues as/if they come up.
Cloudfront (CDN)
To make this work, you need to create a Cloudfront Distribution for Web.
Origin Settings
Origin Domain Name should be set to ext-cust.squarespace.com. This is Squarespace's entry point for external domain names.
Origin Path can be left blank.
Origin ID is just the unique ID for this distribution and should auto-populate if you're on the distribution creation screen, or be fixed if you're editing Origin Settings later.
Origin Custom Headers do not need to be set.
Default Cache Behavior Settings / Behaviors
Path Patterns should be left at Default.
I have Viewer Protocol Policy set to Redirect HTTP to HTTPS. This dictates whether your site can use one or both of HTTP or HTTPS. I prefer to have all traffic routed securely, so I redirect all HTTP traffic to HTTPS. Note that you cannot do the reverse and redirect HTTPS to HTTP, as this will cause authentication issues (your browser doesn't want to expose what you thought was a secure connection).
Allowed HTTP Methods needs to be GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE. This is because forms (and other things such as comments, probably) use the POST HTTP method to work.
Cached HTTP Methods I left to just GET, HEAD. No need for anything else here.
Forward Headers needs to be set to All or Whitelist. Squarespace's entry point we mentioned earlier needs to know where what domain you're coming from to serve your site, so the Host header must be whitelisted, or allowed with everything else if set to All.
Object Caching, Minimum TTL, Maximum TTL, and Default TTL can all be left at their defaults.
Forward Cookies cookies is the missing component to get forms working. Either you can set this to All, or Whitelist. There are certain session variables that Squarespace uses for validation, security, and other utilities. I have added the following values to Whitelist Cookies: JSESSIONID, SS_MID, crumb, ss_cid, ss_cpvisit, ss_cvisit, test. Make sure to put each value on a separate line, without commas.
Forward Query Strings is set to True, as some Squarespace API calls use query strings so these must be passed along.
Smooth Streaming, Restrict Viewer Access, and Compress Objects Automatically can all be left at their default values, or chosen as required if you know you need them to be set differently.
Distribution Settings / General
Price Class and AWS WAF Web ACL can be left alone.
Alternate Domain Names should list your domain, and your domain with the www subdomain attached, e.g. example.com, www.example.com.
For SSL Certificate, please follow the tutorial here to upload your certificate to IAM if you haven't already, then refresh your certificates (there is a control next to the dropdown for this), select Custom SSL Certificate and select the one you've provisioned. This ensures that browsers recognize your SSL over HTTPS as valid. This is not necessary if you're not using HTTPS at all.
All following settings can be left at default, or chosen to meet your own specific requirements.
Route 53 (DNS)
You need to have a Hosted Zone set up for your domain (this is specific to Route 53 setup).
You need to set an A record to point to your Cloudfront distribution.
You should set a CNAME record for the www subdomain name pointing to your Cloudfront distribution, even if you don't plan on using it (later we'll go through setting Squarespace to only use the root domain by redirecting the www subdomain)
Squarespace
On your Squarespace site, you simply need to go to Settings->Domains->Connect a Third-Party Domain. Once there, enter your domain and continue. Under the domain's settings, you can uncheck Use WWW Prefix if you'd like people accessing your site from www.example.com to redirect to the root, example.com. I prefer this, but it's up to you. Under DNS Settings, the only value you need is CNAME that points to verify.squarespace.com. Add this CNAME record to your DNS settings on Route 53, or other DNS provider. It won't ever say that your connection has been fully completed since we're using a custom way of deploying, but that won't matter.
Your site should now be operating through Cloudfront pointing to your Squarespace deployment! Please note that DNS propogation takes time, so if you're unable to access the site, give it some time (up to several hours) to propogate.
Notes
I can't say exactly whether each and every one of the values set under Whitelist Cookies is necessary, but these are taken from using the Chrome Inspector to determine what cookies were present under the Cookie header in the request. Initially I tried to tell Cloudfront to whitelist the Cookie header itself, but it does not allow that (presumably because it wants you to use the cookie-specific whitelist). If your deployment is not working, see if there are more cookies being transmitted in your requests (under the Cookie header, the values you're looking for should look like my_cookie=somevalue;other_cookie=othervalue—my_cookie and other_cookie in my example are what you'd add to the whitelist).
The same procedure can be used to forward other headers entirely that may be needed via the Forward Headers whitelist. Simply inspect and see if there's something that looks like it might need to go through.
Remember, if you're not whitelisting a header or cookie, it's not getting to Squarespace. If you don't want to bother, or everything is effed (pardon my language), you can always set to allow all headers/cookies, although this adversely affects caching performance. So be conservative if you can.
Hope this helps!
Here are the settings to get CloudFront working with Squarespace!
Behaviours:
Allowed HTTP Methods Ensure that you select: GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE. Otherwise forms will not work:
Forward Headers: Select whitelist and choose 'Host'. Otherwise squarespace will not know which website they need to load up and you get the message 'Website has expired' or similar.
Origins:
Origin Domain Name set as: ext-cust.squarespace.com
Origin Protocol Policy Select HTTPS so that traffic between the CDN and the origin is secure too
General
Alternate Domain Names (CNAMEs) put both your www and none www addresses here and let Squarespace decide on if to direct www to root or vice-versa (.e.g example.com www.example.com)
You can now configure SSL on CloudFront
HTTPS You can now enforce HTTPS using a certificate for your site here rather than in Squarespace
Setting I'm unsure about still:
Forward Query Strings: recommended not for caching reasons but I think this could break things...
Route53
Create A records for www and root (e.g. example.com www.example.com) and set as an alias to your CloudFront distribution
We have a web application, say mysite.com.
Now users can come and create pages like, mysite.com/page/mypage. Here 'mypage' is unique identifier for the page he/she has created. So whenever mysite.com/page/mypage url is requested, it hits our 'pagerequestservlet', which gives out requested page data.
Now what I want is, whenever user hits, mypage.mysite.com, then also we give out the same page related info (that we give out on mysite.com/page/mypage). This would mean, I need to make all my *.mysite.com requests to be handled by 'pagerequestservlet' (or a similar servlet). Then I can just parse the request URL, identify the identifier 'mypage' and return the data.
Now my question is, how to make all my *.mysite.com requests to be handled by 'pagerequestservlet'? I am using GoDaddy as my domain registrar.
You must setup your DNS to allow such wildcards, I don't know wheter GoDaddy supports this.
A servlet is "DNS-agnostic", normally it does not need to know anything about its domain name. This way it's possible to deploy the same servlet on different environments or even with different context roots (example.com/a and example.com/b).
You still have access to the domain name via ServletRequest#getServerName(). You could implement a Filter that handles the subdomain part and redirect to the correct page. But be aware - if you run in a clustered environment or behind a load balancer, this would not return mypage.example.com, but the name of the host ther servlet was deployed to.
What I'd really like to do is set up an azure site called site.com. Then have hundreds of subdomains such as foo.site.com, bar.site.com, baz.site.com etc. My asp.net mvc application will pull out the subdomain as this will be used as an identifier.
Next I'd like to have other domains CNamed to the subdomains. Such as hello.othersite.com -> foo.site.com, so that the browser still shows hello.othersite.com but I'd be able to get the foo subdomain out of the request.
I don't want to have to configure any of this because there are going to be lots of subdomains, essentially one per account.
Is this actually possible?
I've tried a few tests but I'm not 100% sure how to proceed. Would I just:
Setup site.com to accept *.site.com
CNAME hello.othersite.com to foo.site.com (do I want masking, forwarding etc?)
Does the incoming http request contain any information about the subdomain (foo) that
it's CNAMED to?
I hope this isn't too vague and hand wavey but some confirmation of its plausibility would be a great help.
It is not just Azure, but the whole web.
I don't think it is possible to get out of the HTTP request for hello.othersite.com that it actually mapped in the DNS to foo.site.com. And this is because your actual HTTP request will look something like
GET /index.html HTTP/1.1
(other headers)
host: hello.othersite.com
Your web server, whatever it is, has no idea that hello.othersites.com is mapped via CNAME to foo.site.com. The request you receive is for hello.othersite.com.
If you do forwarding, the users will never stay on hello.othersite.com but will be redirected to foo.site.com. I guess this is not what you want.
Direct domain masking is usually done via iFrame, which would also not recommend.
I would do the following, as nothing else comes to mind at the moment:
Setup the site to accept *.site.com and *.othersite.com
Add Wildcard CNAME map to my Azure cloud service, i.e. *.site.com -> CNAME -> my.cloudapp.net. Same for both custom domains I want to have.
Perform necessary checks in my app to figure out domain mappings <-> user accounts.
I have a business requirement, where i should show a different URL in the address bar from the actual. Say for ex: I have hosted my site at Hum.com. But for some users, this URL should show up as CP.com at the address bar? Is it even possible?
The only way to do this is if you control both domains, hum.com and cp.com and if you configure your web server to serve the same application for cp.com and hum.com.
If above is the case (you control both domains), you can simply redirect the users to the appropriate domain using Response.Redirect.
This is easily done in Apache via NameVirtualHosts and I am sure IIS offers the same functionality.
Yes this is possible, but it's generally done at the DNS level and not within the application itself. You want the IP address of Hum.com to resolve to the same IP address as CP.com. This is how hosting sites such as Google Sites generally work.
To do this you need to own the DNS entry for your vanity domain name (i.e. CP.com) and you need to ensure that the hosting site is capable of associating requests for CP.com with the hosted website.
This can be done by redirect.
if(fUserOfCP && !HttpContext.Current.Request.RawUrl.Contains("cp.com/")){
Responce.Redirect(
HttpContext.Current.Request.RawUrl.Replace("hum.com/", "cp.com/")
, true);
}
This code is the idea, probably is better to break the RawUrl, check and reconstruct it on the redirect to avoid the existing of host on file name.
Assume that both names belong to you, and you have setup correctly the dns.
Rewrite is not possible on host name if this is your first thoughts.
We've recently run into an issue with our ASP.NET application where if a user goes to ourcompany.com instead of www.ourcompany.com, they will sometimes end up on a page that does not load data from the database. The issue seems to be related to our SSL certificate, but I've been tasked to investigate a way on the code side to fix this.
Here's the specific use case:
There is a user registration page that new users get sent to after they "quick register" (enter name, email, phone). With "www" in the URL (e.g. "www.ourcompany.com") it works fine, they can proceed as normal. However, if they browsed to just "ourcompany.com" or had that bookmarked, when they go to that page some data is not loaded (specifically a list of states from the DB) and, worse, if they try to submit the page they are kicked out entirely and sent back to the home page.
I will go in more detail if necessary but my question is simply if there is an application setting I can say to keep the session for the app regardless of if the URL has the "www" or not? Buying a second SSL cert isn't an option at this point unless there is no recourse, and I have to look at a way to solve this without another SSL.
Any ideas to point me in the right direction?
When your users go to www.ourcompany.com they get a session cookie for the www subdomain. By default, cookies are not shared across subdomains, which is why users going to ourcompany.com do not have access to their sessions.
There is a useful thread discussing this issue here. The suggested solution is:
By the way, I implemented a fairly good fix/hack today. Put this code
on every page: Response.Cookies["ASP.NET_SessionId"].Value =
Session.SessionID; Response.Cookies["ASP.NET_SessionId"].Domain =
".mydomain.com";
Those two lines of code rewrite the Session cookie so it's now
accessible across sub-domains.
Doug, 23 Aug 2005
Surely you are trying to solve the wrong problem?
Is it possible for you to just implement URL rewriting and make it consistent?
So for example, http://example.com redirects to http://www.example.com ?
For an example of managing rewriting see:
http://paulstack.co.uk/blog/post/iis-rewrite-tool-the-pain-of-a-simple-rule-change.aspx
From the browsers point of view, www.mysite.com is a different site than mysite.com.
If you have a rewrite engine, add a rule to send all requests to www that don't already have it.
Or (this is what I did) add a separate IIS site with the "mysite.com" host header and set the IIS flag to redirect all traffic to www.
In either of these cases, any time a browser requests a page without the www prefix, it will receive a redirect response sending it to the correct page.
Here's the redirect site home directory properties:
And the relevant host header setting:
This fixes the issue without requiring code changes, and incidentally prevents duplicate search results from Google etc.
Just an update, I was able to fix the problem with a web.config entry:
<httpCookies domain=".mycompany.com" />
After adding that, the problem went away.