Bug description
If you embed a dashboard, and authenticate using a guest JWT token, the dashboard can be almost entirely ok, except for the time range filter, which shows an error and doesn't allow you to apply changes even if you ignore the error and make a selection.
Looking at the network tab it seems the GET request to api/v1/time_range/?q=%27Last+year%27 returns a 403, even though the response should contain totally boring data (as far as i understand).
Screenshots/recordings
Superset version
v5
Checklist
- [ ] I have searched Superset docs and Slack and didn't find a solution to my problem.
- [x] I have searched the GitHub issue tracker and didn't find a similar bug report.
- [ ] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.
Comment From: dosubot[bot]
Hi @d1manson! I'm Dosu and I’m helping the superset team.
The 403 error from the /api/v1/time_range/ endpoint when using a guest JWT token is caused by missing API permissions for the guest role. Specifically, the guest role needs the "can time range on api" (or "can_read_on_time_range") permission to access this endpoint, even if it already has dashboard read access. This permission is not granted to guest roles by default, which is why the time range filter fails while the rest of the dashboard works. To resolve this, add the required permission to the guest role in Superset’s security settings. More details and confirmation of this requirement can be found here.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other 
Comment From: d1manson
Hi @d1manson! I'm Dosu and I’m helping the superset team.
The 403 error from the
/api/v1/time_range/endpoint when using a guest JWT token is caused by missing API permissions for the guest role. Specifically, the guest role needs the "can time range on api" (or "can_read_on_time_range") permission to access this endpoint, even if it already has dashboard read access. This permission is not granted to guest roles by default, which is why the time range filter fails while the rest of the dashboard works. To resolve this, add the required permission to the guest role in Superset’s security settings. More details and confirmation of this requirement can be found here.To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
You might be sort of right that i can somehow grant the permission to the guest user, but i'm not sure how - there is no guest role. I'm using the /api/v1/security/guest_token/ endpoint to get the token, and currently just supply the dashboard uuid, but maybe there's some way to specify access to the time_range api too?
Comment From: dosubot[bot]
You can't specify API permissions like "can_read_on_time_range" directly when creating a guest JWT token via /api/v1/security/guest_token/. Instead, Superset assigns guest users the role defined by the GUEST_ROLE_NAME config (often "Public" or a custom role), and all permissions—including API access—are managed through that role. To fix the 403 on /api/v1/time_range/, you need to add the "can_read_on_time_range" permission to the role set in GUEST_ROLE_NAME using Superset's security UI (Settings → Roles → [Your guest role] → Edit Permissions). This change will apply to all guest tokens using that role, and is the only supported way to grant API permissions for embedded/guest users in Superset v5 [source].
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
Comment From: d1manson
@dosu
It seems there is no "can_read_on_time_range" but there is "can time range on Api", which is a strange permission name as it's not very clear what it's enabling. But you are right that adding that on the public role did do the trick.
Comment From: dosubot[bot]
Yep, the permission name is a bit odd, but "can time range on Api" is what enables access to the /api/v1/time_range/ endpoint—which is what powers the time range filter in dashboards. Without it, users (including guests) get a 403 when trying to use that filter, even if they can view the dashboard itself. Granting this permission on the public (or guest) role is the right fix for embedded/guest access scenarios. If you want more details or links to discussions about this, let me know!
Reference
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other