Thanks for letting us know about the redirection issues. I was able to get GoDaddy to redirect from domain.example to www.domain.example by setting up forwarding here. It looks like you can also set it up for subdomain to destination. This is located underneath the DNS record settings table, just scroll down a bit and you should find it.
If you’re doing apex publishing, try removing the CNAME record and try adding the forwarding from a subdomain (www.testdomain.com) with the destination being https://testdomain.com at a Permanent 301 forward. Let me know if that works; it was able to work for me going the other direction!
Edit: It looks like subdomain forwarding from www.testdomain.com to testdomain.com required me to wait for a good while before the redirect started working, around 10 minutes or so. It also seems to have it’s moments where it works, and then moments when it doesn’t. I can investigate on why it takes so long and why the behavior seems to be flaky.
I also noticed that GoDaddy had an A record called “Parked” that would interfere with things, so I removed that. Hopefully that can help!
This was a recent bug that we discovered, I believe it should be fixed now. If you go to your publishing settings and mark the mode as “View Mode” now, your custom domain should no longer be in play-mode (give it a few minutes).
thanks so much for looking into this matter, I really appreciate you taking the time.
How utterly strange that you were able to get the domain forwarding to work, while I cannot.
Thanks for describing the Subdomain forwarding. I had tried both variants, ie
a) either stating a CNAME record with name “www” and value “testdomain.com” (ie without www-prefix)
b) or adding a subdomain for www.testdomain.com with a permanent forward to https://testdomain.com
Unfortunately, neither works for me (I just retried the subdomain forwarding as per your post, and even after 2 hours nothing changed).
That being said:
I do not expect you to invest your time to figure out an issue that is solely related to my domain and DNS provider. If it’s an issue on GoDaddy’s side, I will go back to them to have it resolved.
The reason I reached out to you is because I wanted to make sure the issue does not lie on Coda’s side (as GoDaddy informed me that the www-redirect won’t work because Coda has not allowed for the redirect on their Hosting server).
Can you confirm that the Hosting Server is set up in a way that allows for domain forwarding (based on your recent post, I’d assume this to be the case, as you were able to get it to work for your test domain).
Hello @John_Li1 ,
I can confirm I see the difference between View and Play mode now. I think things don’t work exactly as expected when edit mode is selected (which might be necessary for the standard published link (without the website redirect).
I am wondering if the edit option works as expected under any mode right now, but I am working on a few other things, so I will check later.
Thanks,
Greetings,
Joost
Coda support investigated the matter and provided me with the following update:
“It looks like your DNS provider is not responding on port 443 (SSL). So a request to [https://www.testdomain.com] is not properly redirecting to [https://testdomain.com]. As far as next steps, our developer looking at this advised that this unfortunately may just not be supported with your dns provider”
Support further suggested a work-around, which I implemented and it works fine, hence I wanted to share:
I published Doc X and connected to domain testdomain.com.
I updated my DNS records as per the publish settings issued by Coda upon connecting a domain.
Next, I created a copy of Doc X. I connected this copy to domain www.testdomain.com (ie with the prefix www as subdomain)
I updated my DNS records as per the publish settings issued by Coda upon connecting a domain.
For this particular use case, I won’t make changes to “Doc X”, so don’t mind the fact that I had to create a copy. Naturally, if Doc X is an evolving doc, using this work-around will not be satisfactory.
Thanks for everyone who pitched in on this! Thanks,
Nina
Hi, I’m hoping someone can help with a security question for a custom domain doc.
I published a doc in Play Mode on a custom domain and noticed that anyone can access hidden pages, including a form results page with all the contact details of other respondents.
For (an anonymised) example: if my site is healthyfood.com and a page URL was healthyfood.com/bananas-1 all that’s needed is to change that -1 to something else, say healthyfood.com/bananas-2 and the sensitive data is all there for all to see. Likewise any navigation though the branches of hidden pages.
I’m not a developer or coder, so there’s likely something basic I’m missing, but I couldn’t find anything about this in the documentation and would really appreciate any advice.
How did you find out about the /-1 , -2 etc logic?
Experienced Coda makers have known this for a long time, but rarely communicated about it in the open. Sometimes I wonder if Coda employees understand this.
Long story short, this is how Coda operates today. When you publish something, make sure you don’t have hidden pages. The source table of the form you best put in a different doc.
I found it because I went to send the page URL to our customers in a newsletter. I noticed the -1 (actually it’s a 54) and became curious what happens if I removed the number for a cleaner URL and it was an instant realisation from there.
Do you know what causes the URL naming convention of pages within a doc? Or is there a way to “rename” the URL for a page?
That is a massive insight, thank you. I truly appreciate it. And also quite unfortunate as a CRM is exactly what I’ve been building towards for some time now.
Regarding the URL’s: they are based on the page title and a page create sequence number - which you can’t change yourself.
@Coda_hq: it would be nice if published docs would not have this sequence number in the URL. I realize the problem if you have 2 identical page names, but perhaps you could limit adding these numbers only to pages with identical names.
As far as CRM and many other documents with confidential or GDPR sensitive data: why would you publish a doc like that in the first place? Coda can be used as a CRM, but you have to be really selective with sharing.
We have just launched a JV initiative with another company. We are using a Doc as our website and successfully published it to a new domain hosted by Crazy Domains. I’ve published documents to subdomains on our website (hosted by Go Daddy) but we can’t use either of our websites because that’s not fair to the other company.
Our JV Doc works with www.domain.com but not domain.com. Nina’s solution above doesn’t work for our case because it’s a dynamic document that we update weekly. Going to domain.com I get a https warning, so I thought it might be an SSL issue.
We are having trouble getting a SSL certificate… from the domain host:
we are unable to verify the website and email existence. If your website is hosted somewhere else, please provide the following:
1.) CSR file generated from your hosting provider (with 2048 bits key),
2.) SERVER SOFTWARE used to generate the CSR, and
If I ‘proceed anyway’, it just takes me to Crazy Domain to buy the website. When I spoke to their support team, they told me they could see our Doc at domain.com so I have no idea what’s going on.
