Failed to initialize OAuth2 support: Error 1071: Specified key was too long; max key length is 767 bytes #1739

New Issue

GiteaMirror · 2025-11-02T04:11:47-06:00

GiteaMirror commented

2025-11-02 04:11:47 -06:00

Originally created by @silverwind on GitHub (Apr 29, 2018).

Gitea version (or commit ref): 7ea4bfc561
Git version: 2.17.0
Operating system: Linux
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant

Description

After updating to today's master, I got the mentioned error related to commit 5a62eb30df. Database is MariaDB 10.1.32 with default character set utf8mb4. Reverting the commit fixes the error.

CC: @lafriks.

Originally created by @silverwind on GitHub (Apr 29, 2018). - Gitea version (or commit ref): https://github.com/go-gitea/gitea/commit/7ea4bfc56172faf588142ee5637f35c0344f7534 - Git version: 2.17.0 - Operating system: Linux - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant ## Description After updating to today's master, I got the mentioned error related to commit https://github.com/go-gitea/gitea/commit/5a62eb30df3a04e76e465824f525b4ffd920b562. Database is MariaDB 10.1.32 with default character set utf8mb4. Reverting the commit fixes the error. CC: @lafriks.

GiteaMirror closed this issue

2025-11-02 04:11:47 -06:00

GiteaMirror commented

2025-11-02 04:11:48 -06:00

@lunny commented on GitHub (Apr 29, 2018):

utf8mb4 is not supported currently

@lunny commented on GitHub (Apr 29, 2018): utf8mb4 is not supported currently

GiteaMirror commented

2025-11-02 04:11:48 -06:00

@silverwind commented on GitHub (Apr 30, 2018):

Which of these should I change to support gitea? (They are all at their default)

localhost> show variables like '%character_set%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | utf8mb4                    |
| character_set_filesystem | binary                     |
| character_set_results    | utf8                       |
| character_set_server     | utf8mb4                    |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+

GiteaMirror commented

2025-11-02 04:11:48 -06:00

@silverwind commented on GitHub (Apr 30, 2018):

Tracked the issue down to this line which defines a indexed VARCHAR(400). Is it an option to change that to VARCHAR(191)? Note that my other tables use the old utf8 charset, not sure why it's attempting to use utf8mb4 on this table.

@silverwind commented on GitHub (Apr 30, 2018): Tracked the issue down to [this line](https://github.com/lafriks/xormstore/blob/3a80a383a04b29ec2e1bf61279dd948aa809335b/xormstore.go#L73) which defines a indexed `VARCHAR(400)`. Is it an option to change that to `VARCHAR(191)`? Note that my other tables use the old `utf8` charset, not sure why it's attempting to use `utf8mb4` on this table.

GiteaMirror commented

2025-11-02 04:11:48 -06:00

@silverwind commented on GitHub (Apr 30, 2018):

Found a workaround from https://github.com/go-gitea/gitea/pull/3516#issuecomment-366648794:

innodb_file_format = Barracuda
innodb_large_prefix = 1
innodb_default_row_format = dynamic

In summary, mariadb < 10.2 and mysql < 5.7 don't support longer indexed colums by default. above setting apply the settings that are default on newer versions. I realize that upgrading mariadb would be the proper solution, but the Arch package still seems to be stuck on 10.1 and I don't want to compile it myself.

@silverwind commented on GitHub (Apr 30, 2018): Found a workaround from https://github.com/go-gitea/gitea/pull/3516#issuecomment-366648794: ``` innodb_file_format = Barracuda innodb_large_prefix = 1 innodb_default_row_format = dynamic ``` In summary, mariadb < 10.2 and mysql < 5.7 don't support longer indexed colums by default. above setting apply the settings that are default on newer versions. I realize that upgrading mariadb would be the proper solution, but the [Arch package](https://www.archlinux.org/packages/extra/x86_64/mariadb/) still seems to be stuck on 10.1 and I don't want to compile it myself.

GiteaMirror commented

2025-11-02 04:11:48 -06:00

@drsect0r commented on GitHub (Apr 30, 2018):

Found another workaround, create the table manually with an adjusted primary index length.

CREATE TABLE `oauth2_session` (
  `id` varchar(400) NOT NULL,
  `data` text,
  `created_unix` bigint(20) DEFAULT NULL,
  `updated_unix` bigint(20) DEFAULT NULL,
  `expires_unix` bigint(20) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

ALTER TABLE `oauth2_session`
  ADD PRIMARY KEY (`id`(191));
COMMIT;

@drsect0r commented on GitHub (Apr 30, 2018): Found another workaround, create the table manually with an adjusted primary index length. ```sql CREATE TABLE `oauth2_session` ( `id` varchar(400) NOT NULL, `data` text, `created_unix` bigint(20) DEFAULT NULL, `updated_unix` bigint(20) DEFAULT NULL, `expires_unix` bigint(20) DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8; ALTER TABLE `oauth2_session` ADD PRIMARY KEY (`id`(191)); COMMIT; ```

GiteaMirror commented

2025-11-02 04:11:48 -06:00

@thehowl commented on GitHub (May 1, 2018):

@drsect0r you don't need the second query. The first one will be fine, the problem is the fact that our mariadb installs use utf8mb4 as the default charset - and in this case it leads to problem. The solution is simply to create the table with utf8 instead of utf8mb4 - so the first query will suffice.

This issue will probably create problems for other users who want to upgrade and have this kind of setup. I've created https://github.com/lafriks/xormstore/issues/5 for this reason.

@thehowl commented on GitHub (May 1, 2018): @drsect0r you don't need the second query. The first one will be fine, the problem is the fact that our mariadb installs use utf8mb4 as the default charset - and in this case it leads to problem. The solution is simply to create the table with utf8 instead of utf8mb4 - so the first query will suffice. This issue will probably create problems for other users who want to upgrade and have this kind of setup. I've created https://github.com/lafriks/xormstore/issues/5 for this reason.

GiteaMirror commented

2025-11-02 04:11:49 -06:00

@silverwind commented on GitHub (May 1, 2018):

create the table with utf8 instead of utf8mb4

Wouldn't that still be longer than that 767 bytes limit of old InnoDB? VARCHAR(400) should amount to up to 1200 bytes of storage as utf8 (aka utf8mb3).

@silverwind commented on GitHub (May 1, 2018): > create the table with utf8 instead of utf8mb4 Wouldn't that still be longer than that 767 bytes limit of old InnoDB? `VARCHAR(400)` should amount to up to 1200 bytes of storage as `utf8` (aka `utf8mb3`).

GiteaMirror commented

2025-11-02 04:11:49 -06:00

@thehowl commented on GitHub (May 3, 2018):

Yes, it looks like I didn't add the primary key in the end 🤦‍♂️ You are indeed right - the maximum you can go with the 767 bytes and utf8 limit is 255 characters.

@thehowl commented on GitHub (May 3, 2018): Yes, it looks like I didn't add the primary key in the end :man_facepalming: You are indeed right - the maximum you can go with the 767 bytes and utf8 limit is 255 characters.

GiteaMirror referenced this issue

2025-11-02 12:00:32 -06:00

[PR #1739] [MERGED] Display all organization from user settings #16024

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#1739