question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Unable to authenticate, "The provided value for the column is too long for the column's type"

See original GitHub issue

Environment

System:
    OS: macOS 12.3.1
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
    Memory: 47.16 GB / 64.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.13.0 - ~/.nvm/versions/node/v16.13.0/bin/node
    Yarn: 1.22.17 - /usr/local/bin/yarn
    npm: 8.1.0 - ~/.nvm/versions/node/v16.13.0/bin/npm
  Browsers:
    Brave Browser: 99.1.36.119
    Chrome: 102.0.5005.115
    Firefox: 99.0.1
    Safari: 15.4
  npmPackages:
    next: 12.1.5 => 12.1.5 
    next-auth: ^4.3.4 => 4.3.4 
    react: 17.0.2 => 17.0.2 

Reproduction URL

http://ping.gg

Describe the issue

We had a user try to log in this morning and they were unable, and kept hitting an auth error.

Upon checking the logs, we found this error:

https://next-auth.js.org/errors#adapter_error_linkaccount The provided value for the column is too long for the column's type. Column: for {
  message: "The provided value for the column is too long for the column's type. Column: for",
  stack: "Error: The provided value for the column is too long for the column's type. Column: for\n" +
    '    at RequestHandler.request (/var/task/node_modules/@prisma/client/runtime/index.js:49022:15)\n' +
    '    at async PrismaClient._request (/var/task/node_modules/@prisma/client/runtime/index.js:49919:18)',
  name: 'Error'
}

The only thing out of the ordinary about this user’s email was that it had a pretty long / multi-part domain (@history.ucla.edu).

How to reproduce

We have been unable to reproduce this since the user ran into the issue in production this morning. We would greatly appreciate any assistance in sorting out what happened here.

Expected behavior

User should be able to log in.

Issue Analytics

  • State:open
  • Created a year ago
  • Reactions:2
  • Comments:5 (3 by maintainers)

github_iconTop GitHub Comments

6reactions
hussamkhatibcommented, Jul 13, 2022

I also had the same issue with google auth despite having Text type on id_token as you had too. The logs helped me where it broke. line 18

linkAccount: (data) => {
  console.log(data);
  return p.account.create({ data });
},

I found out the access_token is above 200 characters, I made it to Text type as well and it solved the issue for me.

model Account {
  access_token       String? @db.Text
  id_token           String? @db.Text
}
4reactions
zenflowcommented, Jun 21, 2022

@markflorkowski I came into this issue yesterday, and was digging into it already…

So here’s what I know:

  1. Basic issue is that the default schemas for most of the adapters use VARCHAR(255) (length limited to 255 characters) instead of TEXT (unlimited length) for string fields
  2. This seems to be a frequent issue with the id_token field when using the Google provider:
  3. 255 characters may not always be enough in some other cases
    • access_token and or refresh_token /w Google provider (see https://developers.google.com/identity/protocols/oauth2#size) (does anyone know where in the next-auth schema we find the “Authorization codes” that the linked page talks about?)
    • scope if you’re requesting more scopes than the default ones (e.g. with Google provider and default scopes, the scope field is already 102 bytes: openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/userinfo.profile)
    • session_state if used (if your session strategy is "database) can easily be more than 255 bytes if you’re adding properties to your session object
  4. PR to fix the issue, but just for the TypeORM adapter and just for the id_token field: #336

The workaround has been presented: Change the field type of id_token (or whatever field doesn’t have enough room… I suggest doing it for all string fields) from VARCHAR(255) to TEXT.

  • For the next-auth ORM models: Refer to docs for your adapter and look for a heading like “Custom models”.
  • For your underlying db schema: Do some db migration to ALTER the fields

@markflorkowski Can I ask, what Provider(s) and what Adapter you are using?

Read more comments on GitHub >

github_iconTop Results From Across the Web

What is the MySQL error: “Data too long for column”?
The “Data too long for column” error occurs when you insert more data for a column that does not have the capability to...
Read more >
mysql - "Data too long for column" - why? - Stack Overflow
One of the tables, Department, has a column named Description, which is declared as type varchar(200). When executing the INSERT command for Description...
Read more >
Troubleshoot connector and format issues in mapping data flows
Learn how to troubleshoot data flow problems related to connector and format in Azure Data Factory.
Read more >
Common Problems | TeamCity On-Premises Documentation
Build works locally but fails or misbehaves in TeamCity ... Packet for query is too large) is caused by the server-side max_allowed_packet ...
Read more >
11.3.4 The BLOB and TEXT Types - MySQL :: Developer Zone
Because BLOB and TEXT values can be extremely long, you might encounter some constraints in using them: Only the first max_sort_length bytes of...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found