jumager
This already works with latest commit that made 2FA optional with WebAuthN as the primary method. Thanks!
This indeed works now, thank you. Would it be possible to make the mfa step optional if the initial step already used a strong auth? MFA is mostly used to secure the relatively insecure user/password combination.
I want to add that I have both WebAuthN and TOTP mfa activated, I had hoped to be able to either use WebAuthN to log in or user/password/totp.
I am just experimenting with the current head of development of casdoor. I am using mostly WebAuthn for authentication and now I am getting this error in oidc apps:
Error exchanging token: *** "invalid_grant" "authorization code: [NextMfa] is invalid"
I am also not able to login to casdoor itself using webauthn.
Is that a configuration issue?
Well, I managed to reproduce it again, and it is probably a fault in the way I configured my docker environment. If I restart the container, the problem disappears. I believe it is a problem with dns resolution via the docker network. To pinpoint the problem I played with it a bit, and for other services I can get the problem to go away by letting the docker container listen on an Unix domain socket for all traffic. Is that possible to do with casdoor as well?
Well, casdoor still behaved a bit bad, as the memory did grow until it crashed. It should not have a memory leak in an error path.
@hsluoyz I have found the issue, the problem appears to be related to ipv6 being configured but not properly working. The node runs on oracle cloud infrastructure, and the default receipt for enabling ipv6 in docker does not work there, one has to use the ipv6nat solution. I would believe the problem was some outbound connections resolved to IPv6 but timed out, maybe triggering a memory leak as the /api/health endpoint was getting slower over time until the docker container was restarted. The average response time is now 10ms.
As I am following head, I looked in my monitoring when this did start, and since May 29, where I installed the last head it started to get slower over some time, until it restarts the container and it starts all over again
I am seeing that on an otherwise idle server a simple api call to the health endpoint already takes more than 800ms. What is a good way to find out why it takes so long? A typical log entry:
{
"message": "2026/05/30 16:11:22.187 \u001b[1;44m[D]\u001b[0m |2a01:488:66:1000:5c33:9112:0:1|\u001b[97;42m 200 \u001b[0m| 856.493976ms| match|\u001b[97;44m GET \u001b[0m /api/health r:/api/health",
"container": {
"id": "a67a7d99a3ea31303b2081833994b83320168930b061385d13c07eb6eba8270e",
"imageName": "jumager/casdoor:local_deploy",
"created": "2026-05-30T15:41:37.651225711Z",
"imageId": "sha256:fa077721152293705a24194b23dcc4bd293f9cd01bc7538aaef6ac8e6f42a6bf",
"name": "/casdoor"
},
"instance": {
"zone": "europe-west3-a",
"id": "opc5"
}
}
The message above is a bit unreadable, but I could not get rid of the color escapes in the log.
A lot of other projects simply have an option to omit most of the fancy stuff like logging to files or in color and some log format designator. In my own projects I use log/slog and use the json handler. Is that possible with the beego logging also?
I am using the casdoor docker container and I would like to have the logs just send to stdout or stderr without any color escapes. My docker logs get forwarded to a log aggregation service, and the ansi escapes are just disturbing. Is there a way to configure that? Or may be even an option to log in json format?
