I am currently following "Upload Files to BIM 360 Document Management" and I'm stuck on step 6 where I'm suppose to upload to the client's bucket using 3-legged access token.
So...am I doing something wrong for step 6, or the guide is outdated?
From reading the PUT buckets/:bucketKey/objects/:objectName documentation, only 2-legged access token can access this API.
expected:
200 (and whatever json data it returns)
actual:
403
{
"reason": "Only 2 legged service tokens are allowed to access this api."
}
Unfortunately some of the OSS (bucket) endpoints only support 2 legged auth and PUT Object is obviously one of them so you will need another 2 legged token for the upload...
The guide is not exactly outdated but apparently that's an oversight there...
Related
I'm trying to pubhlish a project using this guide - https://forge.autodesk.com/en/docs/data/v2/tutorials/publish-model/
I am able to get the docs hub ID for the expected hub (using 3 legged token, after having Autodesk provision the b360 docs account, and setting up integration w/ forge app), and pass this into the call to get the projects (using same token, or new token) using this guide - https://forge.autodesk.com/en/docs/data/v2/reference/http/hubs-hub_id-projects-GET/
I get back a response 404 error using the hub ID provided in the GET hubs call that starts with b.xxx from the GET hubs
{
"developerMessage": "The requested resource does not exist.",
"moreInfo": "https://forge.autodesk.com/en/docs/oauth/v2/developers_guide/error_handling/",
"errorCode": ""
}
I've tried this with a. as well, instead of b. and also no prefix on hub ID with no luck. I verified that this Id matches what is shown in the account admin settings online as well.
The get request looks like this, and includes authorization token in format Bearer {{token}} where {{token}} is the (same) variable for the token that works when getting hub ID's.
https://developer.api.autodesk.com/project/v1/hubs/b.e3a26052-6b48-4a03-9115-xxxxxxxxxxx/projects
Is my format incorrect, or is there something else going on?
The request looks ok, incl. the hub ID (the b. prefix must be there). One thing to check for is whether the actual user you're using to obtain the 3-legged token has access to any projects inside this hub.
Also, what happens when you try the GET hubs/:hub_id endpoint? Can you see the hub information or do you get 404 as well?
I'm trying to set up an Signed URL for an Design Automation Workflow which is triggered by an Webhook inside of the BIM360 OSS. If a file is added the webhooks triggers an endpoint to start a Design Automation. The webhook is working. And the Design Automation is working too. The Problem occurs if i try to wire both up. I#m trying to create a Signed URL of the File like suggested in this post from Petr Broz link stackoverflow.
To use this API it is requierd to use an Token which is obatined by 2-Legged-Auth which is working with all necessary Scopes. In the response of the Webhook is an ID for the Folder and Version. The API is recognizing the ID.
The problem occurs in the response of this endpoint to create the signed url: https://developer.api.autodesk.com/oss/v2/buckets/:bucketKey/objects/:objectKey/signed
I'm using the wip.dm.emea as bucket because the file is stored in the EU BIM360 OSS.
The response is a 403 Forbidden:
{
"reason": "Only the bucket creator is allowed to access this api."
}
Is it even possible to get the File ID like in this example Forge how to Download File ?
Because this Solution requires a 3-Legged-Auth Flow which is not possible for a complete Automation.
The thing which makes me question is, that you can achieve this Workflow in plane Forge. But not in BIM360 where i have no control over the Buckets that are created by the System!?
I think this is an architectural missmatch between the Forge API and the BIM360 implementation!? Will there be a solution for this in the future?
Best regards
Jan
Unfortunately, I can confirm that it's not possible to create a signed URL for your BIM360 storage currently, as the error message mentioned, the endpoint requires the bucket owner to do this operation, this is what it is now. But I agree with you that this should be an architecture mismatch between Forge OSS and BIM360 implementation, and it's already been requested in our system, please keep "CPOSS-1066" to check with us about the progress.
As for the current way, you can keep the 3 legged token and using that for the output Url and also in the onComplete() callback, I have the blog post https://forge.autodesk.com/blog/upload-your-design-automation-output-file-bim360-docs which details the way to work, hope it helps at this moment.
I have tried the endpoints to get projects and users with a three legged token, and in both cases I get a 403 with a response body that looks like:
{
"code": 1003,
"message": "Only support 2 legged access token."
}
This seems unequivocal, but doesn't seem to be consistent with the API documentation. Is access really only available using a 2 legged token or have I missed something?
Just to be clear, the endpoints I'm playing with are:
GET https://developer.api.autodesk.com/hq/v1/accounts/:account_id/projects
and
GET https://developer.api.autodesk.com/hq/v1/accounts/:account_id/users
The documentation states "Must be Bearer , where is obtained via OAuth", but there is no mention that only two legged authentication tokens are supported.
Yes, they are BIM360 HQ APIs (well known as Account Admin APIs), part of BIM360 API as I mentioned in the comment above.
Unfortunately, Account Admin APIs only allow access with 2 legged access token now. In contrast, other APIs like Issues, RFIs, and Checklists support 3 legged access token and 3 legged access token with the uid.
Note:
Keyword user context required in the Authentication Context of the documentation means that it requires acting with a 3-legged OAuth token or a 2-legged OAuth token with user impersonation.
Keyword app only means that it supports 2-legged OAuth token only.
I know Autodesk Forge "Object Storage Service" (OSS) requires a 2-legged security token...
I already use a 3-legged token to access Forge "Project Service" and "Data Service" APIs: is it possible to convert or request a 2-legged token from a 3-legged token?
If you try to use a 3-legged token with OSS you get a invalid token error.
I would like to avoid using two different authentication at the same time...
Thanks!
Unfortunately token exchange is not possible - I checked the oAuth 2.0 specification, and I don't think the flow you describe is a valid flow anyway. Remember 2 legged is for application credentials, whereas 3 legged is to access a specific user content.
No, a 2-legged token gives you the access to developer's resources. A 3-legged token gives you access to the logged in user's resources. They are not designed to be interchangeable.
Anybody can help or enlighten me with my issue:
I'm a Java developer and I have an existing smart printer app called GDrive App. It uses Google Drive API (oauth 2.0, gdata-version 2.0 and 3.0 for download-print file) .
This has been working for months until now. Actually, only the download-printing part is no longer working this time, I can still access the app (retrieve files, create folder, search and delete files).
Actual problem:
I keep on getting 401 error when I try to download file (to input stream) for printing. It's confusing because I already provided all the necessary information during the request. And it has been working for many months. No changes of the code. Weird.
I have this for headers:
[Authorization: Bearer ya29.CjAkA8uPBUsKWYMSEDpPxUbP_vtQJOKfCZ7O8I4GkpUkN70bGgnDTAVYiVW2m353H2Y
, GData-Version: 3.0
]
While executing this URL to download and print resource, I couldn't access this.
https://doc-0o-7o-docs.googleusercontent.com/docs/securesc/l9c2gms12ko7qqfc58putbb2v38kkvmm/dp5l9kmpu48kdi8mp2rvtmc1dm1f41tk/1468828800000/09859633411849852329/09859633411849852329/0ByU-nFK_03gtZGhBZkxCYmExeGc?e=download&gd=true
Error 401 means that you aren't authorized properly. Most likely the ya29.CjAkA8uPBUsKWYMSEDpPxUbP_vtQJOKfCZ7O8I4GkpUkN70bGgnDTAVYiVW2m353H2Y access token you are using expired and you have to request another.
You should write your code to anticipate the possibility that a granted token might no longer work. A token might stop working for one of these reasons:
The user has revoked access.
The token has not been used for six months.
The user changed passwords and the token contains Gmail, Calendar,
Contacts, or Hangouts scopes.
The user account has exceeded a certain number of token requests.
source
You can use GoogleAuthorizationCodeTokenRequest to request an access token and possibly a refresh token.