Bug: Self-hosted GitLab backend (GitlabAuthServlet) ignores all configuration and defaults to gitlab.com for token exchange
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 8.2k
- Forks
- 1.2k
- PR merge metrics
- No merged PRs in 30d
Description
Preflight Checklist
When configuring the self-hosted Draw.io .war file (v22.1.21 and v28.2.7) to use a self-hosted, internal GitLab instance, the initial authorization redirect from Draw.io to GitLab works correctly.
However, after the user authorizes in GitLab, GitLab redirects back to Draw.io (/gitlab?code=...). The Draw.io backend then fails with an HTTP 500 Internal Server Error.
The catalina.out logs show the backend (com.mxgraph.online.AbsAuth.contactOAuthServer) is ignoring all configuration and attempting to contact the public https://gitlab.com/oauth/token to exchange the authorization code.
Because our server is in a secure network with an SSL interception proxy, this call to gitlab.com fails with a Java SSL error, causing the 500 error.
Log Error
SEVERE [http-nio-80-exec-X] com.mxgraph.online.AbsAuth.contactOAuthServer
AUTH-SERVLET: [https://gitlab.com/oauth/token] ERROR: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target
Environment
Draw.io Version: v22.1.21 and v28.2.7 (tested both .war files)
Deployment: .war file on Apache Tomcat
Tomcat Version: 9.0.111
Host OS: Amazon Linux 2
Java Version: OpenJDK 11 (manually installed from Adoptium/Temurin)
GitLab Instance: Self-hosted, accessible on a private network at http://xxx.xx.xxx.xx
Draw.io Instance: Self-hosted, accessible on a private network at http://xxx.xx.xxx.xx
Expected Behavior
The Draw.io backend (GitlabAuthServlet) should contact the configured self-hosted GitLab URL (e.g., http://xxx.xx.xxx.xx/oauth/token) to perform the token exchange, as defined in the configuration.
Configuration Attempts (All Ignored by Backend)
We have confirmed that the frontend JavaScript correctly reads the configuration and redirects to our internal GitLab. However, the backend appears to ignore all of the following configuration methods for the token exchange step:
config.js / PreConfig.js: Setting window.DRAWIO_GITLAB_URL = 'http://xxx.xx.xxx.xx'; only affects the frontend.
WEB-INF Files: Creating WEB-INF/gitlab_client_id and WEB-INF/gitlab_client_secret with the correct credentials.
Environment Variables (systemd): Adding Environment="DRAWIO_GITLAB_URL=http://xxx.xx.xxx.xx" (and ID/Secret) to the tomcat.service file.
Environment Variables (setenv.sh): Adding export DRAWIO_GITLAB_URL=... (and ID/Secret) to /opt/tomcat/bin/setenv.sh.
Java System Properties (setenv.sh): Adding export JAVA_OPTS="$JAVA_OPTS -Ddrawio.gitlab.url=http://xxx.xx.xxx.xx" (and guessed ID/Secret properties) to /opt/tomcat/bin/setenv.sh.
web.xml Parameters: Adding elements for gitlab.url, gitlab.appid, and gitlab.secret.
Despite all these attempts, the backend code still defaults to https://gitlab.com.
Question
What is the correct method in the self-hosted .war (v22-v28) to configure the backend URL for the GitLab OAuth token exchange (/oauth/token) to prevent it from defaulting to gitlab.com?
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing GitlabAuthServlet and com.mxgraph.online.AbsAuth.contactOAuthServer, focusing on how the backend selects the OAuth token endpoint. Review the listed config.js/PreConfig.js, WEB-INF files, environment variables, Java properties, and web.xml parameters, then verify the token exchange uses the configured self-hosted URL rather than gitlab.com.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, javascript
- Domain
- authentication, backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100