Setting cookies onrender.com

1

Hey

I’m having problems setting cookies for my static web with the onrender.com domain. I’m assuming because of the public suffix list?

The setup is as following:

When admin ui sends a requests to api service the service responds with a cookie. That cookie is never set.

set-cookie: FRI_API=randomsession; Max-Age=2147483647; Domain=onrender.com; Path=/; Expires=Tue, 02 Jan 2091 13:36:05 GMT; HttpOnly; Secure; SameSite=Strict

Chrome gives: This attempt to set cookie via set-cookie header was blocked because its domain attribute was invalid with regards to the current host url

This works for localhost and our custom domains api.fri.is and admin.fri.is but not onrender.com

I’m fine with using the custom domains, BUT I have Preview Environments like fri-admin-pr-31.onrender.com where we need to test our features before merging the pull request. Right now our product manager and test users can’t log in to test new features.

Am I doing something wrong or is there a better way to achieve this?

2

Hi Bergur,

Yes, onrender.com being on the Public Suffix List will be the issue here.

I think if you set the domain to the full service domain (fri-admin-pr-31.onrender.com), cookies would be written. This would be available in the RENDER_EXTERNAL_HOSTNAME environmental variable if you needed it programmatically.

A workaround that may help here would be to use the Redirects and Rewrites feature of Static Sites to keep your API calls within the Static Site domain. Sometimes customers also use this technique to avoid CORS issues.

