github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 02:24:21 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Azure AD/Oauth2 - Link External Account operation fails due to MS SQL database error. #10901

New Issue
Open
opened 2025-11-02 09:21:36 -06:00 by GiteaMirror · 19 comments
GiteaMirror commented 2025-11-02 09:21:36 -06:00
Owner
Copy Link

Originally created by @abjoseph on GitHub (May 23, 2023).

Description

When attempting to Link an external account as shown in the screenshot below (1st screenshot), I'm getting a HTTP 500 error (2nd screenshot). Upon looking at the logs, I found the following:

May 23 23:04:22 gitea gitea[1975042]: 2023/05/23 23:04:22 ...rs/web/auth/oauth.go:929:SignInOAuthCallback() [E] [646d4676-2] UserLinkAccount: mssql: String or binary data would be truncated.

Edit/Update: I tested the exact same setup with a MySQL and SQLite database, and it worked as expected. The issue has been narrowed down to some configuration issue when Gitea is backed by a MS SQL database.

Gitea Version

1.19.3

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

1st Screenshot

image

2nd Screenshot

image

Git Version

2.40.0

Operating System

Ubuntu 20.04.6 LTS

How are you running Gitea?

Gitea is ran as a service per the docs:

[Service]
# Modify these two values and uncomment them if you have
# repos with lots of files and get an HTTP error 500 because
# of that
###
#LimitMEMLOCK=infinity
#LimitNOFILE=65535
RestartSec=5s
Type=simple
User=git
Group=git
WorkingDirectory=/var/lib/gitea/
# If using unix socket: Tells Systemd to create /run/gitea folder to home gitea.sock
# Manual cration would vanish after reboot.
#RuntimeDirectory=gitea
ExecStart=/usr/local/bin/gitea web -c /etc/gitea/app.ini -p 3000
Restart=always
Environment=USER=git HOME=/home/git GITEA_WORK_DIR=/var/lib/gitea
# If you want to bind Gitea to a port below 1024, uncomment
# the two values below, or use socket activation to pass Gitea its ports as above
###
#CapabilityBoundingSet=CAP_NET_BIND_SERVICE
#AmbientCapabilities=CAP_NET_BIND_SERVICE
###

[Install]
WantedBy=multi-user.target

Database

MSSQL

Originally created by @abjoseph on GitHub (May 23, 2023). ### Description When attempting to Link an external account as shown in the screenshot below (1st screenshot), I'm getting a HTTP 500 error (2nd screenshot). Upon looking at the logs, I found the following: ```bash May 23 23:04:22 gitea gitea[1975042]: 2023/05/23 23:04:22 ...rs/web/auth/oauth.go:929:SignInOAuthCallback() [E] [646d4676-2] UserLinkAccount: mssql: String or binary data would be truncated. ``` ***Edit/Update:*** I tested the exact same setup with a MySQL and SQLite database, and it worked as expected. The issue has been narrowed down to some configuration issue when Gitea is backed by a MS SQL database. ### Gitea Version 1.19.3 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots ### 1st Screenshot ![image](https://github.com/go-gitea/gitea/assets/26844547/854d4c36-9196-46cb-872b-0aa29847260f) ### 2nd Screenshot ![image](https://github.com/go-gitea/gitea/assets/26844547/881675b3-3340-4af0-bc88-b9dbce60e246) ### Git Version 2.40.0 ### Operating System Ubuntu 20.04.6 LTS ### How are you running Gitea? Gitea is ran as a service per the docs: ```service [Service] # Modify these two values and uncomment them if you have # repos with lots of files and get an HTTP error 500 because # of that ### #LimitMEMLOCK=infinity #LimitNOFILE=65535 RestartSec=5s Type=simple User=git Group=git WorkingDirectory=/var/lib/gitea/ # If using unix socket: Tells Systemd to create /run/gitea folder to home gitea.sock # Manual cration would vanish after reboot. #RuntimeDirectory=gitea ExecStart=/usr/local/bin/gitea web -c /etc/gitea/app.ini -p 3000 Restart=always Environment=USER=git HOME=/home/git GITEA_WORK_DIR=/var/lib/gitea # If you want to bind Gitea to a port below 1024, uncomment # the two values below, or use socket activation to pass Gitea its ports as above ### #CapabilityBoundingSet=CAP_NET_BIND_SERVICE #AmbientCapabilities=CAP_NET_BIND_SERVICE ### [Install] WantedBy=multi-user.target ``` ### Database MSSQL
GiteaMirror added the issue/confirmedtype/bugissue/workaround labels 2025-11-02 09:21:36 -06:00
GiteaMirror commented 2025-11-02 09:21:37 -06:00
Author
Owner
Copy Link

