starred/bambuddy

Fork 0

mirror of https://github.com/maziggy/bambuddy.git synced 2026-05-09 05:35:30 +02:00

[GH-ISSUE #1182] [Feature]: Allow API Keys to access cloud presets #857

New issue

Closed

opened 2026-05-06 12:33:27 +02:00 by BreizhHardware · 8 comments

BreizhHardware commented

2026-05-06 12:33:27 +02:00

Owner

Originally created by @turulix on GitHub (Apr 30, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1182

Originally assigned to: @maziggy on GitHub.

Problem or Use Case

I am currently working on building a fully automated, headless pipeline to manage my 3D prints. A crucial step in this workflow is automatically slicing the 3D models on my server before sending them to the printer.

However, as discussed in #665, the current APIs are unable to access cloud data. Because the API cannot interact with the cloud to retrieve user presets.

Proposed Solution

The most straight forward way would be to allow API keys to access cloud data of the user that has created them

Alternatives Considered

No response

Feature Category

API

Priority

Critical for my use case

Mockups or Examples

No response

Contribution

I would be willing to help implement this feature

Checklist

I have searched existing issues to ensure this feature hasn't already been requested

Originally created by @turulix on GitHub (Apr 30, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1182 Originally assigned to: @maziggy on GitHub. ### Problem or Use Case I am currently working on building a fully automated, headless pipeline to manage my 3D prints. A crucial step in this workflow is automatically slicing the 3D models on my server before sending them to the printer. However, as discussed in #665, the current APIs are unable to access cloud data. Because the API cannot interact with the cloud to retrieve user presets. ### Proposed Solution The most straight forward way would be to allow API keys to access cloud data of the user that has created them ### Alternatives Considered _No response_ ### Feature Category API ### Priority Critical for my use case ### Mockups or Examples _No response_ ### Contribution - [x] I would be willing to help implement this feature ### Checklist - [x] I have searched existing issues to ensure this feature hasn't already been requested

BreizhHardware

2026-05-06 12:33:27 +02:00

closed this issue
added the
enhancement
label

BreizhHardware commented

2026-05-06 12:33:28 +02:00

Author

Owner

@maziggy commented on GitHub (May 1, 2026):

You didn't fill out the bug report completely. I'm missing important details.

@maziggy commented on GitHub (May 1, 2026): You didn't fill out the bug report completely. I'm missing important details.

BreizhHardware commented

2026-05-06 12:33:28 +02:00

Author

Owner

@turulix commented on GitHub (May 1, 2026):

What details do you still need?

@turulix commented on GitHub (May 1, 2026): What details do you still need?

BreizhHardware commented

2026-05-06 12:33:28 +02:00

Author

Owner

@maziggy commented on GitHub (May 1, 2026):

The bug report form has all required infos.

@maziggy commented on GitHub (May 1, 2026): The bug report form has all required infos.

BreizhHardware commented

2026-05-06 12:33:28 +02:00

Author

Owner

@turulix commented on GitHub (May 1, 2026):

I made this using the feature request form, and these are all the infos it asked for, this is not a bug and was done on purpose in #665

@turulix commented on GitHub (May 1, 2026): I made this using the feature request form, and these are all the infos it asked for, this is not a bug and was done on purpose in #665

BreizhHardware commented

2026-05-06 12:33:28 +02:00

Author

Owner

@maziggy commented on GitHub (May 1, 2026):

I'm sorry, mixed up the issues. Need to grab a coffee first.

@maziggy commented on GitHub (May 1, 2026): I'm sorry, mixed up the issues. Need to grab a coffee first.

BreizhHardware commented

2026-05-06 12:33:29 +02:00

Author

Owner

@maziggy commented on GitHub (May 1, 2026):

Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you.

Docs -> https://wiki.bambuddy.cool/features/api-keys/

If you find Bambuddy useful, please consider giving it a ⭐ on GitHub — it helps others discover the project!

@maziggy commented on GitHub (May 1, 2026): Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you. Docs -> https://wiki.bambuddy.cool/features/api-keys/ ----- If you find Bambuddy useful, please consider giving it a ⭐ on [GitHub](https://github.com/maziggy/bambuddy) — it helps others discover the project!

BreizhHardware commented

2026-05-06 12:33:29 +02:00

Author

Owner

@turulix commented on GitHub (May 1, 2026):

Got around to testing it thanks for the fast implementation, its not quite working as i need it, i can now successfully get the needed ids from:
/api/v1/cloud/settings

Sending a request to /v1/library/files/<file_id>/slice with the payload:

{
    "printer_preset": {
        "source": "cloud",
        "id": "PMUS3f3e..."
    },
    "process_preset": {
        "source": "cloud",
        "id": "PPUS17c03..."
    },
    "filament_presets": [
        {
            "source": "cloud",
            "id": "PFUS594..."
        }
    ]
}

successfully starts a slicing task, but checking the status of the slicing task under /api/v1/slice-jobs/<job_id>
results in:

{
    "job_id": 1,
    "status": "failed",
    "kind": "library_file",
    "source_id": 13,
    "source_name": "test.3mf",
    "created_at": "2026-05-01T19:03:30.049578+00:00",
    "started_at": "2026-05-01T19:03:30.049663+00:00",
    "completed_at": "2026-05-01T19:03:30.051591+00:00",
    "progress": null,
    "error_status": 400,
    "error_detail": "Cloud preset selected for printer, but no Bambu Cloud session is stored. Sign in to Bambu Cloud and retry."
}

@turulix commented on GitHub (May 1, 2026): Got around to testing it thanks for the fast implementation, its not quite working as i need it, i can now successfully get the needed ids from: `/api/v1/cloud/settings` Sending a request to `/v1/library/files/<file_id>/slice` with the payload: ```json { "printer_preset": { "source": "cloud", "id": "PMUS3f3e..." }, "process_preset": { "source": "cloud", "id": "PPUS17c03..." }, "filament_presets": [ { "source": "cloud", "id": "PFUS594..." } ] } ``` successfully starts a slicing task, but checking the status of the slicing task under `/api/v1/slice-jobs/<job_id>` results in: ```json { "job_id": 1, "status": "failed", "kind": "library_file", "source_id": 13, "source_name": "test.3mf", "created_at": "2026-05-01T19:03:30.049578+00:00", "started_at": "2026-05-01T19:03:30.049663+00:00", "completed_at": "2026-05-01T19:03:30.051591+00:00", "progress": null, "error_status": 400, "error_detail": "Cloud preset selected for printer, but no Bambu Cloud session is stored. Sign in to Bambu Cloud and retry." } ```

BreizhHardware commented

2026-05-06 12:33:29 +02:00

Author

Owner

@maziggy commented on GitHub (May 2, 2026):

Good catch — and apologies that the first fix only covered half the surface. You found the gap: the /cloud/* router got the owner-resolution treatment, but the slice route lives on /library/* with its own router, so when the auth gate returned None for your API key the slice path called get_stored_token(db, user=None) and fell through to the auth-disabled global Settings table, which is empty on every auth-enabled deployment. Same bug as #1182, just on a different router.

The shape that landed:

New route-level dep resolve_api_key_cloud_owner in cloud.py. It's permissive on purpose: returns the API key's owner User when the key has can_access_cloud=true, otherwise None — never raises. That lets us add it to non-/cloud/* routes without breaking the local-presets path. A request via an API key that lacks the cloud scope still slices fine against local presets and only 400s with the existing "no Bambu Cloud session" error if the request actually selects a cloud preset.
Wired into POST /library/files/{id}/slice (your repro) and GET /slicer/presets (same root cause, would hit anyone driving the SliceModal through an API key). Both routes now derive their cloud-token owner via current_user or api_key_cloud_owner
instead of falling back to None.
The auth gate's None-return for API keys is unchanged. Keeping the owner-resolution scoped to the routes that actually need a cloud token prevents scope creep into other routes that intentionally fence on current_user is None.

Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you.

If you find Bambuddy useful, please consider giving it a ⭐ on GitHub — it helps others discover the project!

@maziggy commented on GitHub (May 2, 2026): Good catch — and apologies that the first fix only covered half the surface. You found the gap: the /cloud/* router got the owner-resolution treatment, but the slice route lives on /library/* with its own router, so when the auth gate returned None for your API key the slice path called get_stored_token(db, user=None) and fell through to the auth-disabled global Settings table, which is empty on every auth-enabled deployment. Same bug as #1182, just on a different router. The shape that landed: - New route-level dep ``resolve_api_key_cloud_owner`` in cloud.py. It's permissive on purpose: returns the API key's owner User when the key has ``can_access_cloud=true``, otherwise None — never raises. That lets us add it to non-/cloud/* routes without breaking the local-presets path. A request via an API key that lacks the cloud scope still slices fine against local presets and only 400s with the existing "no Bambu Cloud session" error if the request actually selects a cloud preset. - Wired into POST /library/files/{id}/slice (your repro) and GET /slicer/presets (same root cause, would hit anyone driving the SliceModal through an API key). Both routes now derive their cloud-token owner via ``current_user or api_key_cloud_owner`` instead of falling back to None. - The auth gate's None-return for API keys is unchanged. Keeping the owner-resolution scoped to the routes that actually need a cloud token prevents scope creep into other routes that intentionally fence on ``current_user is None``. Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you. ----- If you find Bambuddy useful, please consider giving it a ⭐ on [GitHub](https://github.com/maziggy/bambuddy) — it helps others discover the project!

BreizhHardware referenced this issue

2026-05-06 12:35:21 +02:00

[PR #1029] [MERGED] v0.2.3 final #1149