can any explain me about how the server responds if we click the button in browser using PHP script then which situation we use JAVASCRIPT and which situation we have to use PHP .
If you're asking about how it works, I'll suggest to google about HTTP protocol, POST and GET methods.
Usually, you use JavaScript to send request to a server when you want it to be AJAX, ie when you want to send request to server and receive response without reloading page. And you use PHP when you have form in your HTML (like login or registration form), and you send it to server in one request to go to another page
Related
I am implementing google reCaptcha. In the Google documentation, they say the way to do it. The documentation suggests server side validation of captcha. I wanted to know why we need to verify it in the server side as it is already verified in the UI side from the google server. Is it a suggested to implement captcha in the UI side alone with no validation in the server? What are the problems(if any) if done in UI alone.
a example would be: you're creating a register form and want to prevent bots to create a account on your site, you need to verify it serverside, because in the background you're sending a request which will look something like this:
POST /register 1.1 HTTP
Host: www.example.com
{"username":"example","email:"hey#gmail.de","captcha-token":"123984f729340fmu2q34f9"}
and if you dont send the captcha-token with the request or the server doesnt validate it, this bot could just spam this request without loading the frontend page. Please mind in head, that bots dont visit your "UI" (frontend page). Just verify everything serverside like text length, bad characters, rate limits...
now I am learning how to build single page web applications with node.js. When I come to the communication part between server and client, I am confusing about the difference between http post request and web socket communication
Here is my understanding:
Web socket like socket.io is asynchronous communication while POST is synchronous communication method.
socket.io is mainly used in dealing with real-time task like html games or dynamic online chatting, or boradcasting some informations.
for validating forms when some user sign up for certain website, it is really good to check instantly if the user name is already been taken or not, I think it is using socket.io to achieve that.
for example in a login page, after I press the username and password, then press 'login' button, I could just use emit things in socket.io to transfer a JSON file with these information. when we checked these information and send back a flag string like 'true' or 'false ' to indicate if the login is success or not.
So my question is:
Why we still use HTTP POST for login and signup ?
Is socket.io better than HTTP POST ?
Why not replace HTTP POST with socket.io ?
P.S for some large files, I have not go into these parts, so I have no idea.
Here is some additions:
After reading a similar question I find I seem to assume that WebSocket is a replacement for HTTP. It is not. It's an extension.
I think this asnwered my third question Why not replace HTTP POST with socket.io.
I have developed a front-end interface using Aja(AngularJS) and HTML5. Right now, I send an HTTP get request to my backend server which returns some data based on the GET parameters.
Since the URL is exposed in the Javascript file, I believe anyone could just use the URL to create there own API to fetch the data. How can I prevent such things ?
One way I could think of is that now instead of directly sending the request to the backend server, an application server could be used (hosting the HTML as well). The Ajax request would then be sent to this server (PHP script ?) which would in turn forward the request to the backend server and return the result to the UI. To prevent 3rd party services, I can disable cross origin requests on my application server.
Is this the correct way to solve my problem or are there better ways to do this? I am concerned that this would unnecessarily create another hop (internal though) for requests.
Note: The backend is running Apache Tomcat
In APIs that are not open to the world the user has to authenticate first in order to use it, see for example https://stripe.com/docs/api#authentication or http://dev.maxmind.com/geoip/geoip2/web-services/ -> Authorization
While trying to serve a page from node.js app I hit with this question. how multiple files are serving from a server with a simple request from user?
For eg:
A user enters www.google.co.in in address bar
browser make a request to that url and it should end there with a response. But whats happening is, few more requests are sending from that page to server like a chain.
What I am thinking now is, how my web browser(chrome) is sending those extra requests... Or who is prompting chrome to do it? and ofcourse, how can I do the same for my node.js app.
Once chrome gets the html back from the website, it will try to get all resources (images, javascript files, stylesheets) mentioned on the page, as well as favicon.ico That's what I think you are seeing
You can have as many requests as you want, from the client side (browser), using ajax. Here's a basic example using jQuery.get, an abstraction of an ajax call:
$.get(
"http://site.com",
function(data) { alert(data); }
);
I get this question a lot =/
But I only know how to answer it at a very high level.
From the minute a user enters a URL and hits enter, what happens on the client and server side, and how do requests/responses work? How does the server interact with CGI/interpreters?
It would be helpful too if you could direct me to a URL that has this information in detail, or if you can answer it.
When I describe this to people I always feel like theyre looking for specifics and I'm not giving enough detail.
Thanks!
Client initiates communication (Usually a HTTP GET request)
Server receives REQUEST-HEADER and parses the URL contained within.
Server does a lookup to see if any URL matches locally in a harddrive-folder. If the webserver handles virtual servers like a Microsoft IIS, then it will determin which folder to search after retrieving the "www.domain.com" part from the REQUEST header.
If web-document (HTML file) is found, then Server sends this back as RESPONSE + a HTTP status code (eg. 200 saying: found, this request went well, where as 404 is "didnt find that file")
Client (browser) receives RESPONSE and can now display it as it wants. If it contains a render engine, then it will search for patterns (HTML tags or whatever language) and then display it as such.
This is also called "stateless" as the server closes communication with client after the client has received everything from the reponse-stream.
Therefore the server cannot know if the client is still connected nor if its comming back later. Many servers does provide a session object using cookies or similar to track if its the same client that sends the next REQUEST and if so, allowing more "intelligent" server responses - such as seeking, transactions and logins.
How does the internet work?
HTTP Made Really Easy
The Canonical Document: RFC 2616
The client sends request headers to the server (finds the IP via DNS).
The server software (e.g. Apache) calls CGI if it needs to and prepares the response.
It sends headers back as well as the content.