Casbin Forum runs on Casnode, the open-source Discourse-style forum. Try the Casnode demo →
Casbin Forum

Our usage pattern is fairly light and standard: we’re using Casdoor via OAuth2, with password grant type, client credentials, user CRUD and listing permissions, user info and logout flows. We are not using the syncer feature (we have no external directory or database sync configured).

If useful: we also don’t have large user import/migration jobs or external IdP syncing currently.

Given this, do you think any internal Casdoor component (even unused syncer modules) could still contribute to memory/CPU growth over time? Or would you point me to where the growth might come from given this usage pattern?

Mapping the types when calling the API directly, for non existing sdk operations

Precisely, I'm importing Casdoor packages from version v1.996.0 and plan to move to v2.63.0

@hsluoyz is there an existing option or chance to implement a feature toggle to redirect directly to the provider instead of going to the casdoor login page when doing the following:

authURL := oauth2Config.AuthCodeURL(
        state,
        oauth2.SetAuthURLParam("code_challenge", codeChallenge),
        oauth2.SetAuthURLParam("code_challenge_method", "S256"),
        oauth2.SetAuthURLParam("provider", idp),
        oauth2.SetAuthURLParam("prompt", "select_account"),
    )

As casdoor already has all those Providers implemented, It's interesting to not having to reimplement all over again

Any options to keep casdoor hidden from Frontend, with only the backend (also proxy to casdoor) knowing Casdoor?