How QCSB Handles Signed Provider Folder Identifiers

This article explains that remote providers such as Google Drive and OneDrive may use signed/validated folder identifiers in frontend navigation instead of exposing arbitrary provider paths or trusting client input.

What you need to know

Basic includes Local storage and the first active Workspace. Pro adds FTP/SFTP, multiple Workspaces, advanced permissions, and background continuation. Max/All Access adds Google Drive, OneDrive, Private Connections, Recovery Vault management, and bulk operations.
A plan gate decides whether a feature exists at the current Effective tier. Joomla access and QCSB permission rules separately decide whether a particular user may use that feature.
Google Drive/OneDrive deep navigation can carry signed short-lived provider object identifiers. The signature binds the object ID to the user, Workspace, location, relative path, and expiration so a modified token is rejected.

Why cloud folders need signed identifiers

Google Drive and OneDrive can address objects by provider IDs that are not meaningful filesystem paths. QCSB can carry those identifiers in frontend navigation, but it signs/binds them so a raw provider ID copied from elsewhere is not sufficient authority.

Validation boundary

The signed value is tied to the current user, Workspace/location, represented path/object and expiration.
A modified signature, expired value, cross-user reuse, wrong Workspace/location, or object/path mismatch is rejected.
After validation, QCSB still applies the saved exact-root and permission rules before provider access.

Troubleshooting

If a file action fails, retry with one small test item and read Transfer Details or the operation toast before changing global settings.

Community Discussion

For practical QCSB workflows and discussion with other Joomla site owners, visit the QC Storage Bridge Community. For private support, bug reports, account-specific entitlement issues, or feature requests, use the QuantaCade support system.