Good day, everyone! I start to develop a project with aws stack. And it has one important component - AppSync that working with a client and data. Also I have custom user structure and logic.
Now I need to add a handling for every user request (I want to check extra http header with their token).
Can I add middle ware or plugins for AppSync with my common logic for mutation every request (for adding field with status of checking this token)?
Some solutions that go to my mind: I can add same code for every resolver. Also I can setting up identity provider with Cognito or other services but it adds more extra complexity in the project.
Thank you!
After extensive research I didn't find any solutions for it. If You need the custom logic for global resolving of user requests, your own graphql server is one of the best options.
Related
I've got a frontend app that handles payments via Authorize.net. In the end, I've got a TransactionId attached to my own order object.
I would like to provide a direct link for my staff that takes them to the transaction in Authorize.net.
Our specific use case is for refunding, and I figured out this link in the sandbox: https://sandbox.authorize.net/UI/themes/sandbox/transaction/QuickRefund.aspx?TransID=1234567890
I would rather send them to the transaction, and let them click the refund button to get that page though.
This doesn't work: https://sandbox.authorize.net?TransID=1234567890
Anybody have any ideas? I could always write my own endpoint that does a refund via the api, but a direct link would be good enough and much easier if it exists.
This functionality does not exist. You will need to build your own endpoint that uses their AIM API to process the refund.
I know there is likely to be documentation out there somewhere but I have been drowning in Google searches trying to get my head around this!
I am working on my first Symfony project and I have a requirement to store files on AWS S3. There are three categories of file I am storing:
Type 1 - This should be accessible to anyone (although only on a request from my website).
Type 2 - This should be accessible to certain users. The list of users will change from time to time (friends list).
Type 3 - This should be accessible to the creating user and at times other users when accessed from a specific page.
I user the FOSUserBundle to handle my user authentication in my project.
At this time I'm lost in a sea of "IAM" users, "ACL" policies and I really don't know how to set something like this up - or if it's even possible. I also have the Gaufrette and liip/imagine-bundle bundles installed in Symfony (so I could add watermarks and resize)
Any help or resources that would point me in the right direction would be grateful.
t2t
Edit (21st Feb 2017
OK, so based on my further reading and the comment below I believe I can simplify what I need to do:
I want to have a bucket on AWS S3 which is restricted so that:
Files can only be read by a request from my domain, that provides a security token of some sort.
That will mean that even if the HTTP referred is spoofed a request to the S3 file will be declined as the token was not sent...
So, the question is - is this possible? If so, how should I proceed?
Thanks,
t2t
Please do not mix your project users with IAM users. Those things are completely separated. You need only one IAM user, which will upload files of all users of your PHP app. Any logic should be written in Symfony.
Currently I set up a RESTful API backend using Django and I can list a set of articles by the following GET:
api/articles/
Also, I can get a single article by:
api/article/1/
Each article is owned by a certain user, and one user could have multiple articles of course.
On the frond end side, I present all the articles at loading of the page, and I hope the user who is logged in currently could see the articles that they own in a different style, e.g, outlined by a box, and has a associated "delete" or "edit" button.
This requires me to tell, after the retrieval of the articles, which ones are owned by the current user programmatically. One way of doing this is to check the current user id with the owner id. However I feel this is not a good choice as the user id is the check is done fully on the client side and may be not consistent with the actual server judgement.
Therefore, is there a way, to tell by looking at the response of the GET, (say, let the server return a property "editable=true/false") to get whether the current user could edit(PUT) the resource?
I understand that this could be done at the server side, by attaching such a property manually. However, I am just asking whether there is better/common practice.
I just started learning web development and I am sorry if the question sounds trivial. Thank you!
You can attach propriety manually as you suggested. The advance of this approach is that you dont need any other http request.
Second possibility might be, that your client intentionally request information about endpoint permissions. In this case I would suggest to use OPTIONS HTTP method. You send OPTIONS HTTP request to api/articles/1 and backend returns wanted info. This might be exactly what OPTIONS method and DRF metadata were made for.
http://www.django-rest-framework.org/api-guide/metadata/
I think that this is a very interesting question.
Several options that come to me:
You can add to the GET api/article/1 response a HTTP header with this information i.e. HTTP_METHODS_ALLOWED=PUT,PATH,DELETE. Doing this way helps the API client because it does not need to know anything else. I think that this is not a good approach when more than one entity is returned.
call to OPTIONS api/article/1. Allowed methods for that user on that resource can be returned but notice that, in my opinion, this approach is not very good in terms of performance, because it duplicates the number of requests to the server.
But what if the entity returned also contains information on the owner or it? can, in this case the client know which policy apply and try to figure out it by itself? notice that the policy can be obtained from another endpoint (just one call would be needed) or even with the login response. If your entities do not contain that kind of information, it could be also returned as a HTTP header (like first option above)
I am working on a website's internal applications and what we want to do is to programmatically update our sales force data via api. For example, to update some entities on a a cronjob etc.
Generally this seems to imply the need for an admin type user that can acquire an access token and make REST Api calls. We could go about doing that, however, salesforce requires a password change every 60 days. How can I get purely programmatic access to our salesforce account?
Thanks in advance.
You're correct that it is a best practise to set up a dedicated API/Integration user. You can make a permission set with the "Password Never Expires" system permission enabled. Add that to your integration user and you're good to go.
I am in the process of building a RESTful API for my application. There are very few services that are public and the rest require authentication and authorization.
To be clear, my question is NOT about authenticating web services. I have already decided to send an HTTP header with an access token provided by the server. The reasons for this include:
Creating a "session" that can track the user activity
Timeout access tokens after XXX amount of inactivity
Track user behavior patterns for each "session"
So far, this approach is working fine. I am interested in any design guidelines for providing a "Login" service. I don't want to just authenticate a request, but I want to track usage of the web service against a "session".
In addition to "session" tracking, we have requirements that require that we track failed login attempts and take appropriate action after XXX number of failed attempts as well as password expiring and email address verification before authorizing, etc.
Specifically, I am concerned with the best way to design the URI's for this. One option would be:
/api/authentication/login?username=UN&password=PW
That could return the access token to be used in the header for secure service calls. Is this a good approach? Is there a better approach? Is there a better patter to use for naming the URI?
My biggest problem is that the URI is not purely sticking with the "URI's should represent resources" approach. End the end it is probably not a big deal, but I am wondering if there are better ways.
Thanks!
Often, RESTful APIs like to be stateless. That means that the API itself doesn't care about keeping a session, and doesn't.
What you do is authenticate 1 time, and then get a temporary key. That key eventually is no good anymore because the key has information in it about when it will expire.
Also, since these large APIs are built on message queues, they know timestamps for each action. and they can basically keep track of activity.
So, in RESTful API design, you often have scenarios where your URL has resources in it, and then there are all sorts of additional things that need to be set.
A good rule of thumb is to hide the complexity behind your ?. A typical use case of this philosophy is where you have a bunch of filter options on a get request of /some/resource. How is this relevant? Well, if you remember that its not a mortal sin to decorate your resource based API with other stuff occassionally, then you can treat other scenarios similarly when you feel like resourcefulness may be in question, but essentially you still have RPC-ish endpoints that need to exist to make your API fully functional for your needs. Or, of course, you can just arbitrarily set certain HTTP verbs to equal those things.
If you want to extend your resources with additional functionality, try to stick to the resource structure in your base url of the call, and then decorate it with your one-off needs.
Resource: /api/authentication
With modifier: /api/authentication/login
With data: /api/authentication/login?username=UN&password=PW
Its not so bad. But again, if you wanted to go completely restful, you could say something like this (this is pure conjecture, you need to decide these things for yourself):
Get logged in status - GET - /api/authentication/:id
Create / Update logged in status - POST / PUT - /api/authentication(/:id)
Log out - DELETE - /api/authentication/:id
... or you could have omitted the :id route and just hid that information in the body of data appended to the call, aka hiding complexity