Access Denied

[nergal]

I get access denied (403) when trying to get backupfiles for a backup.

URL: https://<server>/api/backups/<backup_id>/backupFiles?format=Entity

But it works fine using the web-API interface:
URL: https://<server>/web/#/api/backups/<backup_id>/backupFiles?format=Entity

What's causing this? I'm using the same user in both cases.

[benyoung]

Hi Nergal - This looks ok in my environment just now doing a few isolated tests with a portal administrator user against my dev enterprise manager.

You might want to provide us some more detail around how you are accessing it, examples of the request/response including headers. Given you have a 403 and not a 401 it would indicate that you are authenticated and passing the correct header but potentially it might be a permissions issue - although as you say same user same server different end points different results a bit odd. By web-api interface what system are you talking about here as the documented endpoints are the ones listed first in your post.

Ben

[nergal]

By web-api I mean the interface where you add /web/#/ infront of the api scope so that the page is presented parsed and you can click links etc.

I was thinking about cookies. But the only cookie I get in "set-cookie" header is the session-id which I set in the x-restsvcsessionid header. I've tried to set the whole "set-cookie" as a "cookie "as well but that didn't make any difference. Permissions wise it seems strange since chrome just acting as as REST client.

My scenario is this:
1. Get all backups for a job UID using the query format: /api/query?type=Backup&format=Entities&pageSize=1000&filter=JobUid==\"#{job_id}\"
2. For each backup get BackupFileReferenceList href.
3. For each BackupFuleReferenceList href add ?format=Entity which result in:
"Error" => {
"Message" => "Access denied.",
"StatusCode" => "403"
}

The only header I have is the session ID set so that I have a session up and running. And most calls works fine except for this.

I've tried the same call in chrome but I can't see any other headers set for the BackupFiles request. But there it works.

[benyoung]

I am not 100% sure why you are doing it that way and it might be why you are running into issues - maybe i missed something? If it were me just use the documented method

1) POST to /api/sessionMngr/?v=latest and pass in a Basic auth header (user:password pair) - Doc here - https://helpcenter.veeam.com/docs/backu ... tml?ver=95
2) The response will return a bunch of accessible endpoints based on your security level but you are actually interested in the header that is returned X-RestSvcSessionId
3) Use the header value returned above to pass in that value for every subsequent API via the X-RestSvcSessionId header
4) As an alternative but not the design i use is that logon process will return a set-cookie header with the same value if you are using a cookiecontainer or similar to process further requests in the same process flow on your side

[nergal]

Yes, that's what I'm doing, before I continue doing the scenario I specified in my previous post. So I perform the auth with version 1_3 and set the X-RestSvcSessionId. After that I can perform almost all operations using the session ID. Except for the one listing BackupFiles. And that's the issue. I can't see any difference between my ruby rest client (httparty) and using google-chrome.

[nergal]

Solved!

I had configured version "1_3" instead of "v1_3" for my login request. Which worked fine for all requests except listing backup files. :/

That took a while to find I can tell!

[veremin]

That's why we always recommend reviewing the schema first.

Anyway, glad to hear that you've finally solved your issue.

Thanks.