@abjoseph commented on GitHub (May 28, 2023):

@GiteaBot Is anyone available to confirm my report and look into this?

@abjoseph commented on GitHub (May 28, 2023): @GiteaBot Is anyone available to confirm my report and look into this?
GiteaMirror commented 2025-11-02 09:21:37 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (May 29, 2023):

GiteaBot doesn't have ability to do that ....

Could it be caused by some of these information from your external account is too long?

image

@wxiaoguang commented on GitHub (May 29, 2023): GiteaBot doesn't have ability to do that .... ---- Could it be caused by some of these information from your external account is too long? ![image](https://github.com/go-gitea/gitea/assets/2114189/e2b47b94-c0cc-448d-a412-34658eaaaac8)
GiteaMirror commented 2025-11-02 09:21:37 -06:00
Author
Owner
Copy Link

@abjoseph commented on GitHub (May 29, 2023):

Hi @wxiaoguang, that is entirely possible, but I also tested the exact same setup with both SQLite and MySQL and both worked as-is without any issue. Given that the setup works with other supported databases, shouldn't we be adjusting MSSQL configuration to match Gitea's requirements that is already present in other DBMS? If not, then I don't think we can honestly list MSSQL as a fully supported database.

@abjoseph commented on GitHub (May 29, 2023): Hi @wxiaoguang, that is entirely possible, but I also tested the exact same setup with both SQLite and MySQL and both worked as-is without any issue. Given that the setup works with other supported databases, shouldn't we be adjusting MSSQL configuration to match Gitea's requirements that is already present in other DBMS? If not, then I don't think we can honestly list MSSQL as a ***fully*** supported database.
GiteaMirror commented 2025-11-02 09:21:37 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (May 29, 2023):

I just would like to confirm that it's caused by the "length limitation".

If there is a clear clue for the bug, then there could be a fix for it. Otherwise I am not using MSSQL, so I haven't spent time on reproducing it .....

@wxiaoguang commented on GitHub (May 29, 2023): I just would like to confirm that it's caused by the "length limitation". If there is a clear clue for the bug, then there could be a fix for it. Otherwise I am not using MSSQL, so I haven't spent time on reproducing it .....
GiteaMirror commented 2025-11-02 09:21:38 -06:00
Author
Owner
Copy Link

@abjoseph commented on GitHub (May 29, 2023):

@wxiaoguang, understood. Which table are these fields in? I'll take a look and experiment with what might be causing the error. Also, do you know if there is a way to have the logs show more information other than what I included in the initial post?

@abjoseph commented on GitHub (May 29, 2023): @wxiaoguang, understood. Which table are these fields in? I'll take a look and experiment with what might be causing the error. Also, do you know if there is a way to have the logs show more information other than what I included in the initial post?
GiteaMirror commented 2025-11-02 09:21:38 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (May 29, 2023):

The table name is external_login_user.

To get more logs: https://docs.gitea.com/help/seek-help , section 2 : logs.

@wxiaoguang commented on GitHub (May 29, 2023): The table name is `external_login_user`. To get more logs: https://docs.gitea.com/help/seek-help , section 2 : logs.
GiteaMirror commented 2025-11-02 09:21:38 -06:00
Author
Owner
Copy Link

@abjoseph commented on GitHub (May 29, 2023):

@wxiaoguang. Ok, so I found the discrepancy and the source of the issue. As your screenshot above shows, the access_token, access_token_secret and refresh_token are each configured with the text datatype which in mysql which gives a maximum length of 65,535 characters. However, in MSSQL those same fields are configured with varchar(255) as shown below and that size limitation causes an issue for the access_token, which appears to be a JWT token and is much larger than 255 characters.

image

P.S - Also, we might want to consider improving or at the very least, adding a line entry from the functions that initiate the DB calls. I say this because, despite enabling "LOG_SQL=true", I didn't get any additional output or info. This was confirmed when I was digging through the code for the location of the db call that writes to this table, I noticed that it simply returns the error. I know this is more or less idiomatic go coding style but it sometimes makes for harder debugging.

