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 https://github.com/php-opencloud/openstack/pull/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)
Generally, the object_storage_url is built from
OS_AUTH_URL,OS_PROJECT_IDand 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 https://github.com/php-opencloud/openstack/pull/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)