2

I have a Loopback 3 app with a PGSQL database. Certain enpoints require authorization in the form of a JWT token. The token is generated by a separate service written in PHP and is usually sent to loopback as a Authorization Bearer header. Every now and then, a new token will cause the entire app to break with this error: 

error: invalid byte sequence for encoding \"UTF8\": 0x00
    at Connection.parseE (C:\...\node_modules\pg\lib\connection.js:545:11)
    at Connection.parseMessage (C:\...\node_modules\pg\lib\connection.js:370:19)
    at Socket.<anonymous> (C:\...\node_modules\pg\lib\connection.js:113:22)
    at Socket.emit (events.js:160:13)
    at addChunk (_stream_readable.js:269:12)
    at readableAddChunk (_stream_readable.js:256:11)
    at Socket.Readable.push (_stream_readable.js:213:10)
    at TCP.onread (net.js:602:20)

This will happen whenever the authorization header is present, even if the endpoint does not require authorization. There is user role that validates this token against a different service, but this is never called for endpoints that don't require it, so it's not there. What usually works is generating a new token of the same length. Then the app starts responding again. Here's a sample of a token 

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOjIsImlzcyI6Imh0dHA6Ly9leGFtcGxlLm9yZy9hcGkvYXV0aGVudGljYXRlIiwiaWF0IjoxNTIzMzk5Mjk4LCJleHAiOjE1MjM0MTAwOTgsIm5iZiI6MTUyMzM5OTI5OCwianRpIjoiYjBhZDZmOGQ2NWY2MWUwYTMzZmNmZWNmYTI0YTA2M2EifQ.nHYlfX7vkVU8NIioYfqSSAHGj1y2OyGhhmEazU-wCTY

I've searched for \0 characters in the "bad" tokens and found nothing. I don't know why the token would even come near the pg lib, there's nothing trying to store it. All other posts I've found about this error are usually about trying to insert invalid characters to the DB, which is not what I'm doing here.

I have tried looking at the files in the stack trace but have no idea where the issue could be and how to avoid it. I was thinking of intersecting the token somehow and trimming trailing \0 but don't know where either. Any help?

Vic
  • 2,655
  • 3
  • 18
  • 28
  • Loopback will resolve the token into a userId for every request, so it is likely submitting the query `SELECT * from schema.access_token where access_token = $1` and that's what making the pg library mad. What php service is generating the tokens? –  Apr 11 '18 at 18:02
  • A Laravel App that's in charge of most of the business logic. I use this library: https://github.com/tymondesigns/jwt-auth I didn't know about that, that makes complete sense. Would it be possible to override this behaviour somehow? We don't use the ``access_token`` table. – Vic Apr 11 '18 at 18:32
  • If you don't use the `access_token` table then how do you authenticate? Or are you saying that the endpoint needs authentication, but loopback isn't responsible for it? –  Apr 11 '18 at 18:39
  • Yes, I'm not using loopback authentication. I validate the token against a different service. I don't have a users table either. – Vic Apr 11 '18 at 19:36
  • I don't know how to solve the problem of you having a `\0` in your token, but removing/commenting out the `authentication.js` script in your `server/boot` folder will stop loopback from attempting to resolve tokens for each request. –  Apr 11 '18 at 19:51
  • Oh, yes, it was enabled. I thought it wouldn't be on by default. I've been running a few tests and it seems it's now working! Thanks a lot man, feel free to write an answer with that so I can mark it as the answer. – Vic Apr 11 '18 at 20:22

1 Answers1

0

In my case, my server.js script was using the token() middleware :( After removing it, Loopback stopped triggering an AccessToken query to the DB.

app.use(loopback.token());

cluisalvarado
  • 13
  • 1
  • 5