@abjoseph commented on GitHub (May 29, 2023): @wxiaoguang. Ok, so I found the discrepancy and the source of the issue. As your screenshot above shows, the `access_token`, `access_token_secret` and `refresh_token` are each configured with the `text` datatype which in mysql which gives a maximum length of 65,535 characters. However, in MSSQL those same fields are configured with `varchar(255)` as shown below and that size limitation causes an issue for the access_token, which appears to be a JWT token and is much larger than 255 characters. ![image](https://github.com/go-gitea/gitea/assets/26844547/ce5d5dcb-393d-400a-8e43-82421942255b) P.S - Also, we might want to consider improving or at the very least, adding a line entry from the functions that initiate the DB calls. I say this because, despite enabling "LOG_SQL=true", I didn't get any additional output or info. This was confirmed when I was digging through the code for the [location of the db call](https://github.com/go-gitea/gitea/blob/release/v1.19/models/user/external_login_user.go#L113) that writes to this table, I noticed that it simply returns the error. I know this is more or less idiomatic go coding style but it sometimes makes for harder debugging.
GiteaMirror commented 2025-11-02 09:21:39 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (May 29, 2023):

Can you confirm that if you alter these columns manually, then the OAuth2 could work?

And ...are you running an old instance (upgraded from an old instance) ? I can see that these fields have been changed to TEXT by #8554 (v1.11)

@wxiaoguang commented on GitHub (May 29, 2023): Can you confirm that if you alter these columns manually, then the OAuth2 could work? And ...are you running an old instance (upgraded from an old instance) ? I can see that these fields have been changed to `TEXT` by #8554 (v1.11)
GiteaMirror commented 2025-11-02 09:21:39 -06:00
Author
Owner
Copy Link

@abjoseph commented on GitHub (May 29, 2023):

Hi @wxiaoguang, I can confirm that altering the columns manually to varchar(max) does resolve the OAuth2 account linking issue. Also, I can confirm that I am running the latest, 1.19.3 (2nd screenshot)

1st Screenhot

image

2nd Screenhot

image

@abjoseph commented on GitHub (May 29, 2023): Hi @wxiaoguang, I can confirm that altering the columns manually to varchar(max) does resolve the OAuth2 account linking issue. Also, I can confirm that I am running the latest, 1.19.3 (2nd screenshot) ### 1st Screenhot ![image](https://github.com/go-gitea/gitea/assets/26844547/0cd28df0-6fe4-4cd4-bba6-6afbe09b2b58) ### 2nd Screenhot ![image](https://github.com/go-gitea/gitea/assets/26844547/b28018e8-b31a-46e7-99db-253e150e4349)
GiteaMirror commented 2025-11-02 09:21:39 -06:00
Author
Owner
Copy Link

@abjoseph commented on GitHub (May 29, 2023):

@wxiaoguang, do you know if that Issue you linked was just for MySQL DB engine or for all. I ask because, TEXT datatype does not exist in MSSQL and the reference to TEXT datatype would imply this issue was focused on MYSQL.

@abjoseph commented on GitHub (May 29, 2023): @wxiaoguang, do you know if that Issue you linked was just for MySQL DB engine or for all. I ask because, TEXT datatype does not exist in MSSQL and the reference to TEXT datatype would imply this issue was focused on MYSQL.
GiteaMirror commented 2025-11-02 09:21:39 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (May 29, 2023):

The Gitea's database system is supported by XORM, so maybe there are some tricks. Could @lunny help to confirm the TEXT behavior?

@wxiaoguang commented on GitHub (May 29, 2023): The Gitea's database system is supported by XORM, so maybe there are some tricks. Could @lunny help to confirm the TEXT behavior?
GiteaMirror commented 2025-11-02 09:21:40 -06:00
Author
Owner
Copy Link

@abjoseph commented on GitHub (May 29, 2023):

The Gitea's database system is supported by XORM, so maybe there are some tricks. Could @lunny help to confirm the TEXT behavior?

@wxiaoguang, I stand corrected. MSSQL does support a text datatype, see here but it is being deprecated and will be removed as noted in the callout; That begs the question of what XORM maps to when it runs migrations.

@abjoseph commented on GitHub (May 29, 2023): > The Gitea's database system is supported by XORM, so maybe there are some tricks. Could @lunny help to confirm the TEXT behavior? @wxiaoguang, I stand corrected. MSSQL does support a `text` datatype, see [here ](https://learn.microsoft.com/en-us/sql/t-sql/data-types/ntext-text-and-image-transact-sql?view=sql-server-ver15)but it is being deprecated and will be removed as noted in the callout; That begs the question of what XORM maps to when it runs migrations.
GiteaMirror commented 2025-11-02 09:21:40 -06:00
Author
Owner
Copy Link

@abjoseph commented on GitHub (Jun 6, 2023):

@delvh, do you know if this will be added to the next point release? It is a confirmed bug.

@abjoseph commented on GitHub (Jun 6, 2023): @delvh, do you know if this will be added to the next point release? It is a confirmed bug.
GiteaMirror commented 2025-11-02 09:21:40 -06:00
Author
Owner
Copy Link

@delvh commented on GitHub (Jun 6, 2023):

Well… I don't see a bugfix PR yet, so no?
Post one (and get it merged), then we can backport the fix.

@delvh commented on GitHub (Jun 6, 2023): Well… I don't see a bugfix PR yet, so no? Post one (and get it merged), then we can backport the fix.
GiteaMirror commented 2025-11-02 09:21:40 -06:00
Author
Owner
Copy Link

@abjoseph commented on GitHub (Jun 7, 2023):

@delvh, are you saying the core team does not have the expertise or env to replicate and fix this issue? Is MSSQL officially supported or was that a community contribution?

@abjoseph commented on GitHub (Jun 7, 2023): @delvh, are you saying the core team does not have the expertise or env to replicate and fix this issue? Is MSSQL officially supported or was that a community contribution?
GiteaMirror commented 2025-11-02 09:21:41 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jun 7, 2023):

