Seeing "`Authorization` header is not valid" after deploying to render.com

Get Help and Help Others
1

Hey everybody,

I’ve seen a lot of value already from working with redwoodjs even though I’m still pretty new (just started using it in January). Unfortunately, I recently ran into a bug after migrating from netlify to render.com.

After deploying to render, many of my graphql calls started receiving Error: Something went wrong. as a response. When a call receives that response, I notice that the render.com api logs this message:

{"level":50,"time":1646040112551,"pid":68,"hostname":"<hostname>","name":"graphql-server","msg":"Error building context. Error: Exception in getAuthenticationContext: The `Authorization` header is not valid."}

The weird thing is, sometimes these calls succeed and sometimes they fail. I have no idea why! I’m assuming there must be some race conditions at play that result in authorization header being set sometimes, and not other times.

I’ve followed all instructions here (Deploy RedwoodJS | Render · Cloud Hosting for Developers) and configured a DBAUTH_COOKIE_DOMAIN as per instructions here. If anyone has run into an error like this in the past or knows where I should keep looking that would be so helpful!

This is my site for reference: https://wavepoolmvp-web.onrender.com/

To see the error I’m getting on the site (though it won’t be too descriptive) you may have to refresh a few times.

2

I have also been fighting these two off and on, here is some reading that may help

Can’t get Past “Something Went Wrong”

The Authorization header is not valid

The real issue for me is the latter – and the teams on it :slight_smile:

If you are new to Redwood you may benefit from this new video

Welcome, I say, Welcome!

Al;

Redwood Rules!
3

Thanks @ajoslin103! Glad to know I’m not alone in this!

I’ve noticed that I get this error after the user is authenticated (which happens automatically in my application after a few seconds) but not when the user is unauthenticated (first few seconds after loading). Have you seen a pattern like this as well?

4

After reading the issue you linked above (which stated that some see this error shortly after logging out then logging back in) I’m wondering if perhaps the issue for me is caused by how I’ve set up my code.

For some reason, every time I make a graphql request, I also make an auth request. I wasn’t sure if this was normal/desirable or why my code was doing it, so I’ve been ignoring it for the last couple weeks. Do you know why a RedwoodJS app might make this request so often (if it’s normal) and does this seem like it could be related?

5

If you’re using dbAuth this is the intended behavior: no auth information is stored locally in the client (other than any useState you may add yourself), so for every useAuth call in the front end it’ll need to ask the server if you’re who you say you are—it sends up an encrypted cookie, the server decrypts it and makes sure it wasn’t tampered with, then returns whatever you have set to be returned in getCurrentUser() in api/src/lib/auth.js.

With the third party auth solutions, a bunch of user data is stored locally in the browser in LocalStorage and then you’re given a refresh token that expires after a set amount of time (I think Netlify’s default is 6 hours). That means you only need to go back to the server once every 6 hours to make sure the person is who they say they are (the client trusts LocalStorage to be correct). But a lot can happen in 6 hours! For example, If you need to lock out or ban a user, or their role/permissions change, nothing will happen on their end until that refresh token expires and the client asks the server for a new one.

In theory, dbAuth could be extended to work in a similar way and give you the option of storing some user data locally and trusting it for a set period of time before it expires. This isn’t currently on our roadmap but if someone wanted to take a crack at adding it, we’d be all ears! If that sounds like you, please open an Issue on the repo and make a proposal so that we can discuss and come up with a way forward.

6

That may not be a bad idea! It would cut down on the total number of function calls the site makes (which I know at least netlify sets limits on). Could be a cool contribution for me to make! At the moment I’m still pretty focused on just getting this site up and running on render.com.

@rob I know you’re something of an expert on dbAuth, which may or may not help with a problem I’m experiencing.

As discussed above, my app makes a lot of auth?method=getToken calls to the auth function. Usually, the response to these requests looks like this: random-generated-string-a0e6-ea80f6c25263. Sometimes, for reasons unknown to me, the response looks like this instead:

<!doctype html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width,initial-scale=1" />
  <link rel="icon" type="image/png" href="/favicon.png" />
  <script defer="defer" src="/static/js/runtime-app.e59ba053.js"></script>
  <script defer="defer" src="/static/js/app.6e16fb97.js"></script>
  <link href="/static/css/app.b16205e2.css" rel="stylesheet">
</head>
<body>
  <div id="redwood-app">
    <server-markup></server-markup>
  </div>
</body>
</html>

