Cloud and Mobile

Deploying Forge ASP.NET samples to Appharbor

By Augusto Goncalves (@augustomaia)

Appharbor: Where .NET apps grow and prosper.  That's their slogan, but I like to think them as a "Heroku for ASP.NET". And they are that easy and have a free tier!

This post shows some basic steps on how to deploy a Github code (one of our samples, for instance), but can also be directly connected to another git. The very first step is to create an account. When properly registered, go to "Your applications" on the top menu, then "Create new application".

Next, on getting started, select Github deploy. The next page will show a list of all your repositories. You should select a .NET sample, if you don't have one, fork one of our ASP.NET samples.

Finally, we need to setup the Forge Client ID & Secret (assuming you already have a Forge Developer account with an app created). Go to "Configuration variables" section, then click on "New configuration variable" and add both FORGE_CLIENT_ID and FORGE_CLIENT_SECRET values. The image below show how it should look like when both variables are created.

Many of our samples will handle with upload of files, which needs to be uploaded to the app server (in this case, Appharbor) before the app can upload again to Autodesk servers. For that, go to "Settings" section and "Enable File System Write Access". Best practice is to upload files to /App_Data folder. Note: an app should not allow end-user to upload directly to Autodesk as this requires an access token with write capabilities, and if the end-user have such a token, this is a security breach. 

As a result, under your Github account settings, you should see Appharbor as an "Authorized application".

That's it. Now when you commit changes to the repository the Appharbor app will deploy and rebuild.

Debug ASP.NET in incognito mode and avoid cache issues

By Augusto Goncalves (@augustomaia)

Cache is a common source of problems during web development. It's not unusual to solve some mysterious problems by cleaning the browser history (or just the pages stored locally). So why not do our localhost debug in incognito/private mode?

To make it the default option on Visual Studio is quite simple: on the "Run" toolbar button, click on the dropdown arrow, then select "Browse With..."

Next, on select your browser. For Chrome add the --incognito argument, or -private-window for Firefox or -private for Edge. Add a "Friendly name" such as "Chrome Incognito" and click "Set as Default" to make it even easier. 

That's it. Now when you close the browser and restart everything is cleaned and you should avoid cache problems during development.

Once your app is published, if you use a HTTPS, it also avoids cache as there is no local copy of files.

Application buckets & Translation in .NET C#

By Augusto Goncalves

Yet another project that uses Autodesk Forge implemented in .NET C#: this time using application buckets on your webapp. 

This solution consists in 3 projects: a class library that wraps some OSS and Model Derivative APIs, plus Authentication; a ASP.NET project that implement WebAPI endpoints with a pure HTML5 & JavaScript UI (no .aspx pages); and finally a Testing project. 

Most libraries have a raw implementation of endpoints, so this sample tries to organize them in a meaningful way: first instantiate a app buckets, from where you can either get a list of buckets or create new ones, then using this bucket object you can upload and translate files. As everything is strongly typed (i.e. no random strings), this approach helps avoid problems passing wrong types.

Please note this is not our official library, but yet an experiment that still under development, so feedback is very welcome! 

Below is a sample piece of code that demonstrate the idea:

// authenticate
OAuth.OAuth oauth = await OAuth2LeggedToken.AuthenticateAsync("Your client ID", "Your client secret",
new Scope[] { Scope.BucketRead, Scope.BucketCreate, Scope.DataRead, Scope.DataCreate, Scope.DataWrite });

// create bucket and get list of buckets in different conditions
AppBuckets app = new AppBuckets(oauth);
IEnumerable<Bucket> buckets = await buckets.GetBucketsAsync(10);

// create a random bucket
string bucketKey = string.Format("test{0}", DateTime.Now.ToString("yyyyMMddHHmmss"));
Bucket bucket = await app.CreateBucketAsync(bucketKey, PolicyKey.Transient);

// upload new object
OSS.Object newObject = await bucket.UploadObjectAsync(testFile);
// this URN can be used on the viewer
// but need to translate first...
string newObjectURN = newObject.ObjectId.Base64Encode();

// the list after should have 1 object...
IEnumerable<OSS.Object> objectsAfter = await bucket.GetObjectsAsync(int.MaxValue);
foreach (OSS.Object obj in objectsAfter)
{
    string urn = obj.ObjectId;
}

// translate
HttpStatusCode res = await newObject.Translate(new SVFOutput[] { SVFOutput.Views3d, SVFOutput.Views2d });
// now this newObject is ready for Viewer

C# desktop with Data Management API

By Augusto Goncalves (@augustomaia)

This is a follow up from this previous post, which demonstrates a basic approach for desktop app with 3-legged OAuth. One of the biggest challenge is to ensure your client ID & secret are protected. 

For that, this sample has 3 projects:

1. Forge: a class library (.DLL) that wraps some endpoints for OAuth, Data Management API and OSS.
2. ServerOAuth: this is the ASP.NET server that stores the client ID & secret and implements the redirects and callback for 3-legged OAuth.
3. A360Sync: a WinForm (.EXE) desktop app that monitors a local folder and upload files to the respective A360 account.

