I am trying to validate that a username is unique on a registration form and would like to verify the uniqueness of the username right after the client types it as opposed to performing this server side after the form has been submitted.
Should I collect a resultSet from the database, store it in an array and then pass this along to the jsp page in the form of a bean (I am using a model 2 design so the user passes through a servlet before arriving at the jsp page)? What if the array is very large? How do I bring this data into javascript?
Alternatively, is there a way to do the query using ajax and javascript all on the client side? Maybe its possible to somehow run the query in the background?
I am really just looking for some direction because I am clueless as to what to even begin researching something like this. Is this even a smart move, performance wise?
I'd use "AJAX" for this.
Here's one approach: set up a blur() handler on the username text field of your form. When the blur() method is invoked, you post the username to the backend code; it verifies it and returns some appropriate response. You then parse the response and change the CSS class on the username text field (e.g., turning it red) -- or do whatever else visually you want to do to indicate "username in use."
Either way, you've got to get the username from the client to the server for verification; you wouldn't want any mechanism which allowed the client to directly use the DB (think security/exploits/etc).
If you're not already familiar, check out jQuery (http://jquery.com/) to make your client-side life much easier.
Related
I have a page html let's call it abc.html
There are AngularJS fields embedded in it.
I am now writing a GET and POST in scala which routes the fuzzy search arguments to the proper page on the server.
I am trying to understand the sequence in which things occur in order to implement a GET/POST requests (written in scala) which would happen when someone makes a search on the search bar on the abc.html page, and which would return elements from the database
Is it abc.html (search) --> http GET request --> backend ( AngularJS) --> Database?
In this case this would mean my http post or get request would pass in the html data model elements which would in turn hit the backend AngularJS controller page which in turn would hit the database, and the return ride would send the database results via an http request to the page?
Do I need to explicitly define my GET in terms of angular fields and the database model?
thanks
HTTP uses request-response pairs. This means you don't have to make another request to return anything to the client, you just need to write the proper response. Other than that, your idea is fundamentally right. The process would look something like this:
Type something into the search form on your HTML page
Submit the search form to your backend. This creates a GET or POST request depending on your form element's method attribute.
(At this point the browser is awaiting a response)
As the request reaches the server, your backend code can capture its data and make a query to your database.
(At this point the server is awaiting data from the database)
The database returns its results, your backend code is free to format it into a response to the client's original request.
The client receives the response and you can use your frontend code to display it to the user.
For our last week in school (finals next week) our teacher decided to give us a crash course in Perl. We talked about all the differences we would encounter if we used Perl and then we started talking about "spoofing".
We were given an HTML example where a user could input their first and last names. Of course our example already had Mickey as the first name and Mouse as the last name.
<form action="action_page.php">
First name:<br>
<input type="text" value="Mickey">
<br>
Last name:<br>
<input type="text" name="lastname" value="Mouse">
<br><br>
<input type="submit" value="Submit">
</form>
At the end when you hit submit you were redirected to a new screen that said your first name is Mickey and your last name is Mouse.
Our teacher said "spoofing" is when you change the method = get in the URL so instead of having
firstname=Mickey&lastname=Mouse
you would enter something like
firstname=baseball&lastname=bat
That would instantly alter the intended command and you would end up getting first name as baseball and lastname as bat.
This all sounds pretty straight forward, until he said he wanted us to write a program to prevent spoofing without using a post method.
Instead when a user attempts to spoof the system we're supposed to print out some anti-spoofing comment.
Unfortunately, we never really talked about spoofing aside from the examples. I've attempted to Google spoofing to see some example code, or at least understand this concept, but I haven't had much luck, or I haven't looked in the right places.
So I thought I would ask here. Can someone who is decent at Perl direct me towards basic anti-spoofing programs and content, or at least explain and show how spoofing is supposed to work.
What you need to do is to authenticate the data in the query string, and validate it when you receive it. There is a standard tool(set) for this: a cryptographic Message Authentication Code (MAC).
Basically, a MAC is a function that takes in a message (any arbitrary string) and a secret key, and outputs a random-looking token that depends, in a complicated way, on both the message and the key. Importantly, it is effectively impossible to compute a valid MAC token for a modified message without knowing the key.
To validate a query string (or some other data) with a MAC, you'd basically follow these steps:
Encode the data into a "canonical" form as a string. For an HTTP URL, you could just use the query string (and/or the entire URL) as it is, although you may wish to normalize it e.g. by %-decoding any characters that don't have to be encoded, and normalizing the case of any %-encoded values (e.g. %3f → %3F).
Alternatively, you could decode the query string into, say, an associative array, and serialize this array in a format of your choice. This can make it easier to combine parameters from multiple sources (e.g. hidden form fields), to add extra data fields (see below) and to choose which fields you want to validate.
Optionally, combine the data with any additional information you wish to associate it with, such as a user ID and/or a timestamp. (You can either transmit the timestamp explicitly, or just round it down to, say, the last hour, and check both the current and the previous timestamp when validating it.) Changing any of these values will change the MAC output, thus preventing attackers from e.g. trying to submit one user's data under another user's account.
Store a secret key (preferably, a securely generated random value of, say, 128 bits) on the server. Obviously, this secret key must be stored so that users cannot access it (e.g. by guessing the path to the config file).
Feed the canonically encoded data and the secret key into the MAC algorithm. Take the result and (if your MAC library doesn't do this for you) encode it in some convenient matter (e.g. using the URL-safe Base64 variant).
Append the encoded MAC token as an extra parameter in the URL.
When you receive the data back, remove the MAC token, feed the rest of the data back into the MAC generation code as described above, and check that the resulting MAC matches the one you received.
MAC algorithms can be constructed from cryptographic hash functions like MD5 or SHA-1/2/3. In fact, a basic MAC can be obtained simply by concatenating the secret and the message, hashing them, and using the result as the token.
For some hash functions, like SHA-3, the simple MAC construction described above is actually believed to be secure; for older hash functions, which were not explicitly designed with this use in mind, however, it's safer to use the (slightly) more complicated HMAC construction, which hashes the input twice.
Alternatively, there are also MAC algorithms, such as CMAC, which are based on block ciphers (like AES) instead of hash functions. In some cases (e.g. on embedded platforms, where a fast hash function may not be available) these may be more efficient than HMAC; for a web application, however, the choice is essentially a matter of taste.
One difference between GET and POST is that the information for the former is passed in the URL itself. That means you can type what you like in the browser's address bar -- it doesn't have to have come from an HTML form. I think that's what is meant by spoofing here.
The most obvious protection is to calculate a CRC of all the protected fields -- in this case MickeyMouse -- and put that value in a hidden field of the HTML form sent out by the server. Then, when the request comes back, calculate the CRC of the same fields and check that it matches the value of the returned hidden field.
Of course that can be circumvented if the user works out how the protection functions and adds his own calculation of the CRC of his spoofed data as well. But this should be sufficient for a proof of concept.
If you want to detect if a user has changed a parameter in the querystring of a url after a form has performed a GET action, then generate a client side hash before the form is submitted. The hash would be based on the values of the form fields, and then compared to a recalculated hash based on the current parameter values on the response page. If the hashes don't match the querystring has been tampered with.
Here's a client side Crypto library to calculate the hashes https://code.google.com/p/crypto-js/
Note this is only for educational use, and wouldn't provide enough security in the real world, as a person could also discover the hashing key by inspecting the page source and use that to generate their own hashes.
A POST method wouldn't prevent spoofing anyway. POST and GET do almost exactly the same thing - they send plain text encoded variables to a web server.
They're insanely easy to "spoof" - the point isn't the spoofing, it's that you shouldn't trust "user input" like that, ever.
I would suggest in the case of the names, it doesn't matter. So what if I fudge your web page to "pretend" I am called "baseball bat" instead?
If it's important, like for example, ensuring I can only see my test results - then you need to handle the data processing server side. One method of doing this is via session tracking - so rather than including field in a web form, I instead use a "session token".
You would 'send' me a username and password - ideally using a hash to make it impossible to 'see' as you're sending it, or in your browser history. And then I would check it against my server, to check if that hash is 'valid' by performing the same operation on the server, and comparing the two.
So perlishly:
#!/usr/bin/perl
use strict;
use warnings;
use Digest::SHA qw ( sha1_base64 );
my ( $firstname, $lastname ) = qw ( Mickey Mouse );
my $timewindow = int ( time / 300 );
my $token = sha1_base64 ( $timewindow.$firstname.$lastname );
print $token;
This produces a token that doesn't last long - it changes every 5 minutes - but it's extremely difficult to tamper with.
The reason for including the time, is to avoid replay attacks, whereby if look in your browser history, I can find "your" token and reuse it. (That's probably the next question after the "spoofing" one though :))
If you sent the parameters with the token, bear in mind that it's actually quite easy for a malicious actor to perform the same calculation themselves, and send some completely faked credentials and tokens.
This is something of a simplistic example though - because really, faked parameters shouldn't matter, because you shouldn't trust them in the first place. If 'Mickey Mouse' is valid, and 'baseball bat' isn't, then your server should detect that when processing the form, and discard the latter, which makes the whole 'form spoofing' thing irrelevant.
The question is rather narrowly phrased, so this answer might not quite address what you're asking. But as a matter of policy, if you don't want your users to tamper with your data you should not give them custody of it. Why are you relying on the query string for the user name if the server already knows it? Rely on the client for authentication and for new information, and rely on your records for any information that should stay beyond the user's control.
POST requests can be crafted almost as easily as GET requests, and cryptographic protection, even when it is secure, is only useful to the extent that the client cannot access
the encrypted data; so why transmit it back and forth?
I have an ExpressionEngine site that I'm building with Bootstrap. It's a site for volunteers to find projects to help with. On the home page I have a modal with a form for them to select when they're available and what categories of jobs they're looking for. Then they can click submit and it'll go to a new page with filtered entries.
I don't know if this is possible using the GET method or POST method on the form. I've figured out how to use the GET method and get a query string into my URL but I don't know how to use that data to filter my entries on the entries page. Or would using POST and JSON be a better option? I don't know really how to implement either so any help would be great.
Thanks a lot!
It depends on how the information you would like to show is stored.
If you are using MySQL (a common RDMS), or any other form of SQL Database for that matter, the most common way is to send your GET query string (for example) to your server, have a sever-side language (such as PHP) handle that request by accessing your database, and then echo the result. This can be done synchronously, or with AJAX.
For example, the flow of everything might look like this:
User selects an option (say, "Gardening Projects").
JavaScript converts the value of that input option to a query string and sends an HTTP request using the GET method.
The destination of this request is "filter.php" (for example).
"filter.php" access your database using an SQL query, which searches for any entries in your database, say, having a tag of "gardening".
"filter.php" echos a statement with those entries (or, better yet, returns a JSON object)
JavaScript then parses the resultant JSON object into the DOM, which displays as a bunch of links in a result area that your user can click on.
The question you have about how to handle this is very broad, so I would recommend simply doing some Google searches or looking around this site for resources that show you how to set up databases, access those databases with possibly PHP/SQL, and maybe even use AJAX to return those results, etc.
To get you started (these are in no particular order):
AJAX Tutorial
PHP - JSON encode
SQL tutorial
jQuery AJAX
I got it figured out with some help from #JoshBeam. It turns out that I was trying to make it way more complicated than it actually is. Rookie mistake. In the end I just ended up using method=get in my form and the setting the action as the page with the filtered entries. I then used php to echo the inputs into my EE channel:entries tag.
One thing I still haven't figured out is how to make it so that my query string will combine values for matching names. Currently I have checkboxes for days of the week, each with name="day" and different values for each day. If there are multiple checked, my query string becomes example.com/?day=sun&day=mon when I'd rather have it as example.com/?day=sun&mon. So if anyone has any tips on that, I'd welcome them! I also wonder if there's a way to add pipes between each value when I echo them in my EE tag so that I can have multiples - e.g. {exp:channel:entries category="1|2|3"}. But I have really yet to Google either of these questions so I'll do that.
Thanks!
I don't understand. I have searched all internet forums but found nothing helpful. I am trying to update the numberOfLikes field on my postsTable in MySql when the user clicks on the like button. I know this is done through ajax but I am only familiar with prototype ajax and none internet forums state anything about it.
Here's the flow chart
1. On "seeForums.php" user clicks on the "like" link.
2. The like link has an id that triggers the function which updates numberOfLikes on my postsTable.
Thats it. Thats all I need. But I need it in a prototype ajax format, something like this.
function processLikes()
{
new Ajax.Request(theUrl,
{
contentType:"text/HTML",
onSuccess:updateLikesMySql,
onFailure:error
onException:error,
});
}
Helps are appreciated :)
You can't do this with Javascript alone as it is client side only, you'll need to get a server side language (e.g. PHP) involved as well.
The idea is that you send an AJAX request to your PHP file along with the data that you want to update, and your PHP file will handle inserting values into the database. That PHP file would then print an output (e.g. success or failure) which would be received in your Javascript so you can act accordingly.
You should know that the nature of HTTP (web) makes it Request/Response like.
So your backend code runs on the server,
And javascript and all frontend code run on the client.
Client has no access to your database, So you can't do anything to your database with Javascript.
Best thing you can do is ask your serve with javascript to update the database,
Make a server-side script available at some URL,
Then use ajax to call that URL.
In the server-side script, do the code which updates the database.
I've done several forms that follow a similar pattern:
two interdependent form fields, let's say "street address" and "location" (lon/lat).
when user fills in one field, the other is updated via an ajax call.
(eg. if the user fills in street address, do a request to a geocode API and put the result in the location field; if the user fills in the location (eg. via a map UI), do a request to a reverse-geocode API and put the result in the address field.
No problem so far, these are easy to hook up to blur and/or focus change events.)
The problem occurs if the form is submitted before an ajax call completes. In this case one field will have a correct value and the other will be stale. The handler on the server needs to detect that this has happened and update the stale value. We can't just check for the default value because the user might have changed both fields any number of times.
There are two possible solutions I've thought of, and I don't much like either one. I'd love other suggestions.
Solution 1. Use hidden fields as flags to indicate freshness: set the value to 0 by default, reset it to 0 before the ajax request is sent, and set it to 1 when the response comes back. On the server side, check these fields and recompute any field whose freshness flag is set to 0. There is still a potential race condition here but the window is greatly narrowed. I've used this technique and it works (eg. http://fixcity.org/racks/new/). It is annoying though, as it requires more code on both client and server and is another possible source of bugs.
Solution 2. Use synchronous AJAX calls instead ("SJAX"?). Not appealing since AJAX here is just a UI convenience, it's not strictly necessary for the application to work, so I'd rather not make things feel slow - then it becomes UI *in*convenience.
Solution 3. Always do server-side postprocessing. If it's expensive, use caching to make it cheaper - eg. if the value is not stale, that means the client just made the same request via AJAX so we should have populated the cache if needed during the AJAX handler.
This one currently seems the most appealing to me, although it has two limitations:
it can't be used for things that are not safe and idempotent - eg. if the AJAX request was doing a POST; and it can't even be used for this example because we have two interdependent fields and no way to know which is correct and which is stale.
When the user presses submit, have it run a validation function that decides what state the form is in by examining the form fields and the state of the ajax call (set a flag, such as ajaxBusy).
You could enhance your AJAX call to both disable the form submit button and set a global var to to true that is checked on form submit~ That way the user can't submit the form before AJAX completes. I would add a loading graphic for UI sake.
You should validate what is submitted on server-side anyway. If both fields are related 1-1, then you can designate one of them as "master", and submit it alone, while the other one is calculated server-side.