HTML page has a submit button. On clicking the button, the 4 APIs has to be called. All the 4 APIs are linked to each other.
For instance, the first API is used to get the access token. And the token is passed in the second API to process the GET request.
I am new to REST APIs and not sure whether it's easy to call via HTML or better way by using PHP.
You want to use, not to implement API.
You should decide first on which side (server or client) it should be implemented.
On server side you do requests on your behalf. You are responsible for them. They are done from your IP address. But you can hide API address from client, you can cache response or control this process somehow. Use PHP cURL extensions for that.
On client side, requests is performed by end user, from his IP. Read How to enable cross-domain request on the server? to learn about requests to different domains. Search for AJAX. Probably, use some library like jQuery to write less code.
Related
one of my vendor he is asking a posting page where he can send some varaibles from his portal which is in asp.net.
My website is in php. what posting page i should be providing him and how to fetch whatever he is sending.
You may disable the CSRF validation (if you have any) to achieve this task.
However the standard way is to create webservice to achieve this goal.
The best and easiest API to implement is RESTful.
Here is reference to that:
How to create a simple REST API in PHP
Creating a simple REST API in PHP
It doesn't matter what language the vendor use or what you use...
He need to you to specify him what is your script URL that you allow him and expect POST request from him to do what he need.
If it's from his server side (for example in PHP we use curl),
so he need to use asp.net way to post request...
maybe this will help him how to do it
How to make HTTP POST web request
If he doing those request from client side (ajax),
so he can use jQuery http://api.jquery.com/jquery.ajax/
and in your side to allow in the php script the "access control allow origin"
see:
how to bypass Access-Control-Allow-Origin?
I have developed a website with my friend. For the front-end we are using AngularJS, and for the backend we're using Laravel.
Whenever data has to be fetched, an API call is made from front-end to PHP.
My concern is that this API call is clearly visible in network panel. Then some bad guy can easily abuse this API. How can I avoid this?
In most cases exposing your API is not bad thing, but you need to think about this:
1. You should design your API, so only legitimate operations can be made. In example: person shouldn't be able to delete whole database using API.
2. You could provide some authentication mechanism if needed, so the person trying to call your API will have to be logged in (authentication token should be stored in session and verified in server-side with every API call).
If you want to hide POST/GET Params form console. Try to make JSONP call in angular . JSONP calls are not real ajax requests and won't be shown in Firebug. You can also clear the console using clearconsole() after you receive the response and you can also authenticate the requesting IP in your laravel backend.
It's just like regular routing. For example: Everybody knows that they can access a user's profile on Facebook on the /:username route, but Facebook prevents unauthorized clients from viewing that data. The same concept is used for REST routes.
Just like regular page requests, AJAX calls and the data passed / received can be seen by the user. JSONP can be used to prevent the API requests from being logged by regular developer tools, but that is not a good security solution your API can still be discerned by a malicious user.
Even if you encrypt the request payload and the response, it can be intercepted by a malicious user before encryption and after decryption.
You mentioned using proper authentication on your API, which is usually good enough for most cases.
I am wanting to build an API first RESTful application in PHP. I have never attempted to do this so I have some questions about how to handle PUT and DELETE
So for an example if I have a API endpoint that updates a User profile, should I make it accept BOTH a POST and PUT Request?
If I was building a Client for my API as a Desktop app or iOS app, etc it would be easy to send a PUT request to my API but I plan to have a Web based app for my API as well.
So on my web based app, I would have an HTML Form to Update a User profile, this would then be sent as a POST as HTML Forms do not allow PUT requests.
Could someone with more experience with this explain the best way to handle my example scenario?
Would the proper way be to send my Form as a POST to my PHP script, then my PHP script would make a proper PUT request to my PHP API with cURL?
You can absolutely also do PUT requests from browsers, but you need javascript.
Generally I would say a good way to think about it, is as follows:
First build a great REST api that follows all the rules. Only once you are at that point, think about the workarounds you need to make it work in other contexts. Submitting an HTML form is a valid thing to need a workaround for.
However, since 'POST' is completely open for interpretation, and has little rules associated, one option would be to create a single resource (or url) on your server that handles all the POST requests coming from browsers. (something like /browserpost).
You could always add a hidden <input> field with name="url" that specifies which resource was actually intended to be updated, and an <input> with name="method" value="PUT" for the intention.
You will need to add CSRF protection anyway, so I feel this would be a solid way to deal with this this. 1 endpoint to specifically 'proxy' html-based form submissions and internally do the appropriate mappings to the correct REST services.
I would use GET POST PUT DELETE as they are described in HTTP. That's restful (in my opinion). As regular browser forms does not support this I would send the data via AJAX.
If you really need to use browser forms, maybe because javascript is not enabled, then using POST requests with a param like ?method sounds like a suitable solution - although I don't like it.
On many places (Google, Yahoo, Stack Exchange... ) I found that Ajax coding (for example php+Ajax login system) is not, and cannot be secure enough. So many reserve about Ajax security, and nowhere you can find an example of secure Ajax code.
At the same time, all this sites (even Facebook, Twitter...) USES a lot of Ajax code, for registering and loging users, for commenting features etc. Seems like Top Secret matter.
So, could someone show an example of secure php-Ajax code ?
An AJAX request is just like a normal browser request, just in the background. So if you would normally have a login form that posts data to your checklogin.php, you can do the same with AJAX and its equally secure.
Another thing to keep in mind is with cross site javascript calls. This is used for example when you are creating apps on facebook to transfer data from/to your server. These request have to be signed to make sure the data is comming from a valid source. This is done by using a secret and public key. These sites use oauth to handle these request. You can also implement this in your own site, but for any regular authentication (login/post messages/etc) this will not be needed. Just code like you would if it were a regular request.
I have a catch 22 situation here with the google analytics tracking code.
I have a form that upon submission submits data to an api.
We recently decided to record this submission as an ecommerce transaction with the google analytics tracking code. The transaction does not get recorded until the application get submitted and returns data from the api. This is because data from the api is included in the transaction.
The issue is that the form also autosaves data to a database so that if the form is not completely filled out and/or submitted an automated php script can pick it up later for submission to the api.
Now the catch 22
I need to find a way to implement this for the data that is submitted via the automated php script.
3 solutions that won't work
Submitting the the transaction on the serverside to ga. This is possible, but in this scenario all the data that google analytics collects from the client comes from the server which eliminates the whole purpose of using google analytics to begin with.
Submitting the transaction before the form is submitted. Remember we need to retrieve data from the api to submit in the transaction.
Saving information about the client to the database for including in headers when submitting the transaction on the serverside to google analytics. Something like this would probably work that is if I new all the information that google analytics collects about the client, how to spoof my ip address and had the time to build a solution like this.
Use AJAX for your auto-saves and use SUBMIT for the final update.
For option 3, you could use the Urchin tracking methods to simulate the data as it would be sent to Google Analytics, and instead send it to a local file which scrapes the request info and then sends it to Google when its done.
So, your JS code would look like this:
var pageTracker = _gat._getTracker("UA-XXXX-1");
pageTracker._setLocalServerMode(); //this disables external GA calls.
pageTracker._setLocalGifPath("/foo/bar.gif");
pageTracker._trackPageview(); //or your transaction calls
From looking at the URL request this makes against a regular __utm.gif request, it seems that the only important thing missing is the utmcc parameter, which appears to be a url-encoded version of the Google Analytics cookies. You'd want to track this as well (out of document.cookie, or on the server side), so that you could add it to the query string when you make your Google Analytics request. This is important because this is where the session and source information is stored; otherwise your tracking won't have context.
Then, on the server, bar.gif could rewrite to bar.php, which captures the query string and request headers that Google would have sent to its servers (of primary importance is the query string and the user agent string and the IP address); , and then adds whatever data it needs, then takes the resulting query string and makes a cURL request to the Google Analytics version of that URL, with spoofed headers for browser, etc.
Unless you can use asynchronous tracking code to send the data after the API returns the necessary bits of data, there is no sensible way. The method described above is good and all, but would still require you to spoof IPs to Google, as the IP is read from the incoming call and it would again be the server.
In my experience Google Analytics is not the correct tool for cases such as this (server side tracking).
There's a question about sending Google Analytics hits from the serverside at #1027660 that has several suggestions on how to generate a server-side click.
Whilst that contravenes your "can't do it this way #3", you might find it looks simple enough to be worth breaking that rule.
Good luck!