Wondering whether redeem RESTful API allows for additional information, such as metadata or any other key/value pairs, to be passed to Branch.io? We need to pass additional information other than branch_key, branch_secret, identity, amount, and bucket.
Thanks in advance!
The referral_redeem api will require the branch_key, branch_secret, identity, amount, and bucket values to redeem credits to a specific user. No other values are required. Reference to our documentation Here
The response will be either a success or failure with an error message.
If I am misunderstanding your query please let me know.
Related
Is there a way I can update another user attributes using AWS amplify with cognito? I.e. when user reply to a post I want to change a rating of a person that started a thread. Or for this I will need a table in DB to manage it.
In docs i see that there is a method:
https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/CognitoIdentityServiceProvider.html#adminUpdateUserAttributes-property
but I dont see a way to use it in Amplify.
I have not seen any API of aws-amplify which can alter user attributes as admin.
Generally, it is good practice not to duplicate data or keeping data duplication minimal if unavoidable. In other words, keeping a single source of truth. Use Cognito as only for authentication, I mean obtaining JWT token.
Rating, user basic info, and role; keep those at your own data source.
I need help to the follow issue:
Each endpoint of my API is decorated with the "Authorize" attribute, where I indicate the claim or the necessary claims to access the endpoint. However, the same user can have a considerable amount of claims and these claims will be stored in the database. So with every request in my API, I need to intercept this request, identify the user, query the database to see if it has the required claims, and return, providing or denying access to the requested endpoint. Most of the implementations that I saw on the internet, pass the claims in the code itself, in a static way, and that does not meet me.
I tried to implement some custom filters, but I was not successful either.
Could someone help me solve this?
Thanks!
I recomended you to use JWT Authorization.
It's easy to implement and also secure.
In this article you have an example with how to do it. I hope that's help you.
https://code-maze.com/aspnetcore-webapi-best-practices/#jwt
I’m currently storing the Token in order to access the social tables web service but now realise tokens expire after just 2 weeks. I presume I need to use the POST token function to get a new one? If so, where do I find the values for client_id and client_secret?
You will need to make a Social Tables App in order to use our oauth routes. Here are some nice instructions from our docs:
https://developer-portal.socialtables.com/docs/apps/
Once you have your client_id and client_secret, you will be able to use the oauth authorization flow to allow user to grant your app access to their data.
https://developer-portal.socialtables.com/docs/authentication
Please feel free to post a follow up if this process gives you any trouble.
I have a question about RESTful APIs and security in a multi-tenant environment.
Imagine you have an endpoint: api/branches/:branchId/accounts/:accountId
Authentication is done through Bearer Tokens (oauth2). Each token includes a set of claims associated to the invoking user. A branchId claim is included in the token, and each user belongs to a single branch.
The security restrictions are the following:
The branchId of the GET request should match the one stored on the token claim.
accountId should be a valid account inside the branch identified by branchId.
The question is: which of the following solutions is correct?
Maintain the endpoint: api/branches/:branchId/accounts/:accountId. And do the required security checks.
Change the endpoint to: api/accounts/:accountId, obtain the branchId from the token, and then do the remaining security checks.
The application is meant to be multi-tenant. Each branch is a tenant, and each user may only access the information associated with its single branch.
Thanks!
I needed to make a decision fast, so I will be using solution 1. If anybody has an argument against or in favor please join the conversation.
Arguments in favor:
I totally agree with this answer: https://stackoverflow.com/a/13764490/2795999, using the full URL allows you to more efficiently decide which data store to connect with, and distribute load accordingly.
In addition you can easily implement caching, and logging because the full url is descriptive enough.
Independency of security and API. Today I am using OAuth2 but perhaps tomorrow I can send the request signature, and because the URL has all the information to fulfill the request it will work.
Arguments against:
Information redundancy: the branchId is on the URL and encrypted on the token.
A little more effort to implement.
I have an API that provides an Account resource based on the authentication (login) that is supplied. As a user can only have one account, and can only see it's own account and not those of others, this API will basically be a single resource API in all cases.
So to keep things simple, I have this resource under the url accounts/ and when you access accounts/?username=dude&password=veryhard you'll get your account data (if you dohn't supply authentication you'll get a 403).
Now I wonder if this is RESTful. Also, you should be able to update your account info, and I wonder if PUT would be appropriate. In my knowledge, PUT should be done on a unique URI for the resource. Well, is this a unique URI for the resource? Generally a URI for an account would look like accounts/3515/ where 3515 is the account id. However, users don't know their account id. Also, there should be more ways to log in, instead of a username + password you should also be able to use a token (like accounts/?token=d3r90jfhda139hg). So then we got 2 URL's that point to the same resource, which also isn't really beautiful for a RESTful URI, is it?
So, what would be the most RESTful solution? Or should I not do this RESTful?
REST purists will consider that use of /accounts/ to obtain a single account is bad practice as it should specify a collection. Instead consider a key which cannot be mistaken for an ID, for example if your IDs are UUIDs then use a token such as 'me' so your URL is /accounts/me. This has the advantage that if later on you wish to obtain different account information, say for example you need to list users or you have an administration system using the same API, then you can expand it easily.
Putting username and password in the URL is also not pure REST. The query parameters should be directly related to the resource you are obtaining; commonly filtering and limiting the resources returned. Instead you should seriously consider using something like HTTP Basic authentication over an encrypted (HTTPS) connection so that you separate out your authentication/authorisation and resource systems. If you prefer to use a token system then take a look at oauth or hawk.
Finally, yes if you use PUT you should supply a full resource identifier. Given that it is very common for systems to read data before updating it the lack of ID won't be a problem as that will come back as part of the prior GET.
Yes accounts/?username=dude&password=veryhard is a correct REST URL.
PUT is used with an id if it used to update a resource, if you use it to create you must supply an ID. otherwise you use post to create a resource without id