Xero API invalid OrgId - .net-core

Working with Xero API
Authorization callback returns org, which should correspond Organisation's ShortCode for which Xero user allowed access.
In callback org value is BFtWATeLda24OXh2Yv-FLG but Organisation's ShortCode is !hvw0y, which obviously does not match.
Other possible field that could be matched
OrganisationId - 29e0fd2c-15da-409e-8462-1ac28b9f8f55 no match
ApiKey - QIBVL4B2BBDNE5WBADGFHZEQYR6SXM no match
I wonder how can i link value org callback parameter to Organisation in Xero.
Using Xero API .NET Core client

Is it named the org_muid? If so, that value returned in the oauth call is actually a one way mapping of the OrganisationID. It's a legacy property from before the OrganisationID was returned from the organisation endpoint that is still returned as the removal of it could cause breaking changes for those who use it as the identifier in their token databases.

Related

MobileServiceUser returns wrong UserId

I have an existing user in my Xamarin Forms app whose Details are as follows:
First Name: Jim
Last Name: Smith
ProviderLoginId = jsmith#google.com
OAuth Provider: Google
When I first create this user, I use the following method to authenticate against google as follows:
result = await AuthenticationClient.AcquireTokenInteractive("https://***.onmicrosoft.com/profile.read/profile.read")
.ExecuteAsync();
JObject objToken = new JObject();
objToken.Add("access_token", result.IdToken);
MobileServiceUser user = await App.syncMgr.CurrentClient.LoginAsync(MobileServiceAuthenticationProvider.WindowsAzureActiveDirectory, objToken);
Now, I take the UserId property from the MobileServiceUser user variable and store it into my User Table as primary key.
Subsequently, I create another new user with the following details:
First Name: Jim
Last Name: Smith
ProviderLoginId = jsmith#hotmail.com
OAuthProvider: Microsoft
When I create the user using the same steps as above, I get the same UserId back from Azure. Obviously, I am not able to store it in my User table for the second user. This only happens when the first name and the last name are the same regardless of which ProviderLoginId was used (whether it was Google OAuth or Microsoft OAuth).
Should I not be getting a unique UserId in each case? Since the bug surfaces only when the first and last names are same, I am assuming it is some sort of a bug.
Any and all help is appreciated.
You are using the older client, which is no longer supported.
You should be submitting the access token to the service, not the IdToken. You haven't stated what the AuthenticationClient is, but hopefully it is ADAL (since the older service doesn't work with MSAL).
The newer client and service completely abstracts the authentication code, allowing you to use whatever authentication mechanism you like and just dealing with standard OAuth2/OIDC and bearer tokens (Authorization header) instead of the non-standard X-ZUMO-AUTH header that was used in the past. My recommendation is to upgrade the client and server.

LinkedIn API error when retrieving UCG Posts by Author

I'm making a call to the LinkedIn API to retrieve the full list of posts by my organization but keep getting the error;
Field Value validation failed in PARAMETER: Data Processing Exception while processing fields [/authors]
I believe I have all the necessary permissions (r_organization_social to be specific);
r_1st_connections_size, r_ads, r_ads_reporting, r_basicprofile, r_emailaddress, r_liteprofile, r_organization_social, rw_ads, rw_organization_admin, w_member_social, w_organization_social
Here's my request;
https://api.linkedin.com/v2/ugcPosts?q=authors&authors=List({COMPANY_URN_URLENCODED})&oauth2_access_token={LINKEDIN_ACCESS_TOKEN}
It's the same result if the URN isn't URL encoded.
I'm following steps here - https://learn.microsoft.com/en-us/linkedin/marketing/integrations/community-management/shares/ugc-post-api#find-ugc-posts-by-authors
Any ideas?
Try this link:
https://api.linkedin.com/v2/ugcPosts?q=authors&authors=List(urn%3Ali%3Aorganization%3Acompany_id)&sortBy=LAST_MODIFIED
Replace company_id with your company id
I have used this as my api call to retrieve my company posts.

Can I use my test environment merchant ID and keys to test a flex microform post?

