Using jQuery to insert data to db?

[sitheris]

Hi,

Is it possible to insert data into a database table (Oracle) using strictly JQuery, without calling some external (or embedded) jsp/php/webservice code?

Thanks

 

[tgabe213]

No. jQuery is client side only. It can post data to a web service though.

 

[commodore]

what the guy above me said and its quite simple to post to your PHP/ASP file with code like this ..

$.ajax({
		   type: "POST",
		   url: "your_php-or-asp_script.php",
		   data: "val1="+value1+"&val2="+value2,
		   success: function(msg){
			alert( "Data Saved: " + msg );
		   }
		 });

Edit: Don't forget to output a final reply in your PHP/ASP script eg. echo "1"; this is then displayed as the 'msg' variable by jQuery .

 

[sitheris]

I'm just wondering isn't this kind of a security issue though? I mean someone could see the code and execute this to insert any value (and as many rows) they want into the db right?

 

[maw]

I'm just wondering isn't this kind of a security issue though? I mean someone could see the code and execute this to insert any value (and as many rows) they want into the db right?

yes, but you should always be making sure your server-side script is properly sanitizing and validating any info it is receiving anyway. If the only info your server-side script will accept is what a normal user would enter, then it should not matter if someone tried to do nefarious stuff using your jquery call, the script should know how to handle improper input and deal with it accordingly.

 

[ShoeLace]

If you didn't use jquery you would be either posting to a different page that contains the db code or embedding it on the same page as your form.

The only information you gain you from looking at that jquery snippet is that you're using val1 and val2 as part of your query. If someone looked at your page source and saw txtUsername and txtPassword input boxes they would figure out that you're using them as part of your query too.

In other words, it's not less secure.

 

[sitheris]

Thanks for the responses all

 

[mrgstiffler]

what the guy above me said and its quite simple to post to your PHP/ASP file with code like this ..

$.ajax({
           type: "POST",
           url: "your_php-or-asp_script.php",
           data: "val1="+value1+"&val2="+value2,
           success: function(msg){
            alert( "Data Saved: " + msg );
           }
         });

Edit: Don't forget to output a final reply in your PHP/ASP script eg. echo "1"; this is then displayed as the 'msg' variable by jQuery .

Just a slight tweak to the above:

    var value1 = "foo";
    var value2 = "bar";

    $.ajax({
      url: "yourScript.php",
      type: "POST",
      dataType: 'json', // I always return JSON from my PHP scripts.
      data: {value1: value1 // I think this is quite a bit cleaner, especially with lots of values.
             value2: value2},
      success: function(json) {
        // Success functionality goes here.
      }
    });

 

[DocFaustus]

If you didn't use jquery you would be either posting to a different page that contains the db code or embedding it on the same page as your form.

The only information you gain you from looking at that jquery snippet is that you're using val1 and val2 as part of your query. If someone looked at your page source and saw txtUsername and txtPassword input boxes they would figure out that you're using them as part of your query too.

In other words, it's not less secure.

I am not sure I am following exactly what you are saying. But I do agree with your "not less secure" in a sense. Let me know if I am saying something different than you.

There should be not be a sense of security when talking about anything on the client side. Form submissions (GET and POST) and any javascript AJAX requests are all equally non-secure. Basic rule: Never trust user input... EVER

100% of all information that comes from the client side needs to be sanitized before anything is done with it. And this must happen on the server side.

Second, do everything you can to hide the true nature of your server's database. This means, don't give away the name of the database, table names, column names or how various tables are linked and or joined. For example, if you want to allow the user to perform a select on a certain column, use a different variable name (or form field name) on the client side. Don't actually use the table column name. Example: client side variable "username" could map to server side "logon_id".

Limit users access as well. If they don't need UPDATE or DELETE, then make sure the user account they are accessing through doesn't have them. You can go a step further and never let anyone directly access your database tables. Instead create specific views for them to access. This last part will actually make your life easier if you are presenting users data that spans multiple tables via complex joins or selects

 

[mrgstiffler]

I am not sure I am following exactly what you are saying. But I do agree with your "not less secure" in a sense. Let me know if I am saying something different than you.

There should be not be a sense of security when talking about anything on the client side. Form submissions (GET and POST) and any javascript AJAX requests are all equally non-secure. Basic rule: Never trust user input... EVER

100% of all information that comes from the client side needs to be sanitized before anything is done with it. And this must happen on the server side.

Second, do everything you can to hide the true nature of your server's database. This means, don't give away the name of the database, table names, column names or how various tables are linked and or joined. For example, if you want to allow the user to perform a select on a certain column, use a different variable name (or form field name) on the client side. Don't actually use the table column name. Example: client side variable "username" could map to server side "logon_id".

Limit users access as well. If they don't need UPDATE or DELETE, then make sure the user account they are accessing through doesn't have them. You can go a step further and never let anyone directly access your database tables. Instead create specific views for them to access. This last part will actually make your life easier if you are presenting users data that spans multiple tables via complex joins or selects

I kind of agree with most of this and kind of don't. I absolutely agree with sanitizing ALL user data, MULTIPLE times. If you implement this properly, the rest of the stuff doesn't really matter.

As for your last point, I 100% agree with you on views. I store all my query logic in the database using views. Makes my work SO much easier.

 

[ShoeLace]

I'm just saying it doesn't matter if you have PHP code embedded in your form page or you're using the .ajax() function to transfer information back and forth. Both of them are getting validated on the server side.

With the above example the operation sequence is basically this:

1. User sends data to my-script.php.
2. my-script.php validates the input.
3. my-script.php does whatever you need it to do.
4. my-script.php sends back the results of whatever you did as json.
5. .ajax() injects the results into whatever element you want on the HTML page on success or fail.

If you decided to not go the ajax route you would probably have an if statement checking if the submit button for the form was pressed. If it was pressed, then you would perform your validation and echo out the results in the end.

In both cases, the security is identical.