Hello Render Community!
This is my first time trying to host web services through render and have experienced a very interesting phenomena.
I come from a heroku background, and thought I was familiar with how public prefix’s can effect cookie writing to the browser, making it sometimes painful. But render I think has something funky going on when you introduce a docker container in your setup.
My current setup consists of 2 web services, one for my server and one for the ui. My server is written in kotlin, compiled down with gradle and dockerized. My UI is written in solidJS and uses the fetch API to communicate with the server. So far, everything has been going as planned, and I have to say I’m really impressed with how easy it is setting up dockerized webservices.
So… Whats happening?
When a user enters the landing page of my application, my server will automatically try to assign an anonymous cookie to the browser that eventually gets traded out for a authenticated cookie.
This is the cookie writing logic on my kotlin server (Sorry for the messy test code).
Here, when I’m in production (on render), I use the external_hostname env variable provided by render to dynamically set the domain for the cookie. Which is working, because when I check the Set-Cookie header in the network request, its there, with no yellow triangle for debugging. But only for the first request after a fresh reboot from a new browser.
override fun default(): CookieBuilder<Cookie> {
val prod = System.getenv("APP_ENV") == "prod"
val domain = if (prod) System.getenv("RENDER_EXTERNAL_HOSTNAME") else "localhost"
logger.info("Cookie Settings: [prod=${System.getenv("APP_ENV")}, domain=$domain, secure=$prod]")
logger.info("Render ENV Domain ${System.getenv("RENDER_EXTERNAL_HOSTNAME")}")
cookie?.run {
setAttribute(CookieHeaderNames.PATH, "/")
setAttribute(CookieHeaderNames.DOMAIN, domain)
setAttribute(CookieHeaderNames.SECURE, "$prod")
setAttribute(CookieHeaderNames.HTTPONLY, "true")
if (prod)
setAttribute(CookieHeaderNames.SAMESITE, "none")
}
return this
}
This is the fetch config for my UI, fairly straight forward:
const baseURL = env.isProd()
? "https://athl33t-server.onrender.com"
: "http://localhost:8080";
const config: RequestInit = {
credentials: "include",
mode: "cors",
};
Now what I semi-expected was to be battling with the public prefix for the render domains because I’ve seen a couple threads regarding the prefix being the problem.
However, after recieving no error in the Network tab, or in the Response Headers on the Set-Cookie value, the cookie is still not appearing in my application’s properties.
When this happened, I figured it was because the cookie was not being written anywhere, But I was wrong…
When I reloaded the page, I noticed any subsequent requests did not have the Set-Cookie header, and my server was not attempting to set any anonymous cookies. Which was weird…
I added some logging logic to my server and discovered that there is infact a cookie being written somewhere inbetween the browser, and the dockerized container. This cookie is obtainable via request.cookies in my server, and when I log it’s value, it’s not constantly being re-assigned. it’s always the same cookie, which is throwing me for a loop, and I suspect it may have something to do with how the docker networks are pre-configured.
Is this normal behaviour? or have I stumbled across something weird… again…
And if this is normal behaviour will I be okay to develop as is and expect synonymous behavior when I’m done and register my actual domain to the website?
Just thought I’d pop this thread open incase anyone else ran into similar discoveries,
Best Regards,
Thomas Shank