SOLVED: How can I use my callback URL to construct a Client instance with Data Exchange .NET SDK?

SOLVED: How can I use my callback URL to construct a Client instance with Data Exchange .NET SDK?

Blake_Hageman
Explorer Explorer
807 Views
2 Replies
Message 1 of 3

SOLVED: How can I use my callback URL to construct a Client instance with Data Exchange .NET SDK?

Blake_Hageman
Explorer
Explorer

I am following the developer's guide to initialize the Data Exchange .NET SDK. It is not clear from the documentation or examples how to use the callback URL to return the OAuth workflow to the client constructor.

 

I am calling the constructor with:

 

 

SDKOptionsDefaultSetup SdkOptionsDefaultSetup = new SDKOptionsDefaultSetup()
{
    ClientId = AuthClientID,
    ClientSecret = AuthClientSecret,
    CallBack = AuthCallBack,
    ApplicationName = ApplicationName
};

IClient Client = new Client(SdkOptionsDefaultSetup);

 

 

 

and after the OAuth workflow completes, it sends me in my browser to my callbackURL with the auth code in the query string. Then I am just sitting in my browser with no clear next step, and the final line of code (line 9) above has stalled waiting for a response. How do I use my callback URL to connect the dots back to the stalled line of code in my application so the Client can finish being constructed?

 

Alternatively, can I just complete my own separate OAuth workflow (as I already have been doing) and give the final three-legged token to the Client constructor somehow to avoid the Client constructor from triggering the OAuth workflow altogether?

 

EDIT: I was able to figure this out pretty quickly, thankfully. Solved it by specifying my callback URL as a localhost port that is different from the one I am using to run my app. The Client constructor sets up a System.Net.HttpListener for whatever callback URL you specify; I was having issues before because my callback URL was overloaded and my app was intercepting the response that needed to get back to the Client constructor.

0 Likes
Accepted solutions (1)
808 Views
2 Replies
Replies (2)
Message 2 of 3

Tobias_Hathorn
Autodesk
Autodesk

Thanks for confirming you unblocked yourself! 
Are there any improvements you'd recommend to our docs so others can avoid this?

Please share any other feedback - the SDK is in a Public Beta so we are VERY open to suggestions and feedback...
Also, very curious what you're up with the SDK? What connectors or workflows are you developing?

0 Likes
Message 3 of 3

Blake_Hageman
Explorer
Explorer
Accepted solution

I think some text in the docs (either in the Developer's Guide or API Reference sections, or both) that explains how the callback URL is used would be helpful. I also think it would be nice to have a little more control over the Client object's authentication process i.e. a way to feed the Client your auth token as an argument. For example, the current Client auth process requires persistent admin permissions to mess with the System.Net.HttpListener; admin permissions wouldn't be required if you could manage the auth workflow separately.

 

I will post other SDK questions/feedback I have in different threads so they are easier to find for others!

 

Currently, this work is toward building a custom connector that allows for analyzing Revit model(s) data via Data Exchanges, so most of what I'm figuring out now is how to best get and use the data available in the Data Exchange format.

0 Likes