Problem receiving JWT using C# DocuSign SDK - docusignapi

I am trying to receive a JWT from the DocuSign API using the C# SDK. The method that is used in the sample code from DocuSign is
ApiClient.RequestJWTUserToken(clientID,
impersonatedUserGuid,
authServer,
Encoding.UTF8.GetBytes(privateKey),
expiresInHours);
I have done all the pre-work: Creating the integrator key, Creating the RSA Private Key, obtaining consent. In the sample solution - it works, once I fill in the parameters, I receive a token and am able to execute the rest of the program.
However, in my proof of concept project, I do the exact same procedure and the method is returning null. I have been combing my solution for any differences however I can't seem to find the smoking gun. I created a new integrator key, new RSA key, obtained consent. What is interesting is, as a test, I took my new keys that were failing in my proof of concept project and put them into my sample code app - it worked. The exact same values in each project, one worked and the other failed. I even put the string values in directly into the method, again failed in my proof of concept but worked in the sample application.
I notice the sample app was using a different version of the DLL referenced, I changed my project to that version and it still would not work. Any suggestions I would appreciate.

without seeing your code it's impossible to know how it is different than the sample app. I wonder if you tried the sample code with the new integration key and RSA key you created?
Also, what the other user suggests, take the sample app and modify it so it becomes your code instead of starting from scratch. When you then run into the issue - figure out what was the last thing you change and it probably is the culprit.

Related

Public Google Apps Script - how can I make my API key hidden but still retrieve it?

