Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Every where I look, I see that websites can be created in several different ways. Some sources say that you have to use HTML and add Javascript, but there are others ways I have seen, like using Node.js(how can this thing create servers?). Apparently there are a multitude of ways to make websites. How do these different methods(Node.js) create websites, and what is different from just using HTML and adding scripts to it? Additionally, how do these websites become available to the public after creation? I'm interested in what goes on to create web servers and get them public, not what to write to make it happen.
Everything you see in your browser is written in HTML/CSS. Your browser can display dynamic features by running JavaScript, as you said.
How this HTML and CSS is generated is where the various methods come into play.
An accessible web server will respond to any received requests (the internet is just a huge network). The web server looks at what resource was requested and will respond appropriately. This might involve running a PHP script, hitting an entry point in a C# application, or triggering an event in a Node.js application to name a few actions.
These actions all have something in common: they will result in some plain HTML/CSS/JavaScript/data being handed back to the web server, which is then sent back in the response.
In some cases, the HTML/CSS might be so simple that you can hand-write it and that's all there is to your website. Lots of websites have been written this way. No scripts or application needed (i.e., no PHP, Python, Node, C# etc).
However, if you want your website to be dynamic (e.g., simply display the current date and time) or big or complex or data-dependent, you wouldn't want to hand-write it. In this case, you would write some application or script on the server to generate the necessary HTML/CSS for you.
To make a website public, you can just rent a hosting service and a domain name at a provider - google for "web hosting providers". You will be able to upload your files using FTP protocol and manage your database (usually MySQL) over some tool (most used is PhpMyAdmin).
I'm going to simplify what happens in the background.
The server needs to be connected to internet 24/7 (since the content it's hosting is available only when the server is connected).
Optionally (but very recommended), domain records need to point to the server's IP address(es)... Let's say your server has an IP address 12.34.56.78 - when you rent a domain called "example.com", you need to set its DNS record to point to this IP address so anyone who types in "example.com" into their browser, will communicate with your server.
The server software will see that someone is trying to communicate with it, requesting "example.com" on port 80 (http) and it will return content that has set up to return for this kind of request.
Related
I'm currently working on a website A that is using one of my apis on a website B.
The website A ask the website B some informations and I was thinking that if someone use a fake dns (or put the website B URL in his hosts file), it'll be impossible for my javascript code to get these informations.
Here's my question: is it possible to prevent it or not?
there are multiple ways to prevent that, but not fully.
First, you could perform a dns lookup with javascript as described here.
As another option, you could just use the ip of your target server. But this isn't an ideal solution for production environments.
The third way that comes to mind is a proxy of your api via website A.
While all three of them are not very secure, keep in mind, that a potential user could also modify the client-side javascript code.
Also, welcome to StackOverflow!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Let me see if i can explain this properly.
I am making a website where users can save some information (In this case movie information).
I am getting all the movie data from a third part api (the movie database).
So i was wondering which of these to scenarios are best performance wise?
Send empty views to my client and have a javascript fetch the movies from TMD
API on page load and render them on to the page?
Fetch the data from TMD API render it into my view and send it to the client?
I assume that the first scenario is the best one for me, since i do not have to fetch any extra data before i send my views to my user (and this way also dont use as much bandwidth).
However i feel like the second scenario makes it easier for me to manipulate the data to how i like and want it with less code as i can just render it onto the views before sending it (This way to i would have to use more bandwidth since i have to fetch some data first, and thus send more data to my client?).
As you've articulated already, there are pros and cons to each approach.
Generally you would use a server-side request if the API credentials are not safe to make public, or if you'll be serving the same content to many clients and want to act as a cache to reduce load on the third-party API. You would also do so for data that you want to process, particularly in a proprietary manner, before serving it to a client, though that's a little more obvious.
Conversely, fetching data on the client is more common when the API request will vary based on user input or client state (e.g. cookies, such as a request to a social media API from a logged in user). The downside of this is that you tend to make many more requests to third-party APIs and you may end up exhausting a rate-limited API, resulting in delays for clients.
benefits of each:
serverside rendering
1) less data has to be sent to the client (filtering)
2) API requests can be cached, especially useful if there are request limits or if heavy computations have to be done
3) Less code at the client
clientside fetching & rendering
1) dynamic content without reloading (you can just fetch some more data)
2) you don't need a real server. A static fileserver like NGINX will be enough, no programming required at the serverside.
I want to achieve following functionality and need the help for the same:
I have one server on which there is device connected that prints some bar codes based on pre-formatted command given to it.
Currently there is one desktop application which generates the command and does the job.
Now I want to do this via web, meaning there will be one webpage (say .aspx) and I want to achieve this by javascript.
I am able to generate the pre-formatted command required for printing but I don't know how to send the command to server, whether socket tcp ip or something else.
I have tried using node.js, socket.io, json-socket etc. but nothing is working,
If javascript is a fixed requirement, then no I don't think you'll find a direct solution. You will need to create an intermediary service that will translate websocket protocol to the tcp/ip protocol your software communicates on. I found a package called Websockify that has implementations of this kind of bridge in a few different languages.
Although if you are open to using Flash on the front end, and can meet the security requirements on your backend connection, then Flash socket API could work. I believe Java applets can also manage this.
I don't believe this is possible to do from inside a web browser. If it were it would be a huge security vulnerability (think about it, you visit an attackers page and all of a sudden your printer starts printing and every shared directory on your network fills to the brim with junk data).
You could run the command on the server (node/.net/anything else...) and have the web platform talk to the server to kick the process off. But that sounds kind of like what you already have set up...
Alternately, if you can change the software on the connected device you could try to give it an HTTP endpoint which responds to POSTs.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Scenario:
I have a webserver running php, I want to be able to be able to securely send a request to a separate server running nodejs and get a response back.
The node server will never need to send anything to the webserver by itself, e.g notifications/updates. So I don't think I need the 2 way communications that websockets would provide.
PHP sends a request to node, node processes the request, sends back data (most likely in JSON), php continues with it's script using the returned data.
Problem
I own the server running node, but the webserver is out in the wild. I need a way of making sure that any requests that come in to the node server are actually from the webserver not someone/something else, and I need the request and response data to be encrypted.
I have gathered I don't want to rely on something simple like checking ip addresses, I know that the webserver and the node sever will have to both have some shared secret information/algorithms to encode data. I could have a go at implementing this myself, but I know this problem is already solved with some encryption protocol / libraries.
I'm familiar with the concepts of encryption and keys, but I have never had to implement them.
Question
What is the best way to go about this?
What kind of encryption should/can I use, that is both supported by php and nodeJs?
What would be the potential security threats, if any?
I would suggest interact between two web servers using REST APIs.
REST APIs are used in these types of implementations.
If you can build proper authentication strategy, then the communication should be secure. If you enable SSL on Node, the communication will be encrypted. You can also limit by IP addresses, hostnames, and user agent strings.
Token based authentication with SSL should be good enough security. Utilize a strategy that implements nonce, and always have the tokens expire.
Implement CSRF strategy to prevent MITM attacks.
Build a token-based strategy that relies on common encryption methods, such as:
OAuth2
WSSE on Symfony2
CSRF on Express
I'm trying to automate the process of getting my current student records at my college. In a browser the process involves typing in my college's URL, then clicking on the login link which then brings me to a https:// URLed page were I type my password and user-name in. Then from there it is one or two more links and reading some text on the page. Now, my question is, how might I go about do doing this but in an automated way, so my records would be displayed on the command line. The https:// in the URL signifies, I think, that it uses SSL are there certain libraries that can handle this? Also the 'submit' button on the login page I'm pretty sure uses JavaScript, again, are there libraries to handle this?
I'm sure I missed something or other in my question's description, so please ask if you do not understand my question or need more information.
PS. I am not well versed in Internet protocols and I am also new to Python. In fact I started studying it for this project. But, I am fluent in C and I am pretty good with C++.
Thanks in advance.
Michael,
You don't have to mimic all the actions you do in the browser.
First. There is no problem with https/ssl as long as you don't have to verify them (it seems that you don't have to), urllib2.urlopen will handle them.
Second. When you click 'Submit' browser sends a request to the server with your username, password and probably some other data. The type of that request is probably POST. As a response server will probably send you a cookie with session id. So all you need to do is to investigate the exact format of request to the server (e.g. using FireBug), and get the cookie from the server's response.
Third. Just use that cookie to navigate the pages on the site. This might help.
P.S. As you see, there is too much 'probably' word in the answer - the exact authentication process may differ from described above and you'd have to investigate it by yourself.
Roman's answer is good advice: you generally don't need to act like a real user when your script can call HTTP methods directly.
However, if you are not comfortable with reverse engineering the HTTP operations that the site requires, then an alternative would be to use Selenium, a tool for simulating interaction with web pages. Selenium is usually used by web application developers to test their applications, but it can also be used as an automatable client for an existing website.