#438 - [GH-ISSUE #665] [Feature]: Cloud Profiles - Multiple Users [Maybe Bug?] - starred/bambuddy-maziggy-1

BreizhHardware commented

2026-05-07 00:10:09 +02:00

Owner

Originally created by @cadtoolbox on GitHub (Mar 10, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/665

Originally assigned to: @maziggy on GitHub.

Problem or Use Case

Maybe I'm confused on how cloud profiles are supposed to work. If I sign-in to the cloud profiles tab as my own Bambu account, now every user using Bambuddy is shown as signed in as me. Is this the way it's supposed to work? I would have thought each user signs in using their own account.
If I give them Cloud Auth permission, they can sign out and sign-in as themselves but then I see their account now.
Do we need to create a generic Bambu account to use for everyone in Bambuddy or is this a bug?

I really just want to be able to use any filament currently loaded into all our printers in Bambu Studio with nozzle context properly set.

Proposed Solution

Either the documentation needs to explain how this works better or allow each user to sign-in as their own account.

Alternatives Considered

No response

Feature Category

Print Archiving

Priority

Nice to have

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 @cadtoolbox on GitHub (Mar 10, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/665 Originally assigned to: @maziggy on GitHub. ### Problem or Use Case Maybe I'm confused on how cloud profiles are supposed to work. If I sign-in to the cloud profiles tab as my own Bambu account, now every user using Bambuddy is shown as signed in as me. Is this the way it's supposed to work? I would have thought each user signs in using their own account. If I give them Cloud Auth permission, they can sign out and sign-in as themselves but then I see their account now. Do we need to create a generic Bambu account to use for everyone in Bambuddy or is this a bug? I really just want to be able to use any filament currently loaded into all our printers in Bambu Studio with nozzle context properly set. ### Proposed Solution Either the documentation needs to explain how this works better or allow each user to sign-in as their own account. ### Alternatives Considered _No response_ ### Feature Category Print Archiving ### Priority Nice to have ### Mockups or Examples _No response_ ### Contribution - [ ] 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-07 00:10:09 +02:00

closed this issue
added the
enhancement
label

BreizhHardware commented

2026-05-07 00:10:09 +02:00

Author

Owner

@maziggy commented on GitHub (Mar 12, 2026):

You're right, cloud credentials are currently stored globally (one Bambu Cloud account per Bambuddy instance), so when any user logs in, it overwrites the previous login for everyone.

This has been fixed in the next release. Each user now gets their own Bambu Cloud credentials stored on their user record. When you log into Bambu Cloud, it only affects your own session — other users keep theirs.

One open question: How should API keys handle cloud access?

API keys are used for automation/scripts and aren't tied to a specific user. With per-user cloud credentials, there's no obvious Bambu Cloud account to use when a request comes in via API key. Two options:

API keys can't access cloud endpoints — cleanest approach, since cloud data is inherently per-user. Scripts that need cloud data would use a JWT token instead.
Admins can configure an "instance" cloud account for API key / automation use — more flexible but adds complexity.

Does anyone here use API keys to access cloud endpoints (filament info, devices, firmware updates, etc.)? If so, option 2 would be important. Otherwise option 1 keeps things simple.

@maziggy commented on GitHub (Mar 12, 2026): You're right, cloud credentials are currently stored globally (one Bambu Cloud account per Bambuddy instance), so when any user logs in, it overwrites the previous login for everyone. This has been fixed in the next release. Each user now gets their own Bambu Cloud credentials stored on their user record. When you log into Bambu Cloud, it only affects your own session — other users keep theirs. One open question: How should API keys handle cloud access? API keys are used for automation/scripts and aren't tied to a specific user. With per-user cloud credentials, there's no obvious Bambu Cloud account to use when a request comes in via API key. Two options: 1. API keys can't access cloud endpoints — cleanest approach, since cloud data is inherently per-user. Scripts that need cloud data would use a JWT token instead. 2. Admins can configure an "instance" cloud account for API key / automation use — more flexible but adds complexity. Does anyone here use API keys to access cloud endpoints (filament info, devices, firmware updates, etc.)? If so, option 2 would be important. Otherwise option 1 keeps things simple.

BreizhHardware commented

2026-05-07 00:10:09 +02:00

Author

Owner

@maziggy commented on GitHub (Mar 12, 2026):

If you want to test, please use branch dev (which is btw the new global dev branch you can use for PR's).

@maziggy commented on GitHub (Mar 12, 2026): If you want to test, please use branch dev (which is btw the new global dev branch you can use for PR's).

BreizhHardware commented

2026-05-07 00:10:10 +02:00

Author

Owner

@cadtoolbox commented on GitHub (Mar 12, 2026):

Keep it simple until someone complains ;)

@cadtoolbox commented on GitHub (Mar 12, 2026): Keep it simple until someone complains ;)

BreizhHardware commented

2026-05-07 00:10:10 +02:00

Author

Owner

@maziggy commented on GitHub (Mar 16, 2026):

Is it working for you?

@maziggy commented on GitHub (Mar 16, 2026): Is it working for you?

BreizhHardware commented

2026-05-07 00:10:10 +02:00

Author

Owner

@cadtoolbox commented on GitHub (Mar 16, 2026):

I have issues testing Bambu cloud login using my local test version:
This probably opens a can of worms but I'm posting it for some considerations.

The user is experiencing two related errors when trying to log into Bambu Cloud:

Frontend: POST http://localhost:8000/api/v1/cloud/login 401 (Unauthorized)
Backend: [backend.app.services.bambu_cloud] Login request failed: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1081)

After analyzing the codebase, the issue is clear:

The frontend calls the backend API at /api/v1/cloud/login
The backend API route in backend/app/api/routes/cloud.py calls BambuCloudService.login_request()
BambuCloudService in backend/app/services/bambu_cloud.py uses httpx.AsyncClient() with default SSL verification
The SSL certificate verification fails when connecting to https://api.bambulab.com
This causes a BambuCloudAuthError which gets converted to a 401 HTTP response

Root Cause

The BambuCloudService class creates an httpx.AsyncClient with default SSL verification settings. However, the local environment appears to have SSL certificate verification issues (possibly due to corporate firewalls, outdated certificate stores, or Python SSL configuration issues).

Interestingly, other services in the codebase (bambu_mqtt.py, bambu_ftp.py, camera.py) already disable SSL hostname verification for connecting to Bambu Lab devices, suggesting this is a known pattern in this codebase for Bambu Lab connectivity.

Solution

Modify the BambuCloudService class in backend/app/services/bambu_cloud.py to disable SSL verification for connections to Bambu Lab's API servers. This follows the same pattern already established in other Bambu Lab services in the codebase.

Implementation Plan

Update BambuCloudService SSL Configuration:
- Modify line 38 in backend/app/services/bambu_cloud.py where the httpx client is created
- Add verify=False parameter to disable SSL certificate verification
- This matches the pattern used in other Bambu Lab services like bambu_mqtt.py, bambu_ftp.py, and camera.py

Critical Files

backend/app/services/bambu_cloud.py: Main fix location (line 38)

Verification

Test the login flow:
- Start the backend server
- Open the frontend
- Try to log into Bambu Cloud with valid credentials
- Verify the SSL error is resolved and login proceeds to verification step
Check logs:
- Verify no more SSL certificate verification errors in backend logs
- Confirm the login request reaches Bambu's servers successfully
Test complete authentication flow:
- Complete login with email/TOTP verification
- Verify cloud features work (settings sync, device list, etc.)

Notes

This solution disables SSL verification specifically for Bambu Lab API connections, which is consistent with how other Bambu Lab services in this codebase handle SSL
The httpx client is only used for communication with Bambu Lab's servers, not for general internet requests
This is a common workaround for corporate environments or systems with certificate chain issues

@cadtoolbox commented on GitHub (Mar 16, 2026): I have issues testing Bambu cloud login using my local test version: This probably opens a can of worms but I'm posting it for some considerations. ------------------------------------------------------------------------------- The user is experiencing two related errors when trying to log into Bambu Cloud: 1. **Frontend**: `POST http://localhost:8000/api/v1/cloud/login 401 (Unauthorized)` 2. **Backend**: `[backend.app.services.bambu_cloud] Login request failed: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1081)` After analyzing the codebase, the issue is clear: - The frontend calls the backend API at `/api/v1/cloud/login` - The backend API route in `backend/app/api/routes/cloud.py` calls `BambuCloudService.login_request()` - `BambuCloudService` in `backend/app/services/bambu_cloud.py` uses `httpx.AsyncClient()` with default SSL verification - The SSL certificate verification fails when connecting to `https://api.bambulab.com` - This causes a `BambuCloudAuthError` which gets converted to a 401 HTTP response ## Root Cause The `BambuCloudService` class creates an `httpx.AsyncClient` with default SSL verification settings. However, the local environment appears to have SSL certificate verification issues (possibly due to corporate firewalls, outdated certificate stores, or Python SSL configuration issues). Interestingly, other services in the codebase (`bambu_mqtt.py`, `bambu_ftp.py`, `camera.py`) already disable SSL hostname verification for connecting to Bambu Lab devices, suggesting this is a known pattern in this codebase for Bambu Lab connectivity. ## Solution Modify the `BambuCloudService` class in `backend/app/services/bambu_cloud.py` to disable SSL verification for connections to Bambu Lab's API servers. This follows the same pattern already established in other Bambu Lab services in the codebase. ## Implementation Plan 1. **Update BambuCloudService SSL Configuration**: - Modify line 38 in `backend/app/services/bambu_cloud.py` where the httpx client is created - Add `verify=False` parameter to disable SSL certificate verification - This matches the pattern used in other Bambu Lab services like `bambu_mqtt.py`, `bambu_ftp.py`, and `camera.py` ## Critical Files - `backend/app/services/bambu_cloud.py`: Main fix location (line 38) ## Verification 1. **Test the login flow**: - Start the backend server - Open the frontend - Try to log into Bambu Cloud with valid credentials - Verify the SSL error is resolved and login proceeds to verification step 2. **Check logs**: - Verify no more SSL certificate verification errors in backend logs - Confirm the login request reaches Bambu's servers successfully 3. **Test complete authentication flow**: - Complete login with email/TOTP verification - Verify cloud features work (settings sync, device list, etc.) ## Notes - This solution disables SSL verification specifically for Bambu Lab API connections, which is consistent with how other Bambu Lab services in this codebase handle SSL - The httpx client is only used for communication with Bambu Lab's servers, not for general internet requests - This is a common workaround for corporate environments or systems with certificate chain issues

BreizhHardware commented

2026-05-07 00:10:10 +02:00

Author

Owner

@cadtoolbox commented on GitHub (Mar 16, 2026):

@maziggy Regardless of all that... it works as expected now. Each user has their own Bambu login.

@cadtoolbox commented on GitHub (Mar 16, 2026): @maziggy Regardless of all that... it works as expected now. Each user has their own Bambu login.

BreizhHardware commented

2026-05-07 00:10:10 +02:00

Author

Owner

@maziggy commented on GitHub (Mar 17, 2026):

I don't think we should disable SSL verification for the cloud API connection.

The other services (bambu_mqtt.py, bambu_ftp.py, camera.py) disable SSL verification because they connect to local printer hardware using self-signed certificates — that's expected and necessary. The cloud API at api.bambulab.com has a valid public certificate, so SSL verification should work and should stay enabled since we're sending login credentials over that connection.

The CERTIFICATE_VERIFY_FAILED error is almost always a local environment issue — outdated CA certificate bundle, corporate firewall/proxy intercepting TLS, or Python not finding the system cert store. Common fixes:

pip install --upgrade certifi
On Linux: make sure ca-certificates is installed and up to date
If behind a corporate proxy: add the proxy's CA cert to your trust store

@maziggy commented on GitHub (Mar 17, 2026): I don't think we should disable SSL verification for the cloud API connection. The other services (bambu_mqtt.py, bambu_ftp.py, camera.py) disable SSL verification because they connect to local printer hardware using self-signed certificates — that's expected and necessary. The cloud API at api.bambulab.com has a valid public certificate, so SSL verification should work and should stay enabled since we're sending login credentials over that connection. The CERTIFICATE_VERIFY_FAILED error is almost always a local environment issue — outdated CA certificate bundle, corporate firewall/proxy intercepting TLS, or Python not finding the system cert store. Common fixes: - pip install --upgrade certifi - On Linux: make sure ca-certificates is installed and up to date - If behind a corporate proxy: add the proxy's CA cert to your trust store

Rows
Columns

[GH-ISSUE #665] [Feature]: Cloud Profiles - Multiple Users [Maybe Bug?] #438

Problem or Use Case

Proposed Solution

Alternatives Considered

Feature Category

Priority

Mockups or Examples

Contribution

Checklist

Root Cause

Solution

Implementation Plan

Critical Files

Verification

Notes