I have a script that retrieves a webhook (meaning it has to be deployed as a publicly accessible App), and then uses an API to send a message.
The API requires using a key and secret, which I obviously don't want accessible to the public.
Q1: Is there a way to hide an API key/secret in another script and somehow have it accessible?
(Or any other similar solution - doesn't have to be fancy, just functional/safe).
Alternate Question:
Q2: What can a stranger actually see in my public Apps Script project? The full code? If I hide keys in a functions with an underscore ie. function name_(){}, can they read it?
IMPORTANT INFO: I have not 'shared' the project or spreadsheets with anyone, they're still private. But I've 'deployed' the Web App with permissions for 'anyone'. I assume that means anyone can access?
Everything in the script is visible to whoever has access (script owner, workspace admins, added users). Unless only the url of the webapp is shared and if the script itself is not shared then they are not able to access the script, so technically you can still keep them in your script. It is safe there and only the owner and workspace admins (if it is for Google workspace) can access it.
A way you can store/save the key is by storing it in script properties. Doing this you only need to run the script once to store the API key, moving forward you can remove the API key from the script and it will still run:
https://developers.google.com/apps-script/guides/properties#saving_data
Also refer to this post for more information, in my posted answer I have also provided alternatives and reference links:
Is it safe to put in secrets inside Google App Script code?
My project meet this issue, too. Because the amount of functions is not too much , So i hide my main GAS behind an dummy one .
So far I had 2 GAS
the main GAS with key , and all functions , and I deploy it as Web APP
Of cause u need doGet or doPost to do as entrance of API
The dummy one to share with users.
Then you can call something like below in dummy GAS
var url = 'https://script.google.com/macros/s/xxxxxxxxxxx/exec';
UrlFetchApp.fetch(url,{'method': 'get'});
I hope its useful in your case.

Xero OAuth2 Node API - Where does the API use the authorisation code provided to the callback?

I have followed the flow described here https://developer.xero.com/documentation/oauth2/auth-flow and can then get a tokenset which works with api requests.
However, looking at https://github.com/XeroAPI/xero-node-oauth2-app/blob/master/src/app.ts I don't see how/where the authorisation code provided to the callback is used to obtain the tokenset. (compare with Steps 2 & 3 of the auth-flow.)
Looking at https://github.com/XeroAPI/xero-node/blob/master/src/XeroClient.ts I think that apiCallback() looks like it should be the place - but nowhere any mention of the authorisation code.
The example provided (and the Xero client) relies on express being the handler framework. In any other scenario there is a lot of legwork required to imitate that.
Then finally I also discovered that the Xero client insists on using openid scope otherwise the client simply doesn't work. Nothing in the docs to either indicate this, or explain why this restriction is built-in.
The xero-node package uses the openid-client package, which retrieves the code and uses it to get the token set here: https://github.com/panva/node-openid-client/blob/master/lib/client.js#L461-L481
can you elaborate on what you mean by authorization code? You are correct that the apiCalback fn returns the tokenSet which you should be saving in your database associate with each user.
const tokenSet: TokenSet = await xero.apiCallback(req.url);
One of the benefits of using the SDKs is that you don’t have to do that code exchange step. The openid client handles that exchange for you. If you are to roll your own with solution you will have to follow all the steps as described in the first documentation link ^^
—
code a temporary code that may only be exchanged once and expires 5 minutes after issuance.
So lets look at https://developer.xero.com/documentation/oauth2/auth-flow again.
Step 1 looks simple enough, but but eventually I opted to go with https://developer.xero.com/documentation/oauth2/sign-in
That reference also shows how Step 2 should be performed, something the first link omitted.
However, if you then switch back to the 1st link you'll find the next Steps easier to follow.

Difference between logging in into salesforce sandbox with and without consuming wsdl?

I am very new to Salesforce and it's API.
I am having a sandbox org and with it I have url, username, password, security token and last but not the least partner.wsdl
My aim was to connect and retrieve/create data.
Technologies at hand was nodejs
So here is how I started.
I searched over the internet and came to know that I need to create a client, SOAP client in order to login, create the connection and use that connection to create and access the Leads data.So I followed this sample where the wsdl was being consumed.
So I was able to connect
I was very happy on this success and then suddenly I wasn't able to identify/find a way where I can get the sObject.I looked hard for this but no luck. So posted a question on SO
Meanwhile I also looked for other node module and found jsforce
I used jsforce starting guide and created a client that was connecting to salesforce however without using the wsdl file.
Again I was happy, even more happy because I was having the sObject with me.
Now, what is the fundamental difference if I login using the local wsdl file and without wsdl file in the language of salesforce. Which one is the correct way of logging in?
Sorry if this question is not according to SO rules or if there is a typo.
I'm the author of jsforce you mentioned.
In that lib we use REST API mostly and SOAP APIs are only used in some specific calls like login or metadata. Even in such calls we don't use WSDLs because there's no good lib to generate client modules from WSDL in JavaScript/Node.js area. Instead we wrote modules for each APIs which generate SOAP XML strings and parse the response XML.
It is enough because these API message schema are static and fiesible in the specific version, unlike SOAP API Enterprise WSDL differs in organizations. So we can hard code the client module directly w/o generate it from WSDL.

Am I supposed to publish my Spotify API key in an open source app?

I have created a simple app, script almost, that backs up playlist contents (just song titles/etc., not the music) off Spotify. It uses libspotify.
I want to publish the source; I wonder what the approach is for API keys in this case? Without the API key, if the user is required to provide it in some header file, the app becomes useless to most people.
I believe their approach in your case would be that you should publish the code but have your key stored safely in a directory outside the published code. That way, anyone using your code will have to get their own application key.
If you release your app in binary form they are OK with it being compiled into the application.
There's a thorough response at https://stackoverflow.com/a/15885844, complete with a sweet car analogy and all. :-)

Google Places Request Returning "REQUEST_DENIED"

I realise their are numerous questions regarding this issue and I have read them all, but I still cannot get this to work!
I have:
Created my project in the API console
Enabled Places API in services
Created a new IOS API Key (repeated this step twice now)
Tried the request with sensor=true, sensor=false and no sensor param at all
Tried HTTP and HTTPS
Those are all the fixes I found within the existing questions regarding this issue, have I missed anything? Here is a sample URL I am using to test:
https://maps.googleapis.com/maps/api/place/textsearch/json?sensor=true&query=Test%20sd&key=MYKEY
And yes, I am replacing 'MYKEY' with my actual API key :).
I am developing an IOS app using monotouch but I don't really see how that is relevant as I can't get this to work in the browser either.
Any help would be hugely appreciated! Been stuck on this all day now.
I believe you want to be using your "Simple API Access" key (not an Android/iOS key). The documentation mentions this as the last step.
https://developers.google.com/places/documentation/#Authentication
I tried your sample URL with my Simple API Access key and it was successful.

Resources