In order to restrict actions to specific tokens I need to check if a request made to my api is made from an frontend or backend application.
I want to implement the same behavior like Stripe. Using a secret key on client side will result in an error.
So is there a safe way to check this?
The answer could be through the User Agent, but in fact there is no exact way to identify and differentiate whether a request came from a browser or from another API for example, as it is possible to manipulate the User Agent.
Well-behaved "bots" (like common search engine spiders) will identify themselves using a User Agent specific to them.
Related
Noob here working on first backend project.
What I’m trying to do...
Collect member data via my form (name, email)
User clicks paypal button to pay for membership
When payment approved by paypal, send post request with form data to my members endpoint to add new member
I now realize if I use postman to post to my members endpoint it works. So a malicious user could post data to my members endpoint regardless of paypals payment approval.
My understanding so far is that if my server allows CORS and I don’t password verify the user, anyone can post to that endpoint.
Is it possible to allow post requests only after payment approval without the use of a password?
I’m thinking of online stores that let you checkout without a password. How do they post the collected form data to their db without jeopardizing their post route?
Hope this wasn’t too vague. Pointers would be greatly appreciated!
I’m using node/express, but since it’s a general question I assume it doesn’t really matter..
These answers helped but still didn’t get me there.
Protecting post routes NodeJS
Can I only accept traffic from certain requesting domains with Expressjs?
So post / get request in general are functions of the browser and or server, I can create a simple html form and post to any URL I want to.. Now the question is, will it accept it or not.
When communicating between servers and web-services unless open to the public will use token based authentication to validate the request. So in terms of paypal, the typical flow would be.
(note, very oversimplification below and is just a sample of one such pattern)
User clicks paypal button from your site ( this will contain some type of paypal ID of sorts )
User is directed to paypal and after completing the transaction paypal redirects users back to your server with a token
your server reads the token ( sends API call to paypal with token to verify its valid, if success then process the post )
You can't prevent a user from posting data to a URL, however you can tell the server what to do if they do. So protecting your route from unauthorized post can be handled by sessions, tokens etc. For example, if you have a route on your server, lets call it user profile. This route first executes a check for the session, if its there keep processing, if its not, redirect the user.. Its really no different for callbacks / token auth.
Essentially, you will need to handle what the server does in your code because anyone can post to the endpoint.
To your other question about how companies handle guest checkouts, this can be done a few ways but one way is to create your own token, this token would be an encrypted string that may contain a cart ID, time etc.
When a user clicks 'checkout' the token is generated and passed to the server via a get or post request. From there your server decodes the token and if everything is correct processes the order otherwise it kicks it back.
Again, you see a lot of token based stuff here going on and that because there is an X factor in all of this.. the user.. We know who the server is but the user can be from anywhere and the user isn't a server so we need some way to maintain state between servers, hence tokens, encryption, JWT etc
I'm attempting to use the new Constant Contact V3 API to add a new email contact. I've been reading the docs: https://v3.developer.constantcontact.com/api_guide/client_flow.html, and trying it out and it seems like the only way to do this now is to make an authentication request, approve the request and then retrieve and access token that is valid for only 2 hours.
I need to have access from my server only and just send an add contact request to Constant Contact. I don't understand why I require to have a redirect uri now and an access token to use the V3 api instead of just using the api key.
With the V2 api I was able to make these types of requests directly from the server without hassle and that's exactly what I need now. The V2 documentation seems to be taken down so I can no longer do that so I'm stuck.
Any help is appreciated.
Based on this link: https://community.constantcontact.com/t5/Developer-Support-ask-questions/v2-or-v3-API-for-very-basic-integration/m-p/324777#M11434, it seems like server-to-server auth is not available still. For those of you who have the same issue, use Mail Chimp or another service that has basic api requirements.
You can get INITIAL Access Token without any code - just use your browser and curl. The Access Token is valid for 24 h, but you can automatically renew it using Refresh Token. You can renew it automatically every time it expires and never need to proceed through INITIAL flow over again. You can read about it here. If you are using C#, I have templates and instructions exactly for your scenario here: https://github.com/mikeks/constantcontact-v3.
I've looked at various approaches to this but I'm yet to find one that is perfect for my set up.
I have a UI that calls the api to present data to a user - the UI doesn't require someone to login and i don't want to authenticate every user. What i'm trying to do is simply protect the api because with the url to the api, anyone will be able to access the data.
In my mind, i can create a password/ apikey of some sort and store that as an environment variable that is sent from the UI to the API whenever a request is made. On the API, that apikey/password is validated before allowing access to the api.
Does this sound wise? Would you suggest something else? Have i missed anything. All thoughts are welcome.
The solution sounds good to me. You can do something like this:
back-end: create a new REST endpoint (something like /api/get-token) in your Node.JS application which generates a token (or ID), saves it locally (maybe into a DBMS) and returns it as response. Then, in every endpoint you need to protect, you extract the token from the request and, before sending any "private" data, you check if the supplied token is valid, or not.
front-end: as soon as your application is loaded, you send a request to the newly created REST endpoint and store the given token locally (localStorage should be fine). Then, every time the UI needs to access "private" data, you simply supply the claim within the request.
The implementation should be pretty straight forward.
I need to edit request before sending it to endpoint.
Using Web Demo integration I'm able to send request to the endpoint.
But I can't edit the request in order to provide some extra data to request. Extra data is stored in localStorage so I need to do this in javascript.
I've already connected the agent to an endpoint that handle the request using fullfillment. The problem is that request misses data I can retrieve only from the browser. From fullfillment I can set headers and basic auth but statically and it is not enough.
So I need to add a step in request building/sending:
User write or tell something to embedded chat (Web Demo integration)
Dialogflow recognize intent, params, generate the request.
Additional step: Update the request in javascript
Forward cutomized request to the endpoint
Maybe it's not possible using Web Demo integration. In Documentation can't find a way to just send string or audio in order to receive the generated request.
First of all you will need a custom chat integration, not the default Dialogflow one. Something like Smooch or Kommunicate. The default web demo should only be used for testing your bot. There is NO way you would want to use that in a production environment.
I would save whatever is in the local storage in a database such as Firestore. Once that data is in the database you can use it to modify your request in your fulfillment.
So what I would do:
Have a way to identify a user and save its local storage to the database (as soon as someone clicks on your chat window or opens the chat window)
Once an intent is triggered you check which user is contacting you (through the way that you identified the user) and get all data from the database
Request the data in your fulfillment server
There is no other way in which this is possible. You can't change requests before your query hits Dialogflow.
I want to retrieve a list of recent photos with a given tag to display on a website in a very simple gallery.
For that, the doc says I need an access token. However, it seems that the only way to authenticate against Instagram is through OAuth; which involves sending the user to instagram and allowing my application access to their basic data. However, I don't want my users to do anything; I'd like my application to authenticate against Instagram for me and then retrieve the data I want.
Sounds simple, but all online documentation seems to end up in "Redirect your user to...". And I find no sensible ways to do this programatically; it's all about sending users away, letting them authenticate, and then receiving the access token afterwards. I could of course scrape the HTML, parse the forms (for example, the unique-per-session csrfmiddlewaretoken field which needs to be posted along with login requests etc) and let my server side application pretend to be my own user and login/authorize the app, but that doesn't seem like the way to go.
I could also just authenticate manually in the browser, pick up the auth token and paste into my application; but as the doc says: "do not assume your access_token is valid forever." - so I'd like this to be fully automated.
If I try to create a WebClient and POST to https://www.instagram.com/oauth/authorize/?client_id={clientId}&redirect_uri={redirectUri}&response_type=code&scope=basic it just returns a 403 Forbidden which is of no use. (For what it's worth, I'm using C# and have found instasharp, but this problem is not tied to any given platform...)
Am I completely overlooking something, or am I right that server side authentication against Instagram has become really complicated? Most other social media platform API's I've touched lets me get some form of authentication token just by posting a combination of the application id and secret.