I'm getting started understanding what's required for Cybersource's Flex Microform integration. But to start with, I'm hoping to be able to see a valid response using my merchant ID, shared secret key and the general key that comes with generating the secret on the cybersource api reference page: https://developer.cybersource.com/api-reference-assets/index.html#flex-microform_key-generation_generate-key
This is using the HTTP Signature method and ChasePaymentech (default) processor.
If I use the default settings they supply and choose to do a test POST to here https://apitest.cybersource.com/flex/v1/keys?format=JWT&
The JSON response is good with no complaints of authentication.
If I try to do the same POST with my test environment merchant ID and keys I generated in my merchant environment here: https://ubctest.cybersource.com/ebc2/app/PaymentConfiguration/KeyManagement the POST response will return a 401 with this JSON:
{
"response": {
"rmsg": "Authentication Failed"
}}
Is this developer.cybersource.com site a valid place to perform this kind of test? Are there any other steps I need to do in the merchant account to have this Authenticate?
I'm just getting started on figuring out the CyberSource Flex Micro Form code out myself and it's pretty straight forward from what I can see. If you don't have the proper SDK already pulled in, you can fetch it from https://github.com/CyberSource
I had to use Composer to fetch all the dependencies but once I did, I was able to load up the microform checkout page in my browser window successfully. Make sure you edit the ExternalConfiguration file with your credentials that you setup in CyberSource.
The apiKeyId value is the value you can find in your CyberSource account under Key Management. This is the value with the dashes in it.
The secretKey value is the value you should have downloaded from CyberSource that is your public key. This is the value without the dashes and probably has a few slashes / in it.
That's all I had to do in my setup to get the first successful authentication / token on my end.

How to limit only issue fungible token once with a specific account by Corda Token SDK

Corda Token SDK https://github.com/corda/token-sdk.
By default, the fungible token can be issued many times, to many accounts.
I do not know to limit that fungible token is issued once and sent to a specific account
(after that token will not be issued any more)
Does anyone have an idea?
To implement that, you'd have to do the following:
Create your own EvolvableTokenType.
Your evolvable token type will have 2 custom attributes (that can be changed over time, thus why we chose evolvable over fixed token type):
issued of type boolean
issueAccount of type AbstractParty
Create a contract that validates your evolvable token type (it should extend EvolvableTokenContract):
Implement additionalCreateChecks: You can keep it empty.
Implement additionalUpdateChecks: Here you can validate that you can only update the value of issued to true, you cannot update it to false (this will allow issuing more of your token type which we don't want).
Create a flow that creates your evolvable token type, it sets the issueAccount to the value that you pass as input parameter and sets issued to false.
Now you can create your evolvable token token type and use it to issue tokens of that type.
Create a flow that issues tokens of your token type:
It will fetch the latest version of your evolvable token type.
If the value of issued is true, throw a FlowException that this token has already been issued and you cannot issue it again.
Use the returned state to get the issueAccount value.
Call the IssueToken flow to issue your token type to issueAccount. Of course you need to generate a new key for the account using RequestKeyForAccount and wrap the returned PublicKey in an instance of AnonymousParty.
Now the most important part (your requirement): Call UpdateEvolvableToken flow to update your evolvable token type and set issued to true. This way if someone calls your issue tokens flow again, it will throw an exception because your token type has been issued.
The Kotlin template (token branch) has a high level example of EvolvableTokenType:
Type: https://github.com/corda/cordapp-template-kotlin/blob/token-template/contracts/src/main/kotlin/com/template/states/ExampleEvolvableTokenType.kt
Contract: https://github.com/corda/cordapp-template-kotlin/blob/token-template/contracts/src/main/kotlin/com/template/ExampleEvolvableTokenTypeContract.kt
Flow (it has 2 flows, create token type and issue it): https://github.com/corda/cordapp-template-kotlin/blob/token-template/workflows/src/main/kotlin/com/template/flows/ExampleFlowWithEvolvableToken.kt
Also the Tokens SDK has an example that uses EvolvableTokenType where the House token has an attribute that can change (valuation):
https://github.com/corda/token-sdk/blob/master/docs/DvPTutorial.md#define-your-states-and-contracts

configuration spring MVc websocket messaging spring security

I customized the tutorial http://assets.spring.io/wp/WebSocketBlogPost.html into my application . When sending message from the application to the server using SimpMessageSendingOperations.convertAndSendToUser("fabrice","/stayawakews2/shakebaby", "mano") the log show :
/stayawakews2/shakebaby*-userltmei5cm* .I dont know why it add the value -userltmei5cm .
thanks
this is explained in the reference docs, see the section on user destinations and also these slides.
ltmei5cm - this is a websocket session id. This value generates on client side.
One logined user can have some websocket sessions.
For each webscocket connection(session) spring create individual queue.
If you send message to specific user, message will be added to some queues.
For this reason, the user name is replaced with the webcoket session id.
From JavaDoc comment to DefaultUserDestinationResolver.java:
When a user attempts to subscribe to "/user/queue/position-updates",
the "/user" prefix is removed and a unique suffix added, resulting in
something like "/queue/position-updates-useri9oqdfzo" where the suffix
is based on the user's session and ensures it does not collide with
any other users attempting to subscribe to
"/user/queue/position-updates". When a message is sent to a user
with a destination such as "/user/{username}/queue/position-updates",
the "/user/{username}" prefix is removed and the suffix added,
resulting in something like "/queue/position-updates-useri9oqdfzo".

Resources