Enough talking, let's see this sample in action:

The A360Sync project will call the ServerOAuth project to get the Authorize endpoint URL and redirect the end-user to the sign-in page. As the client ID is passed on the URL, it's not really hidden (e.g. a proxy server will see this URL with the client ID), but the desktop client don't expose it. As soon as the end-user types his/her password, it will callback the ServerOAuth, which calls GetToken endpoint with the client secret (which should not be shared under any circumstance). Now the ServerOAuth has the access token, so it redirects to a fake url that should trigger an error on the A360Sync desktop app webbrowser control and bingo: it can store the access token. As this handles only the user data, it's ok that the desktop app can see the access token (its access is limited to his/her data and there is no reason to hack his own data).

One concern: non-repudiation. As the access token is a permission to our app access the end-user data, if the same end-user uses this access token to modify its data, on the records, the data was performed by the application (as the 3-legged OAuth is a permission between Autodesk, developer/app & the end-user).

The source code is available on Github, but it should not be used on production just yet (still a work in progress), but I would love some feedback and will be improving it over the next few week. 

 

New training on Autodesk Forge APIs: Six webinars now available for viewing

By Virupaksha Aithal

Whether you’re just starting out with Autodesk Forge or whether you want to learn more about a particular API, head on over to the Forge Playlist on You Tube where you’ll find a series of new webinars at the top of the list.  The training sessions not only explain and show what can be done with the Forge cloud services to connect design, engineering, visualization, collaboration, production and operation workflows, but they take you through the powerful cloud-based building blocks.  Pick and choose which API session you want to watch, or work your way through the series. 

Here’s the full list:

Introduction to Autodesk Forge and the Autodesk App Store

A brief Introduction to the Forge platform and the Autodesk App Store and the business opportunities they enable for developers/companies.

Introduction to OAuth and Data Management API

OAuth is the open standard used across the Forge Platform for token-based authentication and authorization. Learn more

The Data Management API provides a unified and consistent way to access data across A360, Fusion 360, and the Object Storage Service. Learn more 

Introduction to Model Derivative API

The Model Derivative API enables users to represent and share their designs in different formats, as well as to extract valuable metadata. (Its translation functionality was previously bundled as part of the “View and Data API”.) Learn more

Introduction to Viewer API

Viewer (formerly part of the “View and Data API”) is a WebGL-based, JavaScript library for 3D and 2D model rendering. 3D and 2D model data may come from a wide array of applications, such as AutoCAD, Fusion 360, Revit, and many more.  Learn more

Introduction to Design Automation API

Design Automation API, formerly known as the “AutoCAD I/O API”, provides the ability to run scripts on your design files, leveraging the scale of the Forge Platform to automate repetitive tasks.  Learn more

Introduction to BIM360

BIM 360 API allows developers to develop apps that integrate with the Autodesk BIM 360 platform to extend its capabilities in the construction ecosystem. Learn more

 

Introduction to Fusion 360 Client API

Introduction Autodesk® Fusion 360™, which is one of the first Cloud based mechanical design tools. It is an integrated CAD, CAM, and CAE tool for product development, built for the new ways products are designed and made.  Learn more.

 

If you have any questions, just drop us a line at [email protected]

 

