I was wondering how do popular mail websites handle / call the serverside scripts. How do they do it differently in a way that users are not easily able to decipher which file they are calling to invoke say login authentication.
For eg: from yahoo website i did view source on login page and saw
<form method="post" action="https://login.yahoo.com/config/login?" autocomplete="" name="login_form" onsubmit="return hash2(this)">
usually action is the server side script file which is being called on submit button right? so they are redirecting to some other website on .done (i.e after authentication), but how do we know what file they calling to run the script?.. Where is the username and password. I tried a wireshark capture too, because they are using post, i won't see the username/password in the url but in wireshark i should see right?
Sorry a lame question, but was just curious as to how these big people work.
Are you merely confused about the URL https://login.yahoo.com/config/login??
Consider: A web server does not need to work with files at all. Having a URL like http://example.com/login.php is merely an extremely lazy way to map to a file on disk. Internally, the web server will receive the request as /login.php and will have to look through its configuration if there's a file login.php somewhere in a directory configured for the host example.com, execute that file and send back the results to the user. That's a complicated task.
Instead it could just receive the query for /config/login? and do something completely different with it, like... logging you in.
You're never executing files directly on a remote server. This is important. There's always a program translating URLs to executable programs or actions. This is completely arbitrary and has nothing to do with the file system.
Try searching for "pretty URLs".
The /config/login? in this case is just a entry point into the server at login.yahoo.com. It could be a HTTP handler name, and when that handler gets invoked on that webserver, it just calls into some other server side call (c++ or java or anything else)...
So its kinda hidden from you. They are (possibly) just executing a 'method' or a series of methods on the server side...which on completion return some data back to the browser via the same http handler/entry-point.
These server entry points or HTTP handlers get all the data from the browser when that form is post'ed and is forwarded to the actual handler for this call.
Search for HTTP handler modules.
Related
I have a PHP page named update_details.php?id=xyz which has a query for getting the details and updating the login time of the users.
The users have a profile page named profile.php?id=xyz. So for different users the profile page is different like profile.php?id=abc, profile.php?id=def etc. Now this profile.php has an ajax function that sends the user id to the update_details.php through ajax call so that the update_details.php can update the record.
Now for example if I have 2000 users and all of them open their profile page simultaneously. Now my question is will the update_details page be able to handle this. I mean is it one update_details.php or each update_details.php?id=abc, update_details.php?id=def etc is considered to be a seperate one.
To be more precise, when 2000 users are updating their record through 2000 ajax calls, are the calls going to one update_details.php or to the one according to their ids like update_details.php?id=abc, update_details.php?id=def etc. TIA
Okay, let's check how the request goes from the browser till it's served and the browser gets a response.
The client clicks on a link, maybe a button.
The browser makes a HTTP request and sends it to the server ( that maybe Apache, nginx, whatever you use )
The server analyzes the request, checks its rules.. Saying : I found a rule when I hit a url with .php extension, I run a php interpreter and pass it the request info..
The server spawns new process or assign the request to one of its workers ( depends on the internals of the server ).
How many concurrent php processes will run ? it depends on the web server configuration and design.
So to answer your question, each php process is running has its isolated memory segment even if they are executing the same instructions from update_details.php
Think of it like 10 workers in a factory crafting a chair following the same instruction, but each one uses a different paint color, wood type, etc..
I'm using the PHP 5.5+ password_hash() function to hash my passwords before storage in the database. So far so good.
What I am a bit uncertain of is the need of pre-hashing the password that it sent from the form to my PHP script.
Now the form submit procedure is (in short terms) done like this:
HTML file which contains the form calls the controller script in form method=".." ->
Controller script recieves the call and picks the correct function ->
function execution and storage to database.
So basically the call is sent through three files from submit to storage.
I am thinking that somewhere along the line the data could be hijacked and seen in plain view since the hashing is done in the third and final file.
Should I be worried and somehow hash the password with some JavaScript during the initial submission of the form or is it safe? The final site will most likely use an SSL certificate but still I'm not 100% sure if I am safe or not.
Your concerns about hijacking the password between controllers are superfluous :
For an attacker to hijack the password while it's passed between different controllers it would mean the attacker has to be able to read the memory of the PHP process, which would require root privileges. If the attacker has root privileges, you have a bigger problem and your solution won't save you because that same attacker can also modify the PHP files to remove your "protection".
As for hijacking the password while it's flying through the Internet, the only solution is to use HTTPS - whatever Javascript cryptography/hashing you would do is pointless since an eavesdropper is also able to alter the page while it's being transmitted and serve a modified version of it without the additional "security" you added; there are many questions about trying to secure a login form without HTTPS on Security.SE, check them out :
https://security.stackexchange.com/questions/73917/techniques-to-make-a-login-page-safe-without-using-ssl
https://security.stackexchange.com/questions/37655/build-a-secure-channel-without-ssl-tls
https://security.stackexchange.com/questions/41845/login-security-without-ssl
https://security.stackexchange.com/questions/8924/what-is-the-best-way-of-securing-a-website-logon-without-ssl-or-preshared-keys
I'm trying to build a single page app with backbone.js on front end and node.js/express as server, I want to have a base HTML file for the root, and then when user navigates to any path such as
mydomain.com/foo/bar
I want to be able to handle that path on the client side by javascript instead of making a round trip to server. I am reading about backbone routing and HTML5 push state. In this article he describes push state like this,
In fact, PushState is really nothing more than a standard API for JavaScript, that allows us to manipulate the browser history by “push”ing full URLs into the browser’s URL without making a round trip to the server, and respond to changes in the URL with Javascript – all without the use of URL hash fragments.
but when I use push state it does actually makes a server request and expects server to deliver contents under /foo/bar . I don't understand how I can avoid that.
Now let's assume that even with push state, your client is going to make a server request under mydomain.com/foo/bar when you visit this URL directly. In that case, since I'm serving the default HTML file, and this default HTML file has links to scripts in it:
<script type="text/javascript" src="/scripts/myscript.js" ></script>
When this HTML loads, it starts looking for scripts under /foo directory instead of root since the server was requested under /foo which obviously does not exist. How do I fix this?
I'm really confused at this point. I'd like to know how URL routing is usually done in a single page application. Any help will be greatly appreciated. You can also refer to this other question I have posted about the same issue: Backbone Router : Get rid of # in the URL
The solution you're trying to implement is very interesting but not that simple. When your server gets a request to mydomain.com/foo/bar, you should redirect to your root with some parameter that the frontend (JavaScript) app can pick-up to know what the original request was for. For example:
Client sends GET http://mydomain.com/foo/bar
Server redirects (responds 302 with Location header set) to http://mydomain.com/#!/foo/bar
Your SPA is loaded in the browser, and on startup you check for the hash and find #!/foo/bar, so you remove the hash and trigger the /foo/bar route (that's a push-state). Your resulting URL is again http://mydomain.com/foo/bar: the original URL the user browsed to.
Grooveshark does something similar to this, though it actually responds with a page to the request sent in 1., which does the hash replacement in the client and then sends another request to the server. It looks unnecessary to me, maybe I'm overlooking something.
I am trying to make an html app for local use, consisting of an HTML page using Google Maps API V3, a SQLite database, and a SimpleHTTPServer script.
The workflow is the following:
User starts the server and opens the page, which contains a map with a set of markers, and a form with filters similar to those of Google Fusion Tables;
User interacts with form, which sets some parameters for a query;
When the user clicks "Submit", page sends a request to HTTPServer, whose request handler queries the SQLite database and returns the result as JSON/JSONP/something-else;
Some function takes back the data and map is updated;
My doubts are more conceptual than anything else, and specifically I would like to know (how/where to look for):
How should I send a request for the server in javascript, and how to listen back to it?
How should the server send data to the request, in order to update its value instead of refreshing the page?
Sorry if my questions seem obvious, but HTTP is something very new to me, and so is client-server communication.
Thanks for reading!
I think you can use CGIHTTPServer.
ref:
http://pydoc.org/2.5.1/CGIHTTPServer.html
Q:How should I send a request for the server in javascript, and how to listen back to it
A:Please google "ajax". "jquery" is one of the most convenient javascript library for ajax.
Q:How should the server send data to the request
A:just use "print" in python script which is called by CGIHTTPServer.
In this case, the output of "print" will be the response to http client(web browser).
In the script mentioned above, you should extract request parameter sent by http client,
with "do_Get()" or do_Post() function.
i am using gwt.
i need to check some input data.
all checking functions are located in PHP server check.php
i am not using javascript checking executed from locally.
all i am doing is to send user input to server by ajax and validate in that place
and error message comes from server to client's gwt widget.
is it best approach??
i can do all checking from locally.but not doing.because server side is importent.
all checks must be resides in server so i am doing all checking from server.
if i do check locally and serverside two times ,then will it be best approach??
What you'll want to do is:
Use this account the next time you come back, or any of the others you've created, instead of creating an account each time you come to the site. Avoid this mess.
Create a .php page that accepts JSON-encoded data that you'd like to verify, and respond with some text like "OK" if it's valid. (I'm no PHP expert, but I'm sure there are plenty of them here)
Use GWT's RequestBuilder to send this data to the .php page, and call the RequestCallback's Response's getText() method. Check if the text is "OK" -- if so, the result is valid!
If you need more detail on any of the specifics, just let me know and I'll edit to clear things up.
Generally I agree with Jason (especially the with the first point :D).
I'd like to add that you should do validation on the client side first. Why? Because it allows you to weed out some obviously wrong inputs => less load on the server. But never accept the values from the client, just because your JS code said so - the general rule is to never trust the client side (because, well, it's the client side and the client can change the way your code works).
So in summary, I usually take these steps in my apps, they offer security and lower the load on your server, but may require a bit more work to write and maintain (especially if your client side and server side use different languages):
Validate input client side. If it doesn't pass, don't bother sending it to the server, just show an appropriate message.
If it does pass, send it to the server, but you must rerun the validation on the server side too.
If the server side validations report an error, send it back in some form (JSON with the error message and/or error code, set a HTTP response code, etc).