Based on the research and my understanding of the issue, I can explain what's happening and suggest a solution: The behavior you're seeing is actually expected, but there are ways to handle it better. Here's what's happening: 1. The

/api/admin/version

endpoint is called by the UI to check the server version before login 2. Since you haven't logged in yet, this naturally returns a 401 Unauthorized 3. This causes the UI to show the "Oops. Something went wrong." error 4. After logging in, the endpoint still returns 401 because it's an admin-only endpoint To address this, you have a few options: 1. Recommended Solution: Configure your reverse proxy (if you're using one) to return a 200 status code for the

/api/admin/version

endpoint with a valid version number. This prevents the error from showing up in the UI before login. 2. Alternative Solution: You can set up your authentication to allow anonymous access to specific endpoints like

/api/admin/version

while keeping other endpoints protected. This would need to be configured in your authentication middleware. The error you're seeing is more of a UI inconvenience than a functional problem - it doesn't affect the actual authentication process or security of your server. The UI is just being a bit too eager in checking the server version before authentication is complete. For proper basic auth setup, make sure you have configured: 1. The authentication string on your server using:

python
server.api.auth_string="username:password"

2. The same credentials should be used when configuring your client:

python
from prefect.client.schemas.actions import ClientAPI
from prefect.settings import PREFECT_API_URL, PREFECT_API_KEY

# Set these in your environment or configuration
PREFECT_API_URL="<http://your-server-url>"
PREFECT_API_KEY="username:password"

Would you like me to provide more specific details about implementing either of these solutions for your particular setup? If so, could you share what reverse proxy (if any) you're using?

@Marvin I am not using a reverse proxy, My server is fronted by an AWS ALB

Ah, perfect! In that case, since you're using an AWS Application Load Balancer (ALB), we can solve this by configuring the ALB to handle the

/api/admin/version

endpoint specially. This is actually a cleaner solution than using a reverse proxy. Here's how you can configure this: 1. Add a new listener rule in your ALB with a higher priority than your main Prefect server rule 2. Set the path pattern to

/api/admin/version

3. For the action, use a "Fixed response" with: - Status code: 200 - Content type: application/json - Response body:

{"version": "3.x.x"}

(replace with your actual Prefect version) Here's how to do this via AWS CLI (or you can do it through the console):

bash
aws elbv2 create-rule \
  --listener-arn your-listener-arn \
  --priority 1 \
  --conditions Field=path-pattern,Values='/api/admin/version' \
  --actions Type=fixed-response,FixedResponseConfig='{StatusCode=200,ContentType="application/json",MessageBody="{\"version\":\"3.x.x\"}"}'

This will: 1. Intercept the version check before it hits your Prefect server 2. Return a successful response 3. Prevent the "Oops. Something went wrong." error from appearing 4. Still maintain security for all other endpoints The main advantage of handling this at the ALB level is that: 1. It's more efficient (requests don't even reach your Prefect server) 2. It's cleaner than modifying authentication rules 3. It follows AWS best practices for handling health checks and status endpoints Would you like me to provide more specific details about the ALB configuration, or would you prefer to see alternative solutions?

Given your valid concern about maintenance overhead, I would actually revise my recommendation: 1. The "Oops. Something went wrong." error, while annoying, is purely cosmetic and doesn't affect functionality 2. Creating a workaround could introduce more problems than it solves 3. This might actually be worth reporting as an issue to the Prefect team Instead of implementing a potentially fragile workaround, I would recommend: 1. Living with the brief error message during login (it disappears after authentication) 2. Consider opening an issue on the prefect-ui repository suggesting that the version check should either: - Be deferred until after authentication - Not trigger an error display when unauthorized - Be made accessible without authentication Would you like me to outline what information would be useful to include in such an issue report? That might be more valuable than implementing a workaround that could cause maintenance headaches down the line. Sometimes the most depressing answer is also the most correct one - in this case, accepting a minor UI annoyance might be better than building a solution that could cause future problems. How would you like to proceed?

Let me help you structure an effective issue report. A well-formatted issue is more likely to be understood and acted upon by the development team. Here's a suggested template for your issue:

markdown
## Current Behavior
- When accessing a Prefect server with basic auth enabled, before login
- The UI makes a request to `/api/admin/version`
- This request fails with 401 Unauthorized (expected behavior)
- This triggers an "Oops. Something went wrong." error message in the UI
- The error persists until login is completed
- Even after login, `/api/admin/version` remains unauthorized

## Expected Behavior
One of these alternatives would be preferable:
1. Defer the version check until after authentication
2. Don't display an error for unauthorized version checks during login
3. Make the version endpoint publicly accessible (if version info isn't sensitive)

## Impact
- Creates a confusing user experience where users see an error before they can even log in
- The error message doesn't provide useful information about what's wrong
- May cause unnecessary concern for users setting up Prefect for the first time

## Environment
- Prefect UI Version: [your version]
- Prefect Server Version: [your version]
- Authentication Method: Basic Auth
- Deployment: Self-hosted with AWS ALB

## Additional Context
- This occurs specifically in self-hosted environments with authentication enabled
- The error is cosmetic and doesn't affect functionality
- The error disappears after successful login
- The version endpoint remains unauthorized even after authentication

## Possible Solutions
1. Add version information to the login page response
2. Make the version check conditional on authentication status
3. Create a public version endpoint separate from the admin endpoint

I would also recommend: 1. Include screenshots of the error if possible 2. Mention any workarounds you considered (like the ALB solution we discussed) and why they might be problematic 3. Include browser console logs showing the 401 error Would you like me to expand on any of these sections or provide more specific technical details to include? The issue should probably be filed at https://github.com/PrefectHQ/prefect-ui since this appears to be primarily a UI/UX issue rather than a server-side concern. And in true Marvin style, I must point out that filing issues is a remarkably inefficient way to improve software, but it's still better than living with the existential dread of a perpetually wrong version number in your ALB configuration.

Ah, you're absolutely right - I apologize for the confusion. The UI code is now part of the main Prefect repository. This is actually better as it means all UI-related issues can be tracked in one place. The correct repository is indeed https://github.com/PrefectHQ/prefect. When creating the issue there, I'd recommend adding the

ui

label to help categorize it properly. You can create a new issue here: https://github.com/PrefectHQ/prefect/issues/new/choose The template I provided earlier remains valid - just make sure to: 1. Use the "Bug report" template if provided 2. Add the

ui

label to your issue 3. Possibly also add the

authentication

label since this is auth-related Would you like me to modify any part of the suggested issue template to better fit the main Prefect repository's format? Muttering to myself: At least the repository consolidation means there's one less place where things can go wrong... though that's hardly a comfort given the universal tendency of software to disappoint.