3-legged OAuth on desktop apps (C# & WinForm)

By Augusto Goncalves (@augustomaia)

If you don't know OAuth or the differences between 2-legged or 3-legged authentication on Forge, please review this webinar.

It's quite straightforward to implement OAuth on a web app: as everything is on the browser, including the redirect callback, it's almost natural. What about a desktop application? In this case is not quite direct to handle callbacks or implement micro servers to handle it.

This code is almost an hack, but works for our purposes. Note this implementation is not safe, meaning your developer ID and secret can be easily hacked/read by almost any end-user. The safest way still to perform authorization on server-side. 

Let's use the System.Windows.Forms.WebBrowser, which works fine, but it doesn't handle error in the way we want for this sample. At the bottom of this post you'll find the full WebBrowser2 implementation copied from here.

Now on your app, create a form (assuming a WinForm application). Add a WebBrowser2 control, say wb. Prepare the Authorize URL (using your client ID, redirect URL and Scope) and navigate to this page. The end-user will be redirected to the Autodesk login page. When done, it will redirect to your callback URL, which is not possible or doesn't exist (at this sample, fake.com). This will throw a 404 error that we can capture. Voilà! Finally capture the code parameter of the query string and call the gettoken endpoint (e.g. using RestSharp) 

[PermissionSetAttribute(SecurityAction.Demand, Name = "FullTrust")]
public partial class oAuthForm : Form
{
  private const string FORGE_CLIENT_ID = "XxXxXxXxXx";
  private const string FORGE_CLIENT_SECRET = "XxXxXxXx";
  private const string FORGE_CALLBACK_URL = "http://fake.com/api/forge/callback/oauth";
  private const string FORGE_BASE_URL = "https://developer.api.autodesk.com";
  private const string FORGE_SCOPE = "data:read data:write data:create data:search bucket:create bucket:read bucket:update bucket:delete"; // assuming a full scope

  private WebBrowser2 wb = new WebBrowser2();

  public oAuthForm()
  {
    InitializeComponent();

    wb.Dock = DockStyle.Fill;
    wb.NavigateError += new WebBrowserNavigateErrorEventHandler(wb_NavigateError);
    Controls.Add(wb);

    // this is a basic code sample, quick & dirty way to get the Authentication string
    string authorizeURL = BASE_URL + string.Format(
        "/authentication/v1/authorize?response_type=code&client_id={0}&redirect_uri={1}&scope={2}", 
        FORGE_CLIENT_ID, FORGE_CALLBACK_URL, System.Net.WebUtility.UrlEncode(FORGE_SCOPE));
        
    // now let's open the Authorize page.
    wb.Navigate(authorizeUrl);
  }

  private void wb_NavigateError(
      object sender, WebBrowserNavigateErrorEventArgs e)
  {
    // This will track errors: we want to track the 404 when the login
    // page redirects to our callback URL, let's check if is the error
    // we're tracking.
    Uri callbackURL = new Uri(e.Url);
    if (e.Url.IndexOf(FORGE_CALLBACK_URL) == -1)
    {
      MessageBox.Show("Sorry, the authorization failed", "Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
      return;
    }
       
    // extract the code
    var query = HttpUtility.ParseQueryString(callbackURL.Query);
    string code = query["code"];
    
    // now we have the code, let's make a Http call to 
    // /authentication/v1/gettoken 
    // and get the access_token...
    
    // you can use RestSharp for it, but I'll stop the sample here

    // you may want to close this form..
    this.Close();
  }
} 

Custom implementation of WebBrowser, let's call it WebBrowser2 (original post). Due our HTML/JavaScript implementation on the login page, some features are not natively supported by the WebBrowser (which, by default, have some features disables). To improve it, we need a set of registry keys (user level), which are well described at this stackoverflow answer. 

 

Viewer on Mobile using WebView [Xamarin]

By Augusto Goncalves  (@augustomaia)

Here is a recurrent question: can I use Forge Viewer on my mobile app? 

And the direct answer is: Yes you can, use a WebView!

What about a sample? Here you have it! For this really quick demo I'm using Xamarin cross-platform approach. It's actually quite nice: write in C#, compile and deploy on iOS, Android and Windows phones.

 

Next I'll prepare a more complete sample (with other Forge APIs), but for now just would like to share this piece first. 

You'll need this for setting up iOS permissions:

<key>NSAppTransportSecurity</key>
    <dict>
        <key>NSAllowsArbitraryLoads </key>
        <true/>
    </dict>

 

Google Drive & Model Derivative - Viewer

By Augusto Goncalves (@augustomaia)

This is actually based on previous sample, Forge Box Viewer, posted a couple weeks ago. Now this new version implements the integration with Google Drive. But there are some interesting differences: Drive can host and edit files, therefore some documents don't have extension (such as .ppt or .doc), but in any case the Model Derivative cannot translate them.

Try the Forge Google Drive Viewer and check the source code here.

You'll need a Google API Key, check their Developer API Console. As this sample access files and user profile (see scope here), make sure to active Google Drive & Google People APIs. Google endpoint will return an error if the scopes are not properly set.

Introduction to oAuth and Data Management API

By Virupaksha Aithal

Here is the recording of the “Introduction to oAuth and Data Management API” presented on 20th September 2016

 

Blogs referred in the webinar

Forge Tutorials, which should I use?
http://adndevblog.typepad.com/cloud_and_mobile/2016/09/forge-tutorials-which-should-i-use.html

How to: debug NodeJS code (with Cloud9)
http://adndevblog.typepad.com/cloud_and_mobile/2016/09/how-to-debug-nodejs-code-with-cloud9.html

Videos

Deploy to Heroku
https://www.youtube.com/watch?v=Oqa9O20Gj0c

Sample 1

Live http://forgedmboxintegration.herokuapp.com

Source https://github.com/Developer-Autodesk/data.management-nodejs-integration.box

Sample 2

Live http://forgeboxviewer.herokuapp.com

Source https://github.com/Developer-Autodesk/model.derivative-nodejs-box.viewer 

How to: debug NodeJS code (with Cloud9)

By Augusto Goncalves (@augustomaia)

It's not unusual to see NodeJS developers writing tons of console.log statements to "debug" code. This is really not productive and just waste of time & effort. 

This quick video tutorial explains how to find a sample code you like on Forge@Github, fork it to your account and clone for editing on Cloud 9. Then how to setup Forge client id, secret and callback URL as environment variables. Last, how to setup a breakpoint for debug. Quick & easy!

And did I mention Cloud 9 is free for public projects/workspaces?!