Unity CCD Management API CORS Policy issue

Hi! I've already posted another thread ( https://discussions.unity.com/t/876521 ) explaining that I've started working with Cloud Content Delivery service last week and I'm trying to manage posting and getting content of my buckets through the management API. My workflow is the next one:

  • I post some assets (not Addressables, just individual assets) using a Unity Editor tool - so, I post some entries, one for each asset, and then update its content with the corresponding asset.
  • I get that assets in an external Blazor app.

The assets in question are basically images and json files, so they don't give me much problems working with them. The other problem I'm facing appears when I try to get the assets from the bucket using an external hosted WebAssembly Blazor app.

I'm using the Management API to make GET requests and not the Client API because there isn't a GetAllEntries endpoint in the Client API. So, I need authentication with APIKey to get access to the Management API endpoints. Then, I add an authorization header to the HttpClient I'm using to make the requests to the API and, when I'm running any request, I get the next error:

As far as I understand, since I'm trying to access endpoints from an external domain, the API domain is blocking my domain since it is not allowed to use the authorization header. I've checked if I'm using the incorrect authorization header, but it's the same the Swagger UI implementation of the API documentation uses and if I make the request in Postman using that authorization header, I get the expected result.

I can't post code because of a NDA.

Looking at your implementation, it seems that every request, whether going through the Client API endpoints or Management endpoints has the authorization header set. What I think may be happening here is that when you call the client api endpoints with that authorization header set and get redirected, your http client may also be trying to send the authorization header to the redirect. Could you validate that may be the case? I suspect that's why it may work in Postman and not locally through your code. If that is the case, I would only specify the authorization header on management api endpoints.

If this issue persists, it would be really helpful if we could get the rest request data to see if there's anything on our end. Though do be mindful about redacting sensitive fields if you do decide to provide that information for us.

I hope this helps!

The fact is I don't know why it makes that redirection. I'm trying to access the management endpoint, not the client one, but somehow it redirects to the client endpoint.

Here I made another type of request and got a different CORS policy error without redirection8003495--1029332--upload_2022-3-29_15-25-11.png

It looks like you have an extra / after the "v1" and before "buckets". I'm not sure if that has anything to do with it.

The reason for the redirect is that the service is redirecting you to where we actually store the content.

Okay, I fixed the problem with the address and then, when it tries to access the content of the entry, gives the original CORS policy error because of the redirection. It's the Client API the one that doesn't allowed me to have authorization headers. So, what I should do? Using directly the Client API endpoint for getting the content of the entry without any authorization header?

The curious thing is that this problem also happens when you try to access the GetContent endpoint of the Management API throught the API documentation Swagger UI - it gives you a "Failed to fetch" error.


Ah yes it does appear that it's happening at the redirect in the swagger UI as well. You can validate that in the inspection tools. You'd see that the actual content url request returns a 307 redirect that points you to where the content is stored. My recommendation is that you should use the client api endpoint directly without the authorization header. If you try that do you still get the same CORS error?

In the meantime, I'll log something to investigate why our swagger UI doesn't redirect properly as expected.

Hi Ryan! I change the request calls to get content from an entry to do it through the Client API and it's working finally!

Although, I don't understand why there is an endpoint in the management API that redirects automatically to the equivalent one of the client API, which blocks the request because of the authorization header. Wouldn't be easier if the client API accept authorization headers? In fact, Client API tells that if you are trying accessing a private bucket, you require to add a authorization header with the access token.

Thank you so much for the help!

1 Like

Some updates about the research I made about this issue:

The bucket whose entry content I was trying to access through the Management API endpoint was public, so, when you use the Client API equivalent endpoint, it doesn't need any authorization header. But the bucket is private, you have to add an authorization header when you use the Client API endpoint with the bucket access token. Which means that the endpoint will allow authorization headers, so if you trying to access the entry content of a private bucket through the Management API endpoint with the APIKey authorization header, it retrieves the content perfectly and there's no CORS policy error.

To sum up, the possible situations:

Trying to access content of a entry in a PUBLIC bucket:

  • Through Management API endpoint with APIKey authorization header -> Redirects to Client API endpoint -> CORS policy error (doesn't allow authorization header)
  • Through Client API endpoint without any authorization header -> CORRECT

Trying to access content of a entry in a PRIVATE bucket:

  • Through Management API endpoint with APIKey authorization header -> Redirects to Client API endpoint -> CORRECT
  • Through Client API endpoint with Bucket Access Token authorization header -> CORRECT

I still think that it would be easy if Client API endpoints accept authorization headers without depending on if you are using a private or a public bucket.

Thank you for this feedback! It is incredibly appreciated and needed to make our service better. I'll take this back to the team and we'll log it in our backlog!

Hi there! I've just found a new CORS policy issue about allowed headers. I have to get some images from my bucket and, in order to make loading times as short as possible, I want to use the browser cache to save those images in it the first time I get them and load them directly from cache the next times.

To achieve that, I found it should be really easy if I add a Cache-Control header to my requests, but when I add it, I get a CORS policy error because that header is not allowed. As we found with the last issue, that header is not allowed by the Client API endpoints, since the endpoint that is giving me problems is the GetContent endpoint (I'm using the Management API equivalent endpoint, but it gets redirected to the Client API) and, another endpoint, like the GetEntryByPath endpoint (which "stays" in the Management API) does allow the cache header.

Here I show the Network trace when I use my application with Chrome. In the first query, the GetEntryByPath query, it can be seen in the right part (in the "Encabezados de respuesta" section) that the cache-control header is allowed.

Then, the GetContent query returns a 307 status code and inside the "Encabezados de respuesta" doesn't show any allowed headers. The location field indicates that the real content is inside another URL, which corresponds to the Client API endpoint and would be used to make the proper redirection.

In this case, I think I can't make anything similar to the solution to the previous issue, because I think there is no option in the bucket configuration that will allow using a cache-control header. So it would be really appreciated if the Client API endpoints start to allow some needed headers.

Thank you in advance