For example, assuming fri-admin-pr-31.onrender.com had a corresponding fri-api-pr-31.onrender.com you could set up a rewrite such as:

  • Source: /api/* Destination: https://fri-api-pr-31.onrender.com/* Action: Rewrite

This would need to be amended to match your required endpoints, and also need an update to the frontend to call /api/<endpoint>.

However, the last issue here would be being able to set this rewrite as part of the Preview Environment creation. I don’t think it’s currently possible to set rewrites dynamically with the render.yaml. In addition, creating rewrites is not currently available to the Public API, so that step may, unfortunately, need to be manual.

Hope that helps

Alan

3

Hi @al_ps and thank you for your help.

I tried your solution but

set-cookie:FRI_API=session; Max-Age=2147483647; Domain=admin.fri.is; Path=/; Expires=Tue, 02 Jan 2091 17:29:05 GMT; HttpOnly; Secure; SameSite=Strict

Gives the same error about being blocked because of domain. I’m guessing because the domain sending the cookie and the domain setting it are different and I have SameSite=Strict.

Cookies always confuse me. Even it I would be able to set it, it would not work, right? Because the domains are different. The api service is sending the cookie asking admin to set it. The static admin then ommunicates with the api using withCredentials (or include credentials, etc) - and again the domains wouldn’t match. The static site is asking api.onrender.com to use a cookie for admin.onrender.com

Am I misunderstanding you?

This sounds really good and would solve alot of my headache, but having to manually set it is kind of a dealbreaker.

How about custom domain for Preview Environments? Could I set up api-pr-31.fri.is ?

There must be a way, I can’t believe that I’m the first person using render preview environment with login/session?

I can change the code anyway you guys think would best match your environment. So any tip in the right direction would be greatly appreciated.

4

Your set-cookie example seems to show your custom domain, is that just a typo? I’d have to give it a try on one of my own projects to see if I could reproduce the issue.

There’s not currently a built-in way to set specific custom domains on previews, there is a feature request on our feedback site, which sounds similar: https://feedback.render.com/features/p/custom-domain-for-pull-request-preview. Feel free to upvote/comment to be notified of updates.

For custom domains, a workaround may be using the Preview Environment “initialDeployHook” to run when the preview env is created. Then have that script add a specific custom domain through the API and update your DNS provider, if they have API access. Or maybe just have something like *.previews.mydomain.com as an A record pointing to 216.24.57.1 and the custom domains like pr-123.previews.mydomain.com should resolve.

Alan

1 Like
5

Allright, I think I have all the information I need. I’ve been bombarding the community here, trying to get all the information. I’m gonna try some things out and see if I can get this all to work.

It seems that render.com is “this” close at offering everything a developer with a team would need, still some rough patches here and there but I’m looking forward to see how the next few months will turn out at render.

You and @John_B have been a great help. Do you guys have buymeacoffee or something similar?

6

Hey @al_ps and thanks again for all your help.

I decided to go the custom domain through api route.

I thought I finally nailed everything, when I get the following eror:
services[1] initialDeployHook is not supported for static sites

I need my static site and api to have custom domain for my previews so the authentication works.

So I go back to the drawing board and try to get the service id from the static site into the api service, since the api service can have a deploy hook and then set the custom domain

- key: ADMIN_RENDER_SERVICE_ID
  fromService:
    type: web
    name: fri-admin-test
    envVarKey: RENDER_SERVICE_ID

But I get this error.

image
image1051×115 13.1 KB

It seems that

How can I set up a custom domain for my static preview and api preview?

7

Hey sorry the bother @al_ps but have you had a chance to look at this?

I’m just trying to find a way to get custom domains on branch deployments to work for static sites. This worked for web service but can’t get it to work for static website.

  • inititalDeploymentHook is not available
  • can’t read the RENDER_SERVICE_ID from static-service.

Render.yaml file: monorepo/render.yaml at main · frjalsar/monorepo (github.com)

…and as my previous request, do you guys have a buymeacoffee or some tipping site where I could show my appreciation for all your help? :slight_smile:

8

Hi Bergur,

I’m sorry for not getting back to you sooner. I wanted to double-check my suggestions and try some stuff out.

The TL;DR; seems to be that a fully autonomous preview environment with your described setup may not be possible at this stage due to the features currently available. A workaround could be to use a Web Service instead of a Static Site

Approach 1: Using the default onrender.com domains with a rewrite to the backend to avoid CORS issues.

I spun up an absolutely bare-bones monorepo, with a Static Site client and a Node Web Service backend. The client just has an input to set the value of a cookie, then a fetch is made to the backend via a rewrite. Some basic console logging shows the cookie/value that was sent to express.

The only actual config I needed to do here, I think, was setting the cookie domain to the full RENDER_EXTERNAL_HOSTNAME, in my case, done with a simple sed in the build command, as I didn’t use a framework for the static HTML.

The problem with this approach is that the required rewrite (e.g. source: /api/*, destination: https://my-backend.onrender.com/*) cannot be set dynamically. Blueprints don’t support dynamic referencing (like envVars) for redirects/rewrites, and even if Static Sites did support initialDeployHook there’s no public API to update them currently.

In summary, it appears possible to use the default domain and set cookies as long as you use the full onrender domain name, but completely automating this approach with Blueprints is just out of reach currently.

Approach 2: Using custom domains

As you’ve found, the limiting factors here are custom domain blueprint declarations can’t be dynamic and initialDeployHook not being available on Static Sites.

Workaround

I’ve not tried it, but if the client site was served through a Web Service (e.g. Express serving the static files) you may have enough configuration available (initialDeployHook) to set the sites required.

I’ve also noted some of the limitations here to be raised internally.

Alan

1 Like
9

Thanks @al_ps for a very thorough answer

Both are semi-viable solutions, but like you mention fail when it comes to the preview environment.

In approach 1 I need to manually add a new rewrite for each pull request - since the cookie is fixed for the full domain
In approach 2 I need to manually add a custom domain for each pull request - since I can’t set custom domain programatically.

Approach 3 actually works automatically, but I loose on the cdn, network edges, cache, brotli compression, etc. and it costs more since I pay for web services and not static webs.

Regarding:

It seems to be that a fully autonomous preview environment with your described setup may not be possible at this stage due to the features currently available*

I got fixated on “your described setup” - Is there another setup that might work? I’m new to Render but I’m planning on moving all my personal and professional projects here so nothing is set in stone for me. Ideally the only thing I would want is

  • Preview environment / branch deployment where dev team can test their code.
  • Test/staging environment where the customer can see the feature/changes.
  • Production where is everything is stable

I’m open to any solution/setup if its my setup that is breaking things. E.g I’ll adjust to Render than trying to force/bend Render to my will.

Again, thanks for all the help. If you guys ever visit Iceland I’ll buy you guys some beer or coffee.

10

I don’t think we currently have a bulletproof answer for a distinct environment pipeline set up. It’s something we’re very aware of, and improving workflows for this type of project set up is definitely on the roadmap.

My colleague John wrote quite a detailed post on possible environment approaches with the current feature set: https://community.render.com/t/suggestions-how-to-have-a-permanent-staging/7280/2

Alan

1 Like
11

Thanks. That’s exactly the same setup I ended up with! :D…but as mentioned it has some shortcomings. Overall no biggie, could be a tad cleaner/smoother. I’ve seen on the community here that this is something Render is aware of. So I’m looking very much of seeing the what Render has in store for us over the next year or so.

Thanks again for going back and forth with me on this.

12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.