Description
Key Learnings
- Discover .NET technologies available for web development
- Learn about integration with other web-services providers
- Learn about the steps necessary to use Forge with .NET
- Gain tips and tricks for existing desktop .NET developers
Speaker
- Augusto GoncalvesAugusto Goncalves has been an API evangelist at Autodesk, Inc., since 2008. He works with all sorts of technologies, from classic desktop to modern mobile and web platforms, including .NET for AutoCAD software and Revit software, and JavaScript application programming interface for NodeJS.
AUGUSTO GONCALVES: So this class is moving to Forge and the cloud with your existing dot NET experience. Actually, this class is about what you need to learn and to pay attention when doing cloud development with dot NET technologies. I'm not using any other thing in this class.
There are so many options out there. You can choose a lot of extra tools. But what about your dot NET expertise? How can you do that?
So my name Augusto Goncalves. I'm at Autodesk for like nine years now. And I'm doing ADM support, desktop support, for most of those years. I have a few seats here if you want. And I did dot NET support for desktop development with partners like ourselves for all those years. And recently I started doing Forge support. And, well, I'm doing support with dot NET, nodes, and some other technologies as well.
And it's quite interesting, because most of you that's been with Autodesk for a long time, you know dot NET. We evangelize dot NET for a long time. So now how can we keep using the same technology? So that's the main idea.
So that's class summary. That is on the registration, right? So, yeah, for over a decade we've been teaching dot NET. And you know that. You know how to use dot NET technology. But how can we use that with Forge, and with cloud technologies?
And the goal of this class is basically show some topics that you have to pay attention, and then show some samples on how on a few scenarios that you may want to do.
I like dot NET. It's a very cool technology, because we can use on desktop. We can use on cloud. We can use dot NET on mobile. You know that? You can use dot NET to develop iOS and Android applications. Do you know that?
Take a take a look at Xamarin. Xamarin is a Microsoft acquired Xamarin. But it's basically an IDE that you can use to develop cross applications that works on iOS and Android. I mean, it's not like a native application on mobile. But it's very good, because you can do C# for both platforms. I still have three seats on the front, if you want, and a few others. Other way.
So, well, the objectives of this class is to discover some technologies, learn about web service providers, the next necessary steps to use Forge with dot NET, and some tips and tricks on how to do this, right? So I will try to save half of my time showing samples and how to make those samples work.
So, well, migration roadmap. So let's say you have a desktop application, and you want to migrate this application to work with cloud. It's not like getting your desktop application and moving that to a browser application. It's not that. How can you expand your application? So that's the goal.
So well that's basically what you may have on your environment. We, Autodesk, we have desktop applications like these. We have AutoCAD, Revit, Inventor, many other applications that are desktop applications. You may have some desktop application here as well.
We do have also some hybrid applications, like Fusion. Fusion is a hybrid application. It's not a cloud application, like a full cloud application, because a lot of tasks do happen on the desktop, and some other tasks on the cloud. So Fusion is a hybrid.
And on the other side, we do have BIM 360 Docs Team, Fusion Team. All of those products here, they are like cloud-only applications, because everything is run on the cloud.
So let's see your applications right here. You can move your intellectual property right to the cloud, or you can just extend your application to be a hybrid application, and take advantage of Forge and many other APIs. So, well, yeah, that may be one of the first goals.
We are doing some of that migration to our AutoCAD in Revit. If you go to Revit today, we do have Revit collaboration that helps you do some collaboration with the cloud. So it's a kind of hybrid application. So we are doing that as well. So you can do that, too. So that's the first step.
And then if that's the case, if something that makes sense for your application, you can do a full web application. So does it make sense to have a full web application on your scenario? Sometimes a hybrid will be more than what you need. But you can consider doing those steps. So that's something that you can take a mindset, and think about what you want to do.
So I imagine that most of you have desktop applications. So the first step will be to make this a hybrid application. So you still have a desktop, but we'll take advantage of part of the cloud features. So how can we make cloud-connected hybrid applications?
Well, we need to learn some stuff, some tech knowledge, before we go that direction. So here are a few things that I would strongly recommend you to learn, and start getting comfortable with.
So the first one is security. Why security is the first one and the most important on this topic? Because when you have a desktop application, most of the information is residing on the desktop. You don't need to transfer that information from your machine to a different machine. Your information is not somewhere else, and you are not keeping the customer information on your premises.
So if the user is using your desktop application, and someone hacks inside his computer, well, it's his computer. There's nothing you can do, actually. So your application needs to be safe, but your cloud application or your hybrid application needs to be much more safer than that. You need to pay attention to the security.
And usually the first step to make security a key point on your application is to design your application to be secure. You start the security by the architecture of your application, not from your code, not from how you encrypt data, but on the overall architecture of your application. So security is the first most important thing that you have to learn, that you have to pay attention to.
Then we need some technologies. So REST is a protocol that we use to make calls between servers. So REST is like you make an HTTP request from one computer to another from your computer to a cloud. And then you get a response back. Usually that response comes in a format of JSON, which is JavaScript Object Notation. So this is basically how to condensate the information into a data structure that is easier to transfer data between providers.
Why JSON and REST, I'm pointing those two here, because they are the most used standards and object notations on the cloud. You can use XML. You can use some web services, XML notation, some other notations. But those are the most common. If you go to a Autodesk Forge, or any other cloud provider, they are all using REST and JSON.
So is REST and JSON something that is new for any of you? Are you aware of that? So if that's new, go to Google and say, how can I learn, or getting started with JSON, getting started with REST. So that's the first thing.
To use REST and JSON, you don't really need to go on the raw implementation of that on dot NET. We do have packages for those. So the Restsharp package for REST, and the Newtonsoft.Json package for JSON are the best packages for dot NET.
Do not go write your own REST codes. Use the SD case for each of those languages. If you need to make a REST code, use the Restsharp. If you need to translate JSON, use Newtonsoft.Json, or any other library. But those are the best libraries for those things.
And of course, Autodesk Forge, that's the dot NET library for Forge. So if you want to make calls to Autodesk, that's the library we use.
When I say libraries, I'm always saying that those libraries are available as part of the NuGet library. So you can go there and get all those packages. Do you know NuGet? Everyone knows it? So we're good.
Next thing, security. As I said, security is the most important thing. Assembly security, DLLs and EXEs are not secure. Do not think your application, Autodesk application, is secure.
If your application is a dot NET application, you can just disassemble that application. You can just decompile and see the code. And everything you put inside your DLL is not secure. You have to keep that in mind. Because of that, you need to make sure no confidential information is stored on your desktop application, DLL or EXE.
If I have search after our application, use some tool like ConfuserEx tool. That will make a lot of mess on your code. It makes it harder for someone to hack in. It's not impossible. It's just harder. So, yeah, that kind of tool is very interesting.
As I said, designed for security. And keep sensitive information on the server. Never keep information-- sensitive information-- on the desktop client. If the information is something that if I access some information I will be able to do something else, do not keep that on the desktop. The desktop should only contain the information needed for that operation and for that user. So that's very, very important.
And if you have any sensitive information, that information must be encrypted during transfer and in storage. So let's say your cloud is sending information to your desktop location. Encrypt that information. If the information is sitting on the desktop, or sitting on the cloud, encrypt that information. Because if someone can hack in and get the information, it will be like random data, and you have time to overwrite the data before the next use. So always encrypt the data.
So is that new? Is that obvious? Everyone is looking like--
AUDIENCE: [INAUDIBLE] have a little thing programmed inside the file that encrypts the data as it sends, or?
AUGUSTO GONCALVES: Well, as I said, design for architecture means right here. Design for security, I mean. It's about keeping your data on whatever is more important.
So let's say you have user data. Keep that on the server, on the cloud. And just send the amount of information in each depth client when that information is needed. And if during the transfer, encrypt that information. Because then the desktop can see it. No one in the middle can see the same information, for instance. And if you keep that information on a database, on the server side, for instance, encrypt that information. If anyone can hack into your cloud, they'll just see encrypted information.
The same thing, if you restore information on the desktop, encrypt that information with some key that is available on the application. Otherwise, someone else can see it.
So let's say you have your desktop application with some data. If that data is encrypted, other applications, like a virus, will not be able to see what you have inside your application-- the data that you have inside that. So encrypt the data. That's the point. Always encrypt the data.
Moving forward. So a hybrid architecture. We can think about in hybrid architecture like this. So we have a desktop application. We have a cloud module that we are going to develop, and some other cloud providers we are using.
So let's say I have a desktop application that we will request my cloud for Forge information, or some other providers, and then return back that information. Note that my cloud is keeping all the logic, and the desktop is just requesting and receiving the piece of information is needed at that point.
So it is not accessing for it for directly. There is no bridge between my desktop to Forge. So my desktop application doesn't know Forge, or is not accessing Forge directly. So that's a way.
For instance, if I have my desktop application, and it's somehow compromised, that application will not be able to access Forge directly, because everything's passing through my cloud application in the middle. So that's one way of doing that.
As I said, and I repeat, do not keep sensitive information on the desktop. Do not keep information-- that system information-- there. That's very important to keep in mind.
So let me do some hybrid application demonstration. I have two samples here. One of the samples is used in data management, and another sample is using more derivative to access the data.
And as I-- just one back here-- as I said, all of those samples are available at GitHub. And right here you can see the GitHub repo. So if you download this presentation from the DevCon website, the presentation is there, the handout is there. And here is the GitHub code for GitHub link for the code. So you can go here and get the entire source code.
So this first application is using a two-legged scenario. So when you do oauth authentication with Forge, and you do oauth authentication with any other provider, we have mostly two kinds of authentication. We have two-legged and three-legged.
Two-legged authentication means that I have a server-to-server authentication. So my server is connecting to Autodesk server, and doing the authentication. The user is not aware of any Forge connection, or any Forge authentication. So this is a two-legged.
In this sample, I have a desktop application that will connect to my cloud, and then connect to Forge. So my desktop application is uploading a file to Forge, and receiving back a unique ID. This unique ID is a random number. It doesn't make any sense to anyone. It's just a random number.
My cloud module then sends this file to Forge, and posts a translation job. In this case I'm uploading a Revit file, and asking Forge to translate the file.
The desktop application knows the UID, and asks the cloud module is my file ready, passing the UID. The desktop application doesn't know anything about Forge, anything about translation. Just knows the UID, which is a random number.
And the application here checks if everything is ready, and download the metadata. My application then transform that data into a spreadsheet from Excel, and send that back to the desktop file.
So why is that secure? Because the desktop application only knows the server, and only knows a UID of the job. And the job in this UID is unique. And if someone else can access that UID, they can query this information. That's correct.
But remember that all the communications between my cloud and my desktop are secure with SSL. So there is no man in the middle accessing that data. The only risk that I have here is a virus on that desktop application reading all the data.
But, well, there's no way to avoid that. I'm not storing the data, or it's just in memory. So a virus can see that. Well, but there's no real way to avoid the virus on the desktop. So, well, that's as good as it can be.
So let's see this running. And let's hope it will not crash, because there is always the risk of doing live demos.
So this sample is, again, it's on GitHub. And the sample contains three projects that I'm using. Don't crash, don't crash, don't crash. I think it's too big. Let me put like. Can you see on the last row, can you see the text?
I'm not going to run line-by-line on the code. I'm just showing some key points here. So I have the solution with three projects. The first one is just a project that I found on a code project, which is a library of a lot of samples, that is adding a context menu to files. So this is just doing this.
This second thing here, this is a translator. This is a desktop application. So this desktop application will actually upload the file, query the status of the translation, and then download the results.
And here is my cloud module that will actually do all the jobs. If I right-click on the project, on the solution, and check the startup settings, I can see that I'm just starting the server, because the context menu will actually start the desktop application. So let's run this.
I have a few breakpoints that I would show how it works. So this is a demonstration. So I have the cloud and the desktop, everything on the same machine. But I can easily split them up. So I know that, because my desktop application through the app config is saying, OK, connect to local host instead of connecting to somewhere on the cloud. But it's the same deal. Good?
So let's come here. So as I said, the first project is just creating this manual here, extract properties. It's just a code that I found on the web that creates a context menu for Revit files. When I click here, this is where we start the desktop application. And the desktop application will then upload the file, get a GUID, and start the project.
So extract properties. So you see, uploading file. So now my cloud module is receiving the file. So my cloud module has an end point which is API Forge translator upload file. And the cloud module will get the file from the desktop, submit the file to Forge, and start the translation job, and return to the desktop only the UID. So this is the code that is doing this, I'm not going to show line-by-line. Just run through the end.
And you see that after the cloud module gets the file, uploads to Forge, and post a translation job, it will return to the desktop client GUID, which is a random number. So the desktop client knows this information now. And the desktop client will now ask, OK, translating 0%. And after a few seconds we will ask again, is this file ready?
So let me enable this breakpoint. Now the desktop module is asking the cloud module for the status. And we will keep asking a lot of times until it's ready. So let me just move forward. OK, translation 100%, because I did a breakpoint there.
So now the desktop application will ask the cloud module for the cell file. So API get the cell file. Every time I ask for that information I'm passing the unique ID. So that's the only information in the cloud module the desktop module knows is the UID. So now that the cell file is ready the cloud module will send that file to the desktop module. And that will be it.
Don't worry about these. It's just debugging thing. Keep going. Keep going. Now the file is ready. We see. Let me resume here. So this is the file.
As I said, the desktop application, it's only uploads. The file asks for the results, and then download the results. The cloud module is doing the whole processing of the file.
Actually this Excel file is created on the cloud, and downloaded to the desktop, and contains all the properties of all the elements on that Revit file.
And you may say, OK, how do you create an Excel file? Well, actually, I think I'm using a few libraries. No, I am not actually using them. Or am I? Oh, right here. It's not on the desktop. It's on the cloud. Everything's on the cloud in this case.
So I'm using this Excel library to create something. So on my cloud module, I'm using a library to manipulate Excel files, so I get all the properties from Forge, which is like a tree of information hierarchy. I run through the tree, organize the information, create a new spreadsheet, and send to the desktop.
What's important about this sample is that all the sensitive information is not is storing on the desktop. The desktop don't have access to Forge, doesn't know how to read Forge. The Forge client ID in secret is not on the desktop, but safely on the cloud. Questions. Any questions?
AUDIENCE: [INAUDIBLE]
AUGUSTO GONCALVES: In this case here, the only encryption I'm doing is on the transfer of files, because when the file goes from here to here, et cetera, I'm using SSL to do the encryption. So it's a secured connection.
As I'm not storing any information here, I don't need to encrypt it, because I'm not storing the information. And I'm not storing the information here, because I upload the file to Forge, download, process, send the results, and erase everything. So I'm not keeping data. So I don't need to encrypt the data. But that's a good point. I'm not encrypting, because I'm not storing the data.
AUDIENCE: What about HTTP versus [INAUDIBLE]?
AUGUSTO GONCALVES: That's the point. If you have HTTPS connection, the connection is secure during the transfer. If not, the connection is open. Anyone in the middle can see that connection.
AUDIENCE: Right. So some of the issues that we have when writing code is when we're doing the HTTP first and HTTPS is that it seems like every time we're running an HTTP were running into issues. Do you have any tips around that?
AUGUSTO GONCALVES: I have to look at the problems you are having. But I would say do not use HTTP only. Use HTTPS. Because when you do a connection on the cloud, or a connection through the internet, you are actually sending data between servers. So the information goes from your machine to several machines.
So keep the data encrypted. Otherwise, anyone can see it. Do not put sensitive information, for instance, on the URL, because a proxy can see it. Keep the information on the body, which is encrypted, or on the header, that is encrypted. But if you are having problems, it may be something on your maybe with your library.
AUDIENCE: Even [INAUDIBLE] client and stuff, if you involve the client, and you run web client, and it's always hard to set up HTTPS connection. We always run into problems like that.
AUGUSTO GONCALVES: Is that specific to Vote? Then that may be something with Vote, then. I can find you someone with Vote, with that expertise.
AUDIENCE: It's brutal on Vote.
Yeah, it is. It's just-- yeah.
AUGUSTO GONCALVES: But yes, if you're not using HTTPS, then your information can be linked. Anyone can see it. So that's very important.
So my next sample-- oh question.
AUDIENCE: Would you consider using webhooks, creating what is gap webooks versus pulling.
AUGUSTO GONCALVES: Yeah. So he's asking about using webhooks, instead of pulling the data all the time. Yes, I want you to use it. But it's not ready yet. But as soon as it's ready, we will start using. But this sample is not ready. Brian announced webhooks this morning, but it's just for new files created, not for translation jobs yet. But we'll be there soon. And then I will change this sample.
AUDIENCE: [INAUDIBLE]
AUGUSTO GONCALVES: So in this case here, you can host this cloud application on any dot NET compatible application server. You can even use a serverless approach, because this is like a serverless approach. It can use Azure or any other. It doesn't matter. It's a dot NET code, so it can be anywhere that is compatible with dot NET.
In this case here it's quite interesting, because this is a very good candidate for in this application. This is a very good candidate for serverless application. Serverless means that you are not keeping that live all the time, just on demand. And we have that on AWS. We also have that on Azure.
So, serverless. On AWS it's called Lambda. On Azure it's Serverless. And on Google, I don't think Google supports dot NET. But they have a similar thing. But I don't think they support dot NET in that case.
AUDIENCE: Are there transfer benefits to receiving [INAUDIBLE]?
AUGUSTO GONCALVES: Is there any transfer benefits using AWS or Azure? Yes. For instance, we, Autodesk, we host our data on AWS East.
AUDIENCE: So if you're in that same region--
AUGUSTO GONCALVES: If you're on the same region, you are not paying the fees to transfer files. So yes, that's a good benefit. If you're going a lot of transfer of data between you and us, then yes, it's a good benefit.
AUDIENCE: [INAUDIBLE] does in AWS East. So [INAUDIBLE] Australia is in like, geographical hosting that's going to come out in the future?
AUGUSTO GONCALVES: Today we have, Autodesk, we are hosting our data on AWS East, and Europe-- Dublin, I guess. So if you use the same location as we, you're not charged for transferring the data between them. And it's faster.
But it can host anywhere else. It doesn't matter. It's just a matter of pricing of transferring the data. So this is quite important if you have a lot of data being transferred. If you have just like metadata or profits, it really doesn't matter. If you have gigs of file, then it's important to pay attention to that.
AUDIENCE: How does this work for the Vote [INAUDIBLE]?
AUGUSTO GONCALVES: Vote? I have to think about more about that. This is a sample for Forge, not actually for Vote. If you want to use Vote to get a file that is on Vote and upload to Forge and do some jobs, you can use the same approach.
But I have to think more. I'm not really a big expert on Vote, on how it works. But if the file is hosted on your internet, you still need to upload that to Forge, if you want to translate the file, if that's something that you need.
And if you have Vote on premises, you can do your cloud module on your premises as well, or not, or Azure. But it's just a matter of how you move the file here.
AUDIENCE: So one of the benefits, obviously, of the HTTPS is the encryption. But one of the disadvantages is when it doesn't work for some reason, whether that's a [INAUDIBLE] or debugging your platform-- whatever the issue may be, trying to figure out how to package that up and send it to your engineers and say, hey, I think I might have found a bug, but I don't want to send you 2,000 lines of code, and you don't really care about the [INAUDIBLE]. You care about [INAUDIBLE] if you have any suggestions how to strictly recapture the web request. [INAUDIBLE].
AUGUSTO GONCALVES: Well, he's asking, what's the benefit of doing HTTPS when you have to debug problems on your connection? So I don't know what you are doing, but it shouldn't matter, because it's just a connection on the lowest level. So your application, and the application on the other side, will not see this encryption process. It's like a transparent encryption. So if you use HTTP or HTTPS for your code, it shouldn't matter, because it's the same code for both cases. The encryption happens on the connection level, not on your application level.
AUDIENCE: As far as getting support, how should I send [INAUDIBLE]?
AUGUSTO GONCALVES: Well, that's what I'm saying. If you have a request on HTTPS, the requests either should be unencrypted when you see it. The encryption happens on the transfer of data, not when you see it. So you are not actually seeing the encryption of the data.
If you are encrypting the data yourself, you are double encrypting the data. So there's no need to do it. You don't really need to encrypt before transferring, because the HTTP is doing that. And it's doing that through private and public keys.
AUDIENCE: So am I right that you just burn one [INAUDIBLE] Revit during the translation here?
AUGUSTO GONCALVES: Yes. He is asking me if I'm using Cloud credits to do the translation, yes. Because I'm doing the translation with two-legged. And then I, in this case, I just burn it 1.5 Cloud credits to translate the Revit file.
AUDIENCE: Do you have a sample of the viewer, of the Forge viewer?
AUGUSTO GONCALVES: Yeah, that's the next one.
AUDIENCE: OK.
AUGUSTO GONCALVES: The next one is this, the next sample. Let me move here, otherwise I will run off time-- out of time. This next sample is a bit more complex. I'm using three-legged scenario. And again, I have a desktop application. I have a cloud application with my data. And I have Forge on the other side.
The goal of this sample is to log in with my Autodesk account, see my files, and then view the file, keeping all the data secure during the process. So the first thing is my desktop application, we will open a browser, and ask my web application to sign in. My web application will then redirect the user to Forge. The user will type his credentials on Forge. But it's a browser application here. But the user will type his credentials on Forge.
Forge will call back my web application with the codes. My application will then exchange the code for a token. My web application will then restore my access token and refresh token and create a unique ID, and send that unique ID to the user.
Again, the desktop application, we will only know this unique ID. Nothing else. That's a big one. My desktop application will then keep record of that unique ID. Again, encrypted. I will encrypt that information here.
I will then request something for my cloud application, passing the unique ID. My application will connect to my database, and check for that unique ID, and get the access token. You, with the access token, I'm going to call Forge, get the data that I want. I will get the data, transform that data somehow. I don't want to send all the data to the user-- just the data I want to send. And finally, send the data back to the user. And the user here will be able to see the application.
What's important here, my cloud module knows the access token, the IDs and secrets. My desktop application only knows the unique ID that was assigned to it. And everything is passing through my server in a way that the desktop application will never see Forge, or will never see Forge IDs or Forge secrets. So that's a big one.
So let's see it running. Again, let's hope it will not crash. Let me close these. Oops. Yes. As I said, the source code is on GitHub right here. So that's the one.
So I will quickly run this sample without breakpoints. So I will disable all breakpoints and start.
Before I do that, let me do one more thing. In this case, I have two modules. So I have the cloud module, and I have the desktop module. If I look at the properties, I will see that when I start debugging, I am starting both projects. So let's start debugging. So that way we start the desktop application and the cloud module.
The desktop application is connecting to the cloud module. So let me go to desktop application, app config. You see, the cloud module is hosting a local host, but can be Azure, or AWS, any address that I have.
So I open my desktop application. It's going to redirect me to Forge. And I will type in my password-- my ID and password.
So the screen is blinking like that because I'm using parallels. And parallels is breaking my graphic cards. So there is a way to fix that. But I'm afraid of doing that and crashing it again. But you see, it's changing this for some reason. I don't know why. It should be like 125. You see, it's, yeah. Should be better now-- hopefully.
Now it's better. It's crashing the application, because it's changing after I launch the application. Anyway.
So I see all my hubs. I can select the file. And I can then see the file here. And, well, that's my file.
I'm not using the Internet Explorer. I'm using CefSharp, which is a better library for this one. So again I can see my project here.
One interesting point that I mentioned is that all the data is kept on the cloud. So let me open this one here. So whenever the user logs in on my application, I'm keeping the UID that I'm sending to the user-- I think that may be too small. And the access token, refresh token, and the expiration date. So let me erase this, and run the code again now with breakpoints enabled so I can show you a few steps. So let me stop and start again.
So when I start the application, the first thing that will happen is it will open the application-- the desktop application. We will ask the cloud module to redirect to the sign-in page. So let me zoom in here. So this is the cloud module redirecting the user. The client ID in secret is actually on the cloud module, and is redirecting to my client. So I can type in my password again.
So now the Forge is calling back my cloud module with the code. My cloud module receives the code, exchange that code for a access token, and keep that access token on a database, and the database creates a UID for that entry, and I send that UID back to the client.
So the session ID is this number here, is encrypted. So the actually session ID unencrypted is like this-- 5a09f4. So that's the unencrypted. I encrypt that information and send that to the client. Because that information will be stored on the client. So I need to encrypt that.
Oh, you may encrypt that information on the client. Yes, but then the client knows how to unencrypt it. So if I encrypt the information on the server, the client doesn't know how to unencrypt that information. So that's something.
And if I go back to my database, my database now have the information for that user. And that's the user-- that's the ID that the client knows. And that's all the other informations.
So keep running. Now the desktop application will keep that information. The desktop application will now request some information for the cloud module. And that's the desktop application request the information to the cloud module.
The cloud module will receive the request the profile, will receive the session ID from the user, which is passed as a header. And then we'll go to the database and get the access token for that information. So note that the desktop only knows the UID, and the cloud module exchange that UID for an access token, and get information. And then I can get the profile, and get the hubs, and get all the information that I want, and show here.
The last step that I want to show you is that when you have the viewer on your application, you need to pass a token for that viewer. You need a token for the viewer to see the module. Here I'm proxying all the requests for the viewer through this proxy. So I have a proxy that will handle all requests for viewer.
So even the viewer is not unencrypted. Everything passes through my server. I'm using proxy for that. So I'm creating this proxy header. And every time the user makes a request for any piece of information on the viewer, I'm going to my database, getting the information, and calling Forge with that information.
That's a big sample, but shows how you can fully encrypt and fully control the information that is going to the client right here. Yes.
AUDIENCE: The records that are stored in the [INAUDIBLE] just going to delete it?
AUGUSTO GONCALVES: This record here? I'm not deleting that for now on this sample. You need to do that to be compliance with some other cloud policies. That's correct.
I try to keep this simpler as possible. So I'm not doing a lot of error checking, or that kind of policy compliance, for instance. But yes, you need to have had something to erase that information after a while. That's true.
If you look at the Autodesk policy compliance, I am allowed to keep that information, because that information here is not user specific. Because I'm not keeping, in this case, the user ID. So if I keep the user ID, then I have a problem. But that information is not user sensitive. But you should have that on your policy, your privacy policy.
And last thing that I want to show you that is very important on this sample is that I'm using here on the package this guy, CefSharp common and CefSharp WinForms. Those are libraries for using a browser on your application. If you don't use that, if use the built-in version, the built-in uses Internet Explorer, which is crap.
The CefSharp, it's an important one. So CefSharp is a library for dot NET that gets the Chrome engine, and put that inside the library. So you can use that. You can use Chrome on your application using this library.
As you can see here, I believe they are on version on-- which version they are? Let me check. They keep updating all the time. So they're using Chrome, I think it's 57. 57 right here. And the Chrome, it's using 61. So it's four versions behind. That's very good. So we have four versions behind the official Google engine. So it's much better.
And there is something that is really, really important that is not available on the built-in version. There is the ability to clear session right here-- delete cookies. So delete cookies is not available on the built-in dot NET browser, but on this one it's available.
This is very important, because if the user goes to your application and sign in, and they check the keep signed in box, that cookie on your application will go to the Internet Explorer cookie database, and will be shared outside your application. So it's crazy. So delete cookies here is much better. So yeah. Use this one. You can use others, but this one is a good example.
So these are desktop applications that connects to the cloud. And question.
AUDIENCE: Quick question. Sorry, but, can you just explain in your first example, two-legged example, where is the user name and password passed there [INAUDIBLE] within your server [INAUDIBLE].
AUGUSTO GONCALVES: What's passed? Can you repeat that?
AUDIENCE: In the first example. which is two-legged, do you ever look from your server in Forge using your user name and password? Where does that happen? Or does it happen at all?
AUGUSTO GONCALVES: No, it doesn't happen, actually. So in this case here, this is a three-legged. So the user is logging in on Forge. And all the actions my cloud module is performing, I'm performing those actions using the user credentials.
AUDIENCE: OK. Because that's the key. So basically [INAUDIBLE].
AUGUSTO GONCALVES: Yes. If I perform actions here, some actions will be billed to the user as his account. But if I request additional translations, then I will be billed to the translations.
So let's say I'm just giving files on this case. So I'm using user credit for it. If I ask for addition translation-- let's say from Revit to IFC-- then I will burn my developer credits.
On the other sample-- let's go back-- on the other sample the user here will not see anything from Autodesk. There is no indication that I'm using Forge at all. So in this case, I'm authenticating using my developer credentials, not the user credentials.
AUDIENCE: OK. [INAUDIBLE].
AUGUSTO GONCALVES: Yes. Yes. On this case, I'm burning only developer credits. On the three-legged case I'm using user credits. But I can also use developer credits if I request additional translations.
AUDIENCE: OK. And in this case, you can also get the user private data store, can you?
AUGUSTO GONCALVES: If I can get user private data on this case, yes, because I'm using three-legged. So I have access token to his data. If the user authorizes me to access his data, then I can see it.
AUDIENCE: Then in first example you can't do that.
AUGUSTO GONCALVES: Because there is no user. There is no Autodesk user on the first sample.
AUDIENCE: OK. So [INAUDIBLE]. Thank you.
AUGUSTO GONCALVES: So the first sample is purely my application in Forge. On this sample is user, my application, and Forge authenticating.
So those are two samples, one sample using two-legged, another sample using three-legged on a hybrid environment. So let me run here, so I can show you desk cloud application.
So the first step is to get a desktop application as a hybrid. The next step, if applicable, is to get your hybrid application, and make a pure cloud application, if that's the case.
So I have two samples that I want to show you. One is a two-legged sample, and one is a three-legged sample. Again, source code and live versions. As those samples are web applications, you can see them on the AppHarbor.
AppHarbor is like similar to Azure and similar to Heroku, but it's focused on dot NET applications. It's quite good to use. It's free. So it's OK. It connects very easily to GitHub. So it's interesting to use.
So let me come back here, and let me close these. And then here. More the derivative. This is the two-legged sample. On a two-legged sample, I just have a huge list of buckets. I will upload the file to that bucket and ask for a translation. So everything here was implemented with CefSharp on the server side. The client side needs to be HTTP-- sorry HTML in JavaScript.
So I have a huge list of buckets. I would just upload the file to a bucket and select the file. So in this case, I'm sending the file from my desktop computer through the browser to my cloud. My cloud then gets the file and sends to Forge. And that when I click again, and I say, OK, translate. And then my web application here will send the request through my cloud module. My cloud module will post a request to Forge translated file.
The only difference between this sample and the other sample is that in this case everything is run on the browser. There is no desktop application. But it's the same idea. And as the data is hosted on the browser, and I don't really have to worry that much about security, because everything is HTTPS. So it's encrypted. So this is my two-legged sample.
I'm not going to go deep on the code, because basically the same idea. So I have just one module, which is a cloud module that receive requests from the cloud from a desktop-- sorry-- from the browser application, post the request back to Forge.
The other sample is using again dot NET on the server side, but is using JavaScript and HTML on the client side on the browser. That's required. I will type in my password. My browser application will request my cloud module for the list of hubs. I will show the list of hubs here, and then show the list of projects, show the rest of the data. And then I can view a file.
I like to point out those samples, because those samples, I wrote those samples in dot NET on the server side. So the browser application requests to see this module, all the requests passed through my server through a proxy. My cloud module request, all the module information, and send back to the browser.
So this is a very classic one, is our web application that is just with server-side implemented in dot NET. So that's the next step if you want to make up your application fully cloud enabled.
Questions here? This is basic sample. It's basically repeating the other two samples.
AUDIENCE: For the two-legged version, where they upload their file to the bucket, is that in your [INAUDIBLE] just saving that file? And then, when they request it to translate, then your cloud service translate it, sends it to Forge?
AUGUSTO GONCALVES: Yes. So he's asking if who is keeping the file, and who is the requesting the translation. So on this sample, when I upload the file from my browser to my cloud module, I upload the file from my browser to my cloud. My cloud uploads to Forge, and put the file on Forge, and erase from a cloud module.
I don't want to keep files. I don't want to keep data that I don't need. It's too much responsibility. So if you keep the data, make sure you need that data.
So it uploads. When I translate, I say, OK, Forge, translate this file. I'm not keeping anything on my cloud module on this specific sample. But you can. I'm not keeping in this case.
The first thing about security is that you don't keep information that you don't need to. If you need that information, keep, encrypt, keep it secure. If you don't need it, don't keep it.
So those are the two samples in dot NET that are using two- and three-legged as well. So, well, what about what customers want with our application? What's the ultimate goal that we want?
We do have desktop applications. We can make those desktop applications hybrid. We can have browser applications. And we can also have mobile applications. An application can be a browser application. Again, here, a browser or a desktop application.
What the customer is doing is a way to access that information using any kind of interface. So that's what they're really looking forward. So they want to request and receive information from our cloud module. It can be a dot NET, in our case. It can be a node, Java, whatever. It can be something here. This class was about dot NET.
Most of the time I will need some database to keep that information. It's not possible to keep everything just stateless. At some point, I would need some database to keep record of whatever I'm doing. On my sample, I used Mongo database, which is non-SQL database. But you can also use SQL database, or any kind of storage.
And your cloud module then connect to Forge, and connect to any other cloud providers that you may need. On the sample that Brian showed this morning, using [INAUDIBLE] to send SMS for instance, that's another provider here. So you're connecting different providers to show the information that you want.
But what the customer really wants is there at the center. If you're keeping different clients accessing different data, that's the complication. We really want to keep the data at the center, so whenever they are trying to call the data, they can see the same data. So that's the thing to keep in mind. Always keep the data at the center, at the center of your strategy, or at the center of your application, the same data accessible from any kind of device. That's the important message.
And to finish, what's next. We are just five minutes to finish.
There are many ways to deploy your application. I use AppHarbor because it's easier to connect from GitHub. You can also use Azure, because it's very integrated with Visual Studio. But also AWS. There are many options on the AWS, l like Elastic Beanstalk, and Serverless, et cetera. And many other dot NET hosts.
There is no difference using Azure or Elastic AWS. AppHarbor is for testing. Don't use that in production. And AWS is better, because we do also host on AWS, and they have a very good support, and the prices are very equivalent in this case. But the benefit of AWS is the better connection with Forge, because we are there as well.
And finally, you can get more information on Developer. You can get our blogs. And they have a lot of samples on GitHub.
And when migrating your application to the cloud, well, there is always the ugly truth about that. You have a huge monster that you want to migrate. And that's basically what you have-- most of us have right now-- legacy software. Someone have all those guys trying to migrate. It's like a big monster. And someone just trying to create a newer cloud.
Born on the cloud application is like a tiny bird, like this. It's a complex job, because we have a lot of intellectual property come in from our years of learning with using dot NET, or any other on the desktop. And now we want to migrate. It's not an easy job. But keeping security as the first thing, you are going to do it.
And don't be shy. Ask for help. We have our channels. We have support. We have some samples on how to do it. I did all those samples to address all the scenarios.
Use well-tested packages. Don't create your code. Don't create basic stuff. If you want to do a connection that is like a basic computer science thing, look for a package. Most of the time, there is a package to do what you need.
And keep the security in mind. And, well, keep in mind that the cloud brings connectivity benefits and better experience. And that's what we are looking for. But it's a tough job.
Here's my information. If you want to send me a direct message, here's my email address and my Twitter.
You can also post questions for us at the developer.autodesk.com. And then there is the stack overflow chain to post questions. We do monitor this stack overflow. We receive email notifications when you put some questions there. So we are going to reply to those questions.
And yeah, that's it. Any other questions? I'm pretty sure there is a lot of questions, hopefully.
If not, I think now is lunch time. By the way, tomorrow we have a dev lab going on. Do you know dev lab? Dev lab tomorrow is starting 1:00 PM to 5:00 PM. We, I think, will be at the lowest level. We're going to talk more about that.
Dev lab is a session for you to come with your question, and spend time with us to answer your questions. It's not a class. It's not a seminar. It's not a lab. It's come with your question, bring your computer, and say, OK, I have a problem with this code, it's crashed, and whatever. Help me fix it.
And it's going to happen tomorrow from 1:00 to 5:00 PM. And I will be there, and many of my colleagues will also be there. And I hope you can come to answer questions, and get those problems sort out.
And now it's lunchtime. Go back to the fifth floor. Lunch plus shirts. And see you guys later. Yeah. Thank you.