[Bug]: Authentication (CODE/ACCESS_CODE) fails to trigger a password prompt and erroneously overrides the Server-side API Key

[albert8899]

Bug Description

I have successfully deployed the project on Vercel and configured HIDE_USER_API_KEY=true to protect my credentials. However, I need to restrict access exclusively to my students (Authentication).

I attempted to use CODE or ACCESS_CODE in Environment Variables, but encountered two critical issues:

No Authentication UI: The web interface does not trigger a password/access code prompt upon entry.

Credential Override: If a user manually enters the access code (e.g., Agent20251220) in the "API Key" field of the settings, the system incorrectly treats this code as the real DOUBAO_API_KEY for API requests, leading to a The API key format is incorrect error from the provider.

[中文]
我已通过 Vercel 成功部署，并配置了 HIDE_USER_API_KEY=true 来隐藏私钥。为了 700 名学生的调研实验，我需要实现访问限制（Authentication）。

我尝试了在环境变量中设置 CODE 或 ACCESS_CODE，但遇到了以下问题：

无鉴权弹窗：网页前端无法自动弹出密码/访问码的验证框。

凭证覆盖错误：如果学生在设置里的“API Key”处输入访问码，系统会错误地将其作为 API_KEY 发送给后端模型供应商，导致报出格式错误（Key format incorrect）。

Steps to Reproduce

1. Set DOUBAO_API_KEY, DOUBAO_BASE_URL, and CODE=YourPassword in Vercel.

2. Open the site in Incognito mode.

3. No password prompt appears; sending a message fails or requires manual Key input.

Expected Behavior

[English]

Mandatory Auth Prompt: If CODE or ACCESS_CODE is set, the site should prompt for a password before allowing any interaction.

Separation of Concerns: Once the Access Code is verified, the system should strictly use the server-side DOUBAO_API_KEY for requests, and the Access Code should never be passed into the API Key field of the provider's request header.

[中文]

强制鉴权弹窗：如果设置了访问码，站点应在用户操作前强制弹出密码框。

逻辑分离：访问码仅用于前端解锁。解锁后，系统应强制使用服务端配置的真实 API Key进行请求，而不应让访问码覆盖或污染 API 凭证字段。

Actual Behavior

Actual Behavior / 实际行为
[English]

Missing Authentication Barrier: Even with CODE or ACCESS_CODE set in environment variables, the application loads directly without any password prompt or overlay.

Incorrect Key Assignment: In the Settings panel, the "API Key" field is automatically populated with the value of the ACCESS_CODE (e.g., Agent20251220).

Request Failure: When a user attempts to chat, the system sends the ACCESS_CODE string as the Authorization header to the LLM provider. This causes a 401 or 400 error (e.g., The API key format is incorrect) because the server-side DOUBAO_API_KEY is being ignored or overwritten by this client-side string.

[中文]

缺失身份拦截：即便在环境变量中设置了 CODE 或 ACCESS_CODE，应用加载后直接进入主界面，没有任何密码输入提示或遮罩层。

Key 赋值错误：在设置面板中，API Key 栏目被自动填入了 ACCESS_CODE 的值（例如 Agent20251220）。

请求失败：当用户尝试对话时，系统将该“访问码”字符串作为 Authorization 请求头发送给了模型供应商。这导致了 401 或 400 错误（如：The API key format is incorrect），因为服务端的真实 DOUBAO_API_KEY 被前端这个字符串覆盖或忽略了。

Deployment Method

Vercel deployment

Browser

Chrome

Operating System

WIN10; Doubao (Volcengine Ark)

Relevant Logs / Screenshots

Additional Context

No response

[YizukiAme]

Hi @albert8899 — thanks for the report!

After digging into the codebase, this is actually a missing feature rather than a bug: CODE / ACCESS_CODE / HIDE_USER_API_KEY are not yet implemented in OpenMAIC. That's why there's no password prompt, and why the access code gets misrouted as an API key.

I've opened a Discussion with a proposed solution that would work on Vercel's free tier with zero dependencies: #293

As an immediate workaround until this is officially supported, you may want to look into Vercel's Deployment Protection or a simple HTTP Basic Auth via proxy.ts.

[albert8899]

Hi @YizukiAme ,

Thank you for the quick investigation and the honest feedback!

Regarding the proposed workarounds:

Vercel Deployment Protection is unfortunately not feasible for my case. I am based in China, and most of my 700 students cannot access Vercel's login or dashboard directly due to network restrictions.

My original plan was to deploy on Vercel and then alias it to a local Chinese domain for my students to use smoothly.

Feature Request:
Since CODE / ACCESS_CODE is currently missing, could you please consider prioritizing this feature? For educators like me, a simple server-side password gate is the only way to share these tools with a large group of students without exposing our API keys or requiring them to have external accounts (like Vercel).

I look forward to seeing this implemented in the future. Thanks again for your hard work on OpenMAIC!

[YizukiAme]

Thank you for your feedback — and it's precisely because of your 700-student scenario that I spent time investigating this issue in depth and put together the proposal in Discussion #293.

That said, I want to be transparent about the process: per CONTRIBUTING.md, new features and architectural changes need to go through a Discussion and receive maintainer approval before a PR can be opened. Since access-code authentication touches multiple layers of the application (proxy, API routes, UI), it qualifies as an architecture-level change.

I have the technical solution ready and am prepared to start development as soon as the maintainers greenlight it. However, submitting a PR without their buy-in risks it going unmerged — which helps no one.

Here's what you can do to help move this forward:

Since the maintainers have indicated that community demand influences prioritization, providing more context about your use case in the Discussion (#293) could significantly strengthen the case. For example:

1. What institution/school is this for?
2. What is the research topic or course? (If this is for a formal study or publication, an acknowledgment of OpenMAIC could be very valuable for the project's visibility)
3. The scale and timeline of your experiment

A concrete, institutional use case carries much more weight than a generic feature request — especially for an education-focused project like OpenMAIC.

I'll keep a close eye on the Discussion and will move quickly once/if we get the green light~

[albert8899]

Hi @YizukiAme , thank you for the INSTANT feedback. Since our research involves sensitive institutional information and a National Social Science Fund project, I would prefer to share the full details and formal acknowledgement plan with you privately. Do you have an email or a private channel where I can send these credentials to support your proposal?

[YizukiAme]

Hi @YizukiAme , thank you for the INSTANT feedback. Since our research involves sensitive institutional information and a National Social Science Fund project, I would prefer to share the full details and formal acknowledgement plan with you privately. Do you have an email or a private channel where I can send these credentials to support your proposal?

Hi @albert8899,

Thank you for sharing this — a National Social Science Fund project is incredibly compelling context😮.

To be clear: I am a contributor, not an official maintainer of the MAIC team. The decision to directly implement this feature upstream ultimately rests with the maintainers.

That said, I have a complete technical solution ready. If the project doesn't plan to prioritize this in the near term, I'd be happy to help you set up a fork with the access-code gate built in — this is genuinely important work that could benefit the broader education research community.

Feel free to reach me at yinzimike@gmail.com if you'd like to discuss further.

[YizukiAme]

P.S. In case Gmail is unreliable on your end, you can also reach me at yinzimike@qq.com. Either works!