Do you (or does anyone else) have a clue why I might be seeing this response? It looks like I’m getting my own site back as a response instead of a bearer token.

7

Hmm, I don’t recall ever seeing that in my own stuff (and I exclusively use dbAuth). Are you seeing this in development, or only when deployed? And do you get this only when logged in, or when logged out as well?

It seems like the request is going to the web-side and not the api-side as it’s returning the HTML to start up the app in the client. If this is only on Render: when you look at the full URL for the auth?method=getToken call, can you see that it’s going to API server endpoint each time? I would expect this response if that call went to the web-side server: it would always respond with this HTML to any URL, and then once the JS is up and running it would determine whether that’s a valid page or not (it’s not) and show you a 404.

8

Someone else said this:

I’m trying to deploy to Heroku and I’m hitting a snag. The deployment is live and is being served just fine but hitting my API doesn’t seem to be working. The response that I get back from my call to currentUser is a blank HTML file with this markup in the middle:

<div id="redwood-app"><server-markup></server-markup></div>

any ideas?

The person never got any helpful replies. But at least we know it’s not a render.com only problem.

9

Thank you both so much for looking at this one with me. The weird thing is, I deleted my deployed instances in render.com and redeployed the last night and the problem is… gone. I have a theory as to what was happening and a theory as to why it is now fixed, but first let me respond to what you’ve said.

@rob in answer to your questions, I only saw this when deployed (never in development). I only ran into these problems when logged in (at least that I noticed). I don’t have a chance anymore to look at the faulty auth?method=getToken calls anymore, but I do think that my request was getting processed by the frontend.

@Tobbe hmm that is strange. I wonder if that response contains their index.html.

Now as for my theories:

Why did I see this problem before?
When I initially deployed to render.com, the deployment for my api functions failed, and that confused me. I started messing around with DBAUTH_COOKIE_DOMAIN and cors and a few other things, trying to get render.com to serve my services correctly. Among the things I tried was updating my render.yaml file to contain this rewrite, as instructed on their site (Deploy RedwoodJS | Render · Cloud Hosting for Developers):

 routes:
  - type: rewrite
    source: /.redwood/functions/*
    destination: https://wavepoolmvp-api.onrender.com/*

The full redirect/rewrite logic for my site looks like this:

routes:
  - type: rewrite
    source: /.redwood/functions/*
    destination: https://wavepoolmvp-api.onrender.com/*
  - type: rewrite
    source: /*
    destination: /index.html

After noticing that my index.html file was being served as an authorization bearer, that second rewrite to /index.html caught my eye. My theory as to what was happening is this: sometimes (not sure why or what triggered it) the first rewrite to my api server failed and the second one was activated.

This seemed to be random and I didn’t notice any pattern between requests that were successfully routed to my api and requests that were rewritten to /index.html. It seemed to affect about half of auth?method=getToken requests and none of my other requests.

What fixed it?
First off, I want to say that I don’t know it’s fixed. I guess I won’t know until I and many others have used my site for a while without issue. But I have tested it on different devices in different browsers and haven’t seen this glitch once.

All that I did was completely delete my previous instances for my whole project on render.com (web, api, and db) and redeploy them. I had to upgrade my api instance to starter plus again for the extra RAM (annoying), but beyond that it was just a simple deploy. And everything worked! No DBAUTH_COOKIE_DOMAIN or cors configuration or anything.

Conclusion
Hopefully this is all in the past and others who have issues with this when deploying to render.com can learn from my mistakes. Thank you so much for looking at this with me. If I run in to more bugs with this I’ll update the thread.

Here’s my website if you’re interested: https://wavepool.events

2 Likes
10

That is strange. I wonder if their routes are set up incorrectly so that currentUser ends up calling /index.html.

11

Thanks for the update! That sounds plausible as it sure seemed like it was just returning the default web response for those requests. Kind of scary that their rewrite rules would be non-deterministic though! And that wiping out the site and re-deploying would fix it??

1 Like
12

Yeah, still hasn’t cropped up again and I hope it doesn’t!

13

In Discord me and Bora were chatting about a similar issue. That discussion he linked here. So for anyone else who comes across this what seemed to fix it for me was changing my version to 3.2.0 via yarn rw upgrade --tag 3.2.0 I was on 3.5.0 and 3.7.1 when I saw the issue.

That being said I’d love to be able to test the build and redirects locally for Render, but I’m not sure if thats possible (Didn’t really look into it.)

@dcorbitt, do you happen to know what version of redwood you were on when you noticed this?