-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change LDAP - PANIC: runtime error: invalid memory address or nil pointer dereference #16252
Comments
The NPE is coming from looking at the login_source which is defined as a LDAP source but doesn't appear to have a Cfg which is an LDAP source. There is very likely to be an error earlier that we are missing but it would be also helpful to review the database for this login_source looking at the login_sources with type 2 or 5 in particular looking for those with empty cfg |
Another Test on Win10, local SQL Server, local GiTEA same Problem. I dont think it maters what you enter as authentication source. DB output id type name is_actived is_sync_enabled cfg created_unix updated_unix CFG is not empty and this is a fresh instance. |
Going all the way to 1.12.6 and then it works again. |
The cfg entry is supposed to be json - that doesn't look like json... |
This is very odd, looking at the code
source, err := models.GetLoginSourceByID(ctx.ParamsInt64(":authid"))
if err != nil {
ctx.ServerError("GetLoginSourceByID", err)
return
}
ctx.Data["Source"] = source
ctx.Data["HasTLS"] = source.HasTLS() // HasTLS returns true of this source supports TLS.
func (source *LoginSource) HasTLS() bool {
return ((source.IsLDAP() || source.IsDLDAP()) &&
source.LDAP().SecurityProtocol > ldap.SecurityProtocolUnencrypted) || // <- This is where the NPE occurs
source.IsSMTP()
} Now So the only thing I can see is that the internal // FromDB fills up a LDAPConfig from serialized format.
func (cfg *LDAPConfig) FromDB(bs []byte) error {
json := jsoniter.ConfigCompatibleWithStandardLibrary
return json.Unmarshal(bs, &cfg)
} this fails or returns an error. But I don't understand that. I can't reproduce this error here on SQLite or Postgres. So I think unless you can see something wrong with the json that is in that cfg, the only solution is going to be compiling in additional logging. Are you able to do that? |
No sry, Also the other authentication methods are also not working, they don't show a 500 error, but not all settings are saved. id type name is_actived is_sync_enabled cfg created_unix updated_unix |
Those cfg fields are being returned as bytes in whatever way you're pasting them in here. Likely this is because of our schema but there should be someway of casting them to strings for us to check if they're actually reasonable JSON. |
This is exactly how the config looks like in MS Sql Studio, just copy/pasted it here, To be clear, the initial setup of any authentication source works and it look fine in the DB. LDAP for example works, login ok. Workaround: |
Before or after attempting to edit it? Would you be able to cast it as a string or even just give me the bytes themselves?
This suggests an issue with collations or encodings but I don't understand it.
This isn't really a viable solution for most people - and it doesn't explain why 1.12.6 works when 1.14.3 doesn't. |
Plain export of the table: I also setup the DB with a different collation (closer to UTF8mb4), but it changed nothing. Default language of my server/DB is german. |
Yep. OK looking at those bytes - they have been |
and I've managed to replicate the issue too. |
OK it's a bug with xorm. |
https://gitea.com/xorm/xorm/pulls/1957 is the bug fix PR. The issue is that there is a fundamental mismatch with how Blob types and non-Blob types are handled for converts like this in Select, Insert and Update - and MSSQL unfortunately requires the special cast. |
Signed-off-by: Andrew Thornton <[email protected]>
Unfortunately due a bug in xorm (see https://gitea.com/xorm/xorm/pulls/1957) updating loginsources on MSSQL causes them to become corrupted. (go-gitea#16252) Whilst waiting for the referenced PR to be merged and to handle the corrupted loginsources correctly we need to add a wrapper to the `FromDB()` methods to look for and ignore the misplaced BOMs that have been added. Fix go-gitea#16252 Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
* Handle misencoding of login_source cfg in mssql Unfortunately due a bug in xorm (see https://gitea.com/xorm/xorm/pulls/1957) updating loginsources on MSSQL causes them to become corrupted. (#16252) Whilst waiting for the referenced PR to be merged and to handle the corrupted loginsources correctly we need to add a wrapper to the `FromDB()` methods to look for and ignore the misplaced BOMs that have been added. Fix #16252 Signed-off-by: Andrew Thornton <[email protected]> * Update models/login_source.go
Backport go-gitea#16268 Unfortunately due a bug in xorm (see https://gitea.com/xorm/xorm/pulls/1957) updating loginsources on MSSQL causes them to become corrupted. (go-gitea#16252) Whilst waiting for the referenced PR to be merged and to handle the corrupted loginsources correctly we need to add a wrapper to the `FromDB()` methods to look for and ignore the misplaced BOMs that have been added. Fix go-gitea#16252 Signed-off-by: Andrew Thornton <[email protected]>
Backport #16268 Unfortunately due a bug in xorm (see https://gitea.com/xorm/xorm/pulls/1957) updating loginsources on MSSQL causes them to become corrupted. (#16252) Whilst waiting for the referenced PR to be merged and to handle the corrupted loginsources correctly we need to add a wrapper to the `FromDB()` methods to look for and ignore the misplaced BOMs that have been added. Fix #16252 Signed-off-by: Andrew Thornton <[email protected]>
There's probably another similar issue regarding repo units which are likely to suffer the same problem |
One of the reasons why go-gitea#16447 was needed and why go-gitea#16268 was needed in the first place was because it appears that editing ldap configuration doesn't get tested. This PR therefore adds a basic test that will run the edit pipeline. In doing so it's now clear that go-gitea#16447 and go-gitea#16268 aren't actually solving go-gitea#16252. It turns out that what actually happens is that is that the bytes are actually double encoded. This PR now changes the json unmarshal wrapper to handle this double encode. Fix go-gitea#16252 Signed-off-by: Andrew Thornton <[email protected]>
One of the reasons why #16447 was needed and why #16268 was needed in the first place was because it appears that editing ldap configuration doesn't get tested. This PR therefore adds a basic test that will run the edit pipeline. In doing so it's now clear that #16447 and #16268 aren't actually solving #16252. It turns out that what actually happens is that is that the bytes are actually double encoded. This PR now changes the json unmarshal wrapper to handle this double encode. Fix #16252 Signed-off-by: Andrew Thornton <[email protected]> Co-authored-by: 6543 <[email protected]>
…#16465) Backport go-gitea#16465 One of the reasons why go-gitea#16447 was needed and why go-gitea#16268 was needed in the first place was because it appears that editing ldap configuration doesn't get tested. This PR therefore adds a basic test that will run the edit pipeline. In doing so it's now clear that go-gitea#16447 and go-gitea#16268 aren't actually solving go-gitea#16252. It turns out that what actually happens is that is that the bytes are actually double encoded. This PR now changes the json unmarshal wrapper to handle this double encode. Fix go-gitea#16252 Signed-off-by: Andrew Thornton <[email protected]>
…#16465) Backport go-gitea#16465 One of the reasons why go-gitea#16447 was needed and why go-gitea#16268 was needed in the first place was because it appears that editing ldap configuration doesn't get tested. This PR therefore adds a basic test that will run the edit pipeline. In doing so it's now clear that go-gitea#16447 and go-gitea#16268 aren't actually solving go-gitea#16252. It turns out that what actually happens is that is that the bytes are actually double encoded. This PR now changes the json unmarshal wrapper to handle this double encode. Fix go-gitea#16252 Signed-off-by: Andrew Thornton <[email protected]>
Backport #16465 One of the reasons why #16447 was needed and why #16268 was needed in the first place was because it appears that editing ldap configuration doesn't get tested. This PR therefore adds a basic test that will run the edit pipeline. In doing so it's now clear that #16447 and #16268 aren't actually solving #16252. It turns out that what actually happens is that is that the bytes are actually double encoded. This PR now changes the json unmarshal wrapper to handle this double encode. Fix #16252 Signed-off-by: Andrew Thornton <[email protected]> Co-authored-by: 6543 <[email protected]>
Backport #16465 One of the reasons why #16447 was needed and why #16268 was needed in the first place was because it appears that editing ldap configuration doesn't get tested. This PR therefore adds a basic test that will run the edit pipeline. In doing so it's now clear that #16447 and #16268 aren't actually solving #16252. It turns out that what actually happens is that is that the bytes are actually double encoded. This PR now changes the json unmarshal wrapper to handle this double encode. Fix #16252 Signed-off-by: Andrew Thornton <[email protected]> Co-authored-by: 6543 <[email protected]>
[1.14.6](https://github.com/go-gitea/gitea/releases/tag/v1.14.6) - 2021-08-04 * SECURITY * Bump github.com/markbates/goth from v1.67.1 to v1.68.0 (go-gitea#16538) (go-gitea#16540) * Switch to maintained JWT lib (go-gitea#16532) (go-gitea#16535) * Upgrade to latest version of golang-jwt (as forked for 1.14) (go-gitea#16590) (go-gitea#16607) * BUGFIXES * Add basic edit ldap auth test & actually fix go-gitea#16252 (go-gitea#16465) (go-gitea#16495) * Make cancel from CatFileBatch and CatFileBatchCheck wait for the command to end (go-gitea#16479) (go-gitea#16481) Signed-off-by: Andrew Thornton <[email protected]>
## [1.14.6](https://github.com/go-gitea/gitea/releases/tag/v1.14.6) - 2021-08-04 * SECURITY * Bump github.com/markbates/goth from v1.67.1 to v1.68.0 (#16538) (#16540) * Switch to maintained JWT lib (#16532) (#16535) * Upgrade to latest version of golang-jwt (as forked for 1.14) (#16590) (#16607) * BUGFIXES * Add basic edit ldap auth test & actually fix #16252 (#16465) (#16495) * Make cancel from CatFileBatch and CatFileBatchCheck wait for the command to end (#16479) (#16481) Signed-off-by: Andrew Thornton <[email protected]>
* Handle misencoding of login_source cfg in mssql Unfortunately due a bug in xorm (see https://gitea.com/xorm/xorm/pulls/1957) updating loginsources on MSSQL causes them to become corrupted. (go-gitea#16252) Whilst waiting for the referenced PR to be merged and to handle the corrupted loginsources correctly we need to add a wrapper to the `FromDB()` methods to look for and ignore the misplaced BOMs that have been added. Fix go-gitea#16252 Signed-off-by: Andrew Thornton <[email protected]> * Update models/login_source.go
…#16465) One of the reasons why go-gitea#16447 was needed and why go-gitea#16268 was needed in the first place was because it appears that editing ldap configuration doesn't get tested. This PR therefore adds a basic test that will run the edit pipeline. In doing so it's now clear that go-gitea#16447 and go-gitea#16268 aren't actually solving go-gitea#16252. It turns out that what actually happens is that is that the bytes are actually double encoded. This PR now changes the json unmarshal wrapper to handle this double encode. Fix go-gitea#16252 Signed-off-by: Andrew Thornton <[email protected]> Co-authored-by: 6543 <[email protected]>
Gitea version (or commit ref): v1.14.3 or v1.13.7
Git version: 2.32.0
Operating system: Windows Server Core 2019
Database (use
[x]
):Can you reproduce the bug at https://try.gitea.io:
Log gist (local):
2021/06/25 20:23:10 ...l/manager_windows.go:85:start() [T] Not running a service ... using the debug SVC manager
2021/06/25 20:23:10 ...l/manager_windows.go:101:Execute() [T] Awaiting server start-up
2021/06/25 20:23:10 cmd/web.go:82:runWeb() [I] Starting Gitea on PID: 5508
2021/06/25 20:23:10 ...dules/setting/git.go:101:newGit() [I] Git Version: 2.32.0, Wire Protocol Version 2 Enabled
2021/06/25 20:23:10 cmd/web.go:126:runWeb() [I] Global init
2021/06/25 20:23:10 ...dules/setting/git.go:101:newGit() [I] Git Version: 2.32.0, Wire Protocol Version 2 Enabled
2021/06/25 20:23:11 routers/init.go:134:GlobalInit() [T] AppPath: G:/Gitea/gitea-amd64.exe
2021/06/25 20:23:11 routers/init.go:135:GlobalInit() [T] AppWorkPath: G:/Gitea
2021/06/25 20:23:11 routers/init.go:136:GlobalInit() [T] Custom path: G:/Gitea/custom
2021/06/25 20:23:11 routers/init.go:137:GlobalInit() [T] Log path: G:/data/log
2021/06/25 20:23:11 routers/init.go:49:checkRunMode() [I] Run Mode: Prod
2021/06/25 20:23:12 ...dules/setting/log.go:287:newLogService() [I] Gitea v1.14.3 built with GNU Make 4.1, go1.16.5 : bindata, sqlite, sqlite_unlock_notify
2021/06/25 20:25:46 ...uters/routes/base.go:153:1() [E] PANIC: runtime error: invalid memory address or nil pointer dereference
/usr/local/go/src/runtime/panic.go:212 (0x1003864)
/usr/local/go/src/runtime/signal_windows.go:239 (0x100371e)
/source/models/login_source.go:262 (0x2c7981a)
/source/routers/admin/auths.go:309 (0x2c7982b)
/source/modules/web/route.go:64 (0x2ba1ffb)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/vendor/github.com/go-chi/chi/mux.go:436 (0x274ba6a)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/modules/web/route.go:103 (0x2ba26e9)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/modules/web/route.go:103 (0x2ba26e9)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/modules/web/route.go:103 (0x2ba26e9)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/modules/web/route.go:103 (0x2ba26e9)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/vendor/github.com/go-chi/chi/middleware/get_head.go:37 (0x2dd3fe1)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/modules/context/context.go:704 (0x276b121)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/routers/routes/base.go:94 (0x2ddb6ac)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/routers/routes/base.go:94 (0x2ddb6ac)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/modules/public/public.go:86 (0x1fd800c)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/modules/public/public.go:86 (0x1fd800c)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/routers/routes/base.go:199 (0x2ddd317)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/vendor/gitea.com/go-chi/session/session.go:256 (0x212ed6e)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/vendor/github.com/go-chi/chi/mux.go:70 (0x274956a)
/source/vendor/github.com/go-chi/chi/mux.go:311 (0x274fa1b)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/vendor/github.com/go-chi/chi/mux.go:436 (0x274ba6a)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/routers/routes/web.go:107 (0x2dde7a4)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/vendor/github.com/go-chi/chi/middleware/strip.go:30 (0x2dd4927)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/vendor/github.com/chi-middleware/proxy/middleware.go:37 (0x2dcfe53)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/routers/routes/web.go:63 (0x2dde2e7)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/source/vendor/github.com/go-chi/chi/mux.go:87 (0x27492f0)
/source/modules/web/route.go:298 (0x2ba151a)
/source/vendor/github.com/gorilla/context/context.go:141 (0x1d980fa)
/usr/local/go/src/net/http/server.go:2069 (0x13858aa)
/usr/local/go/src/net/http/server.go:2887 (0x1388ee9)
/usr/local/go/src/net/http/server.go:1952 (0x138436c)
/usr/local/go/src/runtime/asm_amd64.s:1371 (0x1026640)
Description
When I try to change any authentication source I get a 500 site and the above mentionesd runtime error and it is impossible to change any LDAP settings afterwards.
The text was updated successfully, but these errors were encountered: