password prompt on private datasets.

[t-book]

When a User visits a private dataset an ugly password prompt shows up:

https://stable.demo.geonode.org/catalogue/#/dataset/18150

The frontend attempts to fetch the dataset metadata via:

GET /api/v2/datasets/18150?api_preset=viewer_common&api_preset=dataset_viewer HTTP/1.1

response

401– Unauthorized
WWW-Authenticate | Basic realm="api"

This causes the browser to display a password prompt. When the user logs in, they still receive "Not Authenticated" error, creating a confusing UX.

Observations:

• This also occurs on other metadata endpoints (/metadata/<id>/)
• While HTTP 401 is technically correct for authentication challenges, it's unnecessary here since the user cannot access the resource regardless of authentication
• The WWW-Authenticate header triggers the browser's built-in login dialog.

a possible fix:
Return HTTP 403 Forbidden instead of 401. This will:

• Prevent the browser login prompt (no WWW-Authenticate header)
• Clearly communicate "permission denied" to both users and API clients (e.g., QGIS)
• Improve UX without breaking API compatibility

[giohappy]

@t-book I agree this should be handled better. It's a bit tricky BTW the API is the same for any API client, and the BasicAuthenticator is configured to handle basic auth requests, and it's the first one DRF queries to prepare the response headers when the exception is raised for anonymous users. We cannot just remove it from the authentication chain.

We need to find a better solution to handle API calls coming from the client app.
Opinions @mattiagiupponi ?

[t-book]

I see @giohappy what about a custom exception handler that intercepts 401 responses. It could detects if it's a browser request (check X-Requested-With header) and convert to 403 further remove WWW-Authenticate header. Other API clients would stay unaffected.
But curious what @mattiagiupponi thinks

[giohappy]

@t-book, the X-Requested-With header is not a reliable solution, and modern APIs often omit this header inside their requests (for example, the fetch native API).
I will discuss the option to add a custom header inside the GeoNode client....

[giohappy]

I've found what has caused this behaviour. It happened after the changes to fix #13343.

SessionAuthentication was the first authenticator in the list before this change. BasiuAuthentication became the first after it (since this is the default order). Django selects the first authenticator to inject eventual response headers (if any), and because the BasicAuthentication is the first one, it's given the option to set the basic auth challenge header.

Probably, as @t-book said, the simplest option is to override the exception handler. We keep 401 status (which is semantically correct) but avoid setting the WWW-Authenticate header for any request (from the geonode client or not).

Somehing like:

from rest_framework.views import exception_handler

def no_challenge_exception_handler(exc, context):
    response = exception_handler(exc, context)
    if response is not None and response.status_code == 401:
        response.headers.pop('WWW-Authenticate', None)
    return response

and inside the settings

# settings.py
REST_FRAMEWORK = {
    'EXCEPTION_HANDLER': 'path.to.no_challenge_exception_handler',
}

[t-book]

@giohappy you are a legend! Good find!

[mattiagiupponi]

Ideally i think that the client should intercept the 403 and make a redirect, for this page, to the login page to have a consistent behaviour, but the fix proposed by Giovanni, is for sure easier and adapt it quick instead of making additional work on the client side.

[giohappy]

They're two different aspects. The API returns 401, and that's its job. As you said, @mattiagiupponi, the client should intercept 401 from specific endpoints and trigger a redirect on its side. By the way, it should react only to specific endpoints since, for example, the 401 from userinfo/ shouldn't redirect.

The PR is merged. Once we confirm the fix on development demo we con close the issue.