I have an app that I'm building that utilizes the Autodesk viewer javascript library/API. If I upload a series of .iam & .ipt files for a product, and what to share it with some clients, but I don't want to give away intellectual property, such as being able to use the measure tool, or not being able to select certain sub-parts.
I know you can disable certain toolbars (which can be undone in the js console) or remove them entirely via headless mode, but considering the browser has to access to the access token, a clever person could use that token with the proper URN, and get full access to the data. Correct?
So is there a recommended way to protect our models so that viewers of it cannot take our intellectual property??
To completely remove the attach surface with the info available to the browser agent is proxying - see this blog post for details. Basically you are redirecting Viewer to access our endpoints via your own proxy service where the access token can be assigned implicitly, eliminating the need to expose access tokens to browser agents directly:
Autodesk.Viewing.setApiEndpoint('https://yourproxyurl')
W/o the access token, having access to only the Object IDs/URNs of your models would be futile as all our endpoints to retrieve model data are secured by requiring a valid access token with sufficient token scopes.
Related
The Forge documentation mentions “If you need an end user to authorize your app to act on the user’s behalf, you’ll want to check out this tutorial.” This makes it sound as if our app will be doing something from OurApp → Forge, reaching into Fusion data, pulling it out. Our desired action would be the user acting on their own behalf, with authorized permission, sending files to their account on OurApp.
I've genericized it, but our specific situation is as follows: we want Fusion360 users to be able to install our plugin and then send models in STL format (model derivative v2 API) to our service for 3D Printing or sharing with others. This same behavior exists for Tinkercad and is very popular, but the requirements change for Fusion, now that it is not a web app like Tinkercad.
Autodesk Forge uses OAuth 2.0 as its authentication strategy, and as part of that, the platform allows you to choose between two-legged and three-legged authentication.
Two-legged authentication means that a trust is established between your own application (with credentials that are generated for you when you create a Forge app on https://forge.autodesk.com) and the Forge services. Your application can manage its own data but it does not have access to your users data in other Forge applications.
Three-legged authentication means that a trust is established among 3 entities: your application, Forge, and your user. With an access token generated using 3-legged authentication, your application can also access the user's content in other Forge applications, for example, in BIM360 or Fusion Teams.
With that, if you plan on having your users upload STL files from a locally running instance of Fusion 360, you can use the simple 2-legged authentication and have your Forge application own and manage the uploaded data and the translated derivatives. But if you wanted to upload or download STLs to/from something like Fusion Teams, you would need the 3-legged auth workflow.
I'm not really familiar with Autodesk's instruments, so maybe anyone could help me with Auth:
I have 2-legged auth with forge, and i need to refresh token automatically or simply make my viewer persistent.
Also any help/links/references on points of interest or how to add floor switching feature to the project?
Typically, when setting up the viewer, you provide a function the viewer will call whenever it needs a fresh 2-legged token. This function should make a request to your server-side logic to generate the new token. The Learn Forge - View Your Models tutorial guides you through this process, using different languages and runtimes. For example, here's how you could implement the token updating in Node.js:
https://github.com/Autodesk-Forge/learn.forge.viewmodels/blob/nodejs/routes/oauth.js#L26-L36
https://github.com/Autodesk-Forge/learn.forge.viewmodels/blob/nodejs/public/js/ForgeViewer.js#L46-L52
Btw. a "refresh token" is only available in 3-legged auth workflows.
For features like floor switching, take a look at these:
https://forge.autodesk.com/blog/view-each-floor-using-vertical-explode
https://twitter.com/ipetrbroz/status/1227901732023201795
Since BIM360 allows users to disable 2-factor authentication for themselves one of our clients requires a way to prevent access to files / monitor if users turn this feature off.
For forge-applications managed by me I got this covered through following endpoint :
https://forge.autodesk.com/en/docs/oauth/v2/reference/http/users-#me-GET/
Problem is, users without 2-fa can then still access the files if they go directly through the BIM 360 docs webapp (docs.b360.autodesk.com). Is there a way to restrict acces on the bim360docs platform based solely on 2-fa or a way to use the users-#me endpoint in a way that allows me to monitor a project when those users aren't logging in on my applications?
Sorry, this information is only accessible for the current user (who authorized the 3 legged access token).
I am working on an Identity management application, using which my goal is to manage users on Box application.
I was going through Box documentation, and there are two ways for authentication
OAuth 2.0, which has redirection URI as required parameter. And due to which I cannot make use of it, since I will not be able to enter username and password and Authorize dynamically using my Java code.
Reference: https://box-content.readme.io/reference#oauth-2
JWT authentication, this I can use in my code and successfully get Access token. But problem here is, this access token can only be used to manage App Users (who will not have login to Box website).
Reference: https://box-content.readme.io/docs/box-developer-edition
So, is there any other authentication mechanism which I can use for getting Access token for managing Box users?
Regards,
Sandeep
The current best option is #1 with a process like this:
Create a Box application with the 'Manage an Enterprise' scope enabled.
Use a web-based access token generator (such as this or this) to get an initial access/refresh token pair. Save these somewhere safe (flat file, DB).
Code your application to initialize itself with the access/refresh token pair from its saved location.
When the access/refresh token pair is refreshed, write them out to the save location.
If your application runs across multiple nodes/processes this approach will require some (painful) coordination between them. I believe Box is working on some improvements in this area, so you may not have to live with this for long.
When creating Google Drive applications there are a number of permission "scopes" that can be specified to indicate to the users what permissions are required to run that application.
One of these permissions:
Perform these operations when I'm not using the application
Causes a lot of concern amongst our users. We could not find any definitive explanation of what causes this permission to be listed.
The only possibility we could think of is that using server-side flow for the OAuth2 means that the server might be still syncronising after the browser has been closed and so this has to be flagged up.
If that's the case, will using JS direct to Drive (no proxy server) mean that this permission will not be requested?
This is due to the OAuth2 flavour you chose.
You probably have taken the web server flow flavour, which build a grant URL with the parameter access_type = offline.
This allows you to obtain a refresh token, so you can access your user's files after he has used your app.
You can replace this access_type paramater to access_type=online but you wont get a refresh token. You will be able to acces your users'files only for one hour. After that, you will have to request a new access token to access his files.
I encourage you to read this page where each of the flow are explained.
The official specifications are a good source of information too.