Hi, I’ve started a new topic in “Ask the Community” called How do I…? for custom domains. It might be good, for those of us excited about this new (and frequently requested) feature to share information and ask questions under one topic…
Cheers,
Jack
1 Like
Hi @John_Li1,
love the possiblity of publishing Coda-docs to custom domains! However, I’m running into a problem, as the published doc is solely reachable when a user types “testdomain.com” into their browser (ie without the www-prefix). When the user tries to access “www.testcomain.com”, they encounter an error message. More details below:
From Coda’s Help pages, I have gleaned the following:
Hence, I managed my DNS settings as follows:
- In addition to setting the A-Records as per the “Publish Settings” of my Coda doc,
- I also set the CNAME record for “www” to the root A-record as well.
- I have verified these settings with my DNS provider’s customer service (in my case, GoDaddy) several times, and received the “all clear, all settings correct, domain forwarding should now work” multiple times.
Needless to say, it still does not work (hence, my motiviation to write this post). In one of my many conversations with GoDaddy, I finally received the following instruction:
“The issue lies with the Hosting Provider. It needs to add the re-direction on their hosting server in order to for URL redirection to work on an individual website level”.
Now, blaming the other party is, of course, not an entirely new method of trying to resolve a situation.
However, please look into this matter and let me know if there is merit to it, and if so, if this can be rectified.
Thanks,
Nina
4 Likes
Same problems here, my redirection doesn’t work at all. My domain provider (gandi.net) support said that there is a problem with the SSL certificates.
Neither www. or plain domain work.
Any ideas?
I had the same issue and I think it is the way this is setup by Coda. I tried different things with the DNS and didn’t get it to work properly.
I found 2 solutions (better is 2 if you can find it in your hosting options):
- You can put a small file in the root http(s)docs directory to make this work:
index.html
- If your webserver management panel allows for it (I use Plesk)
where the default is often ‘None’
3 Likes
Hi there Nina,
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!
Hi Petros, mind letting me know what docId or domain you’re trying to connect and I can see what it looks like on our end in terms of errors?
Hey Joost,
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).
safer-safer_dAbFblzavkJ this should be it
Hi @John_Li1 ,
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).
Thank you and best regards,
Nina
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
Wanted to give everyone an update to this topic.
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.
Now, a user can reach the doc by typing www.testdomain.com or solely testdomain.com into their browser.
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
1 Like
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.
1 Like
hi @Adam_Maggs ,
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.
Cheers, Christiaan
1 Like
Hi Christian,
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?
Thank you so much for the quick response.
1 Like
hi @Adam_Maggs ,
Well that was a clever thing to do!
I am not so much into this publishing of docs, mainly due to what you described.
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?
nope, in you domain name provider maybe you can put a URL forward, but that is a lot of manuel work. Coda is not a CRM due to its lack of security.
maybe @joost_mineur can help us out? He is better with this stuff than I am.
Cheers, Christiaan
1 Like
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.
3 Likes
I’m just leaving this bit of info I stumbled upon here, as it might interest you @Adam_Maggs 
2 Likes
Hi All,
On a tangent, Shishir has mentioned that one of the two top things that Coda is working on is granular permissions. Let’s hope it is implemented soon.
Regards
Piet
2 Likes
+1 Cloudflare compatibility would be great!