I think it's a column size problem. I will reproduce it and try to send a PR.

@lunny commented on GitHub (Jun 7, 2023): I think it's a column size problem. I will reproduce it and try to send a PR.
GiteaMirror commented 2025-11-02 09:21:41 -06:00
Author
Owner
Copy Link

@Zettat123 commented on GitHub (Jun 7, 2023):

Hi @abjoseph , is your Gitea instance upgraded from an old version? I tested Gitea v1.19.3 with mssql and saw that those columns have been set to nvarchar(max) datatype.

@Zettat123 commented on GitHub (Jun 7, 2023): Hi @abjoseph , is your Gitea instance upgraded from an old version? I tested Gitea v1.19.3 with mssql and saw that those columns have been set to `nvarchar(max)` datatype. <img height="320px" src="https://github.com/go-gitea/gitea/assets/15528715/2e63e323-e0ab-48c0-b039-e01a4118e825" />
GiteaMirror commented 2025-11-02 09:21:41 -06:00
Author
Owner
Copy Link

@abjoseph commented on GitHub (Jun 7, 2023):

Hi @Zettat123, that's correct. I have been upgrading since version 1.12.2. If this is just a case of an outdated schema, should just I proceed in manually changing those columns to nvarchar(MAX) and close this issue?

However, I'm a little concerned that there might be other tables with outdated schema settings; also, I wonder if there were failed migrations during one of those upgrades and I didn't notice or whether there is some reason/limitation of the XORM library that it wasn't able to update those columns.

@abjoseph commented on GitHub (Jun 7, 2023): Hi @Zettat123, that's correct. I have been upgrading since version 1.12.2. If this is just a case of an outdated schema, should just I proceed in manually changing those columns to nvarchar(MAX) and close this issue? However, I'm a little concerned that there might be other tables with outdated schema settings; also, I wonder if there were failed migrations during one of those upgrades and I didn't notice or whether there is some reason/limitation of the XORM library that it wasn't able to update those columns.
GiteaMirror commented 2025-11-02 09:21:42 -06:00
Author
Owner
Copy Link

@Zettat123 commented on GitHub (Jun 8, 2023):

@abjoseph Thanks for your bug report. It should be caused by the failure of migration. When you encounter similar problems, you can manually set the data type to nvarchar(MAX). And we will try to add a new gitea doctor command to fix this datatype issue.

@Zettat123 commented on GitHub (Jun 8, 2023): @abjoseph Thanks for your bug report. It should be caused by the failure of migration. When you encounter similar problems, you can manually set the data type to `nvarchar(MAX)`. And we will try to add a new `gitea doctor` command to fix this datatype issue.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label issue/confirmed issue/workaround type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#10901
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?