You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Generally, the object_storage_url is built from OS_AUTH_URL, OS_PROJECT_ID and other similar variable. In php-opencloud/openstack it's retrieved from the JSON payload obtained from POST /v3/auth/tokens (in token.catalog.endpoints[type=="object-store"][interface == "xx"].url)
Still, the Python Swift client allows for another alternative: OS_STORAGE_URL
This allows to use a distinct storage-url unrelated from said variable.
This is useful (= actually necessary) in the context of application credentials, where an application credential is generated within a given project, but used to access an object container in another project (whose ACLs have been configured). In such a case we can't rely on the URL generation logic.
This is need to give a use for cross-projects #336
Let's remind that some Openstack hosting solution do not offer multiple users, but only multiple projects, making cross-project application credentials the only secure way to grant access to an object container which implies supporting the OS_STORAGE_URL override.
In a more generic way, it means giving the ability to override OpenStack\Identity\v3\Models\Service::getUrl() from the configuration (this class as not access to)
The text was updated successfully, but these errors were encountered:
drzraf
pushed a commit
to drzraf/openstack
that referenced
this issue
Jan 13, 2022
Generally, the object_storage_url is built from
OS_AUTH_URL
,OS_PROJECT_ID
and other similar variable. In php-opencloud/openstack it's retrieved from the JSON payload obtained fromPOST /v3/auth/tokens
(intoken.catalog.endpoints[type=="object-store"][interface == "xx"].url
)Still, the Python Swift client allows for another alternative: OS_STORAGE_URL
This allows to use a distinct storage-url unrelated from said variable.
This is useful (= actually necessary) in the context of application credentials, where an application credential is generated within a given project, but used to access an object container in another project (whose ACLs have been configured). In such a case we can't rely on the URL generation logic.
This is need to give a use for cross-projects #336
Let's remind that some Openstack hosting solution do not offer multiple users, but only multiple projects, making cross-project application credentials the only secure way to grant access to an object container which implies supporting the OS_STORAGE_URL override.
In a more generic way, it means giving the ability to override
OpenStack\Identity\v3\Models\Service::getUrl()
from the configuration (this class as not access to)The text was updated successfully, but these errors were encountered: