Following configuration instructions there, I edited .conf.in ocsigenserver configuration file adding
<securecookies value="true" />.
I modified default PORT variable from Makefile.options from 80 to 443 (default port for https).
I built again the project with
sudo make install
sudo PATH=$PATH OCAMLPATH=$OCAMLPATH LD_LIBRARY_PATH=$LD_LIBRARY_PATH make run.opt
and I could not connect in https to the site. (a request in http was immediately rejected while a request in https was timing out after a while, with my browser console warning 6 cookies will be treated as cross-site from my app url as the scheme does not match (in French :
Le cookie « eliomservicesession|S|||userindep » sera bientôt traité comme un cookie intersite vis-à-vis de « https://www.app.com/ » car le schéma ne correspond pas.).
I found nothing interesting in logfiles.
Here is the server console output when I launch the server in case it is useful:
[WARNING] Running as root is not recommended
==== The website is available at http://localhost:443 ====
ocsigenserver.opt "-v" -c /usr/local/etc/app/app.conf
ocsigenserver.opt: ocsigen:config: While parsing config file, tag <host>: No defaulthostname, assuming it is "ip-some_ip.internal"
ocsigenserver.opt: ocsigen:main: Ocsigen has been launched (initialisations ok)
I also tried to add attribute
protocol="HTTPS" to port setting in .conf.in file, without success.
Do you have any hint of what could be wrong with it ? (What I want is running the app https only, so if you know how to redirect http request to https with ocsigenserver I take it also )
Have a good evening !
I would recommend using Nginx or something similar to do SSL termination. For a proper deployment you’ll need a reverse proxy anyway, so might as well set it up now.
Thanks for your answer @yawaramin ! I am not familiar with this, but after searching on use of reverse proxies, it looks like it has value when several servers are involved (https://www.nginx.com/resources/glossary/reverse-proxy-server/, https://www.quora.com/Why-do-we-need-reverse-proxy, https://aarvy.me/blog/2019/09/30/what-is-reverse-proxy-live-example-2019/). I set up an MVP, on a single server, and when I will need to increase capacity, my cloud provider have ssl facilities for their load balancing service, so I think I wont need a reverse proxy (at least for ssl). Of course I can set it up on my single machine, and then on every one, but I do not see the benefits of it. Maybe I am wrong ?
If your cloud provider gives you SSL termination out of the box, then turn it on and problem solved
A reverse proxy is needed for things like:
- Load-balancing requests to multiple instances of your server
- SSL termination
- Caching responses
- Compressing responses
- URL rewriting
- And many other production use cases.
In order to get this I have to add a load balancer, and I find it is overkill for a single little MVP server (with built in ssl support) that will take time to get a lot of requests. Moreover, ocsigenserver supports compression, url rewritting, and ssl.
However, I am about to learn about how to set up NGINX to perform this because I have not that much alternative for now, thank you for giving me this (you are right, I will need it some day, I just prefer to launch things fast)
As long as ocsigenserver supports ssl, if someone has a clue on how to fix it, I still take it
Thanks a lot for your insight on nginx @yawaramin. I realize I could not appreciate how valuable was this advice at the time you gave it to me, but it is really what I needed.
For people that wonder (like I was) why one would set up a common reverse proxy like nginx for SSL/TLS stuff : because it is far more easier (or barely possible) to set a secure TLS suite and to keep it up to date than with ocsigenserver that lacks documentation about this (and probably some features), among other advantages.
Hi, it’s a nice coincidence–I recently wrote a post on common system architecture issues that I come across, and I even included a section on SSL termination which strongly echoes what you said: https://dev.to/yawaramin/reducing-system-complexity-by-adding-more-components-4607#segue-ssl-termination