#9653·alist

Only show "Guest user is disabled" error when guest access is explicitly requested, not on every unauthenticated page load

Author: gozimiCreated Sep 17, 2026Updated Sep 17, 2026
Labelsenhancement

Please make sure of the following things

  • I have read the documentation.
  • I'm sure there are no duplicate issues or discussions.
  • I'm sure this feature is not implemented.
  • I'm sure it's a reasonable and popular requirement.

Description of the feature / 需求描述

Currently, when a user who has never logged in (or whose token has expired) opens the root domain, e.g. https://<domain>/, Alist redirects to: https:///@login?redirect=%2F

and at the same time pops up an error toast: "Guest user is disabled, login please".

This happens automatically on every single anonymous visit as long as the guest account is disabled, even though the visitor never explicitly tried to browse as a guest — they simply opened the site for the first time, which naturally lands them on the login page since there's no session yet.

The problem is that this looks like a real error to end users, when it's actually just the expected default flow ("you're not logged in, please log in"). It's confusing and makes the site look broken on first load for any new/anonymous visitor.

Suggested solution / 实现思路

The "Guest user is disabled, login please" message should only fire when a user actively attempts to access content as a guest — for example, clicking a "Browse as guest" affordance, or requesting a shared/public path that expects guest permissions — while the admin has disabled the guest account. It should not fire purely because the SPA's own startup logic makes an unauthenticated request to check the current login state before showing the login page.

Possible approaches:

  • On the frontend, check for a stored token before making any API call. If there is none, navigate straight to /@login without calling an endpoint that would fall back to the guest role, so the backend never needs to return this error for a simple first-time visit.
  • On the backend, distinguish between "no token at all" (first-time/unauthenticated visit) and "actively requesting a resource that requires guest permissions" — only return the 401 + message for the latter case.
  • Keep the current 401 + message behavior for cases where an already-anonymous session explicitly requests something (e.g. opening a public share link) that would require the guest role, while guest is disabled.

Additional context / 附件

Root cause (as of current main), in server/middlewares/auth.go:

if token == "" {
    guest, err := op.GetGuest()
    ...
    if guest.Disabled {
        common.ErrorStrResp(c, "Guest user is disabled, login please", 401)
        c.Abort()
        return
    }
    ...
}

This check runs at the auth middleware level, before any route-specific or permission-specific logic, so it fires unconditionally for any unauthenticated request — including the frontend's own startup/auth-check call on first load, not just genuine "browse as guest" attempts.

Related past discussion: https://github.com/AlistGo/alist/discussions/3514

I'd prefer not to enable the guest account just to silence this notification — enabling guest is a separate security/permissions decision, and a first-time anonymous visitor being redirected to the login page shouldn't need to trigger what looks like an error.