encrypted multiple times while submitting
encryption functions getting encypted multiple times when submit button is clicked back to back
I have a function in javascript which basically converts the textarea code to encrypted format when it is submitted, now the problem is when the submit button is clicked two times, it just encypts the encypted data again and again and keep doing if i keep on clicking the submit data, how can i disable this functionality in one single function instead of changing the submit button to disable and enable later which is just too big in the code
here is my code for JS
function encypttdata(elem) {
var formID = $(elem).attr("id");
if($("#"+formID).valid()){
$.each($("textarea", "#"+formID),function(k){
var textArea= $(this).attr("id");
try{
// do encyption here and then add it to the textarea
$('#'+textArea).val(encrypted);
}
catch(e){
if(textAreaValue.length != 0) {
var encrypted = encypto algo
$(this).val(encrypted);
}
}
});
}
}ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
So here the cases:
1. add a class to all textareas which is notYetEncrypted
2. Once the code is encypted remove the above e class and add a new class named as encypted
So what happens when the double submit is done, how can i add a check which will see if its encypted once and class of encypted added, skip the encyption step.
2. what if anything changes in the textarea, how will i track that, will i change the class on some event like onpropertychange or anything.
3. do i need to add the code you shared in the try and catch both sections.
my code with your code changes will help me fix the issues i am having and be able to change properly and stop it from encyptig it double.
1. add a class to all textareas which is notYetEncrypted
2. Once the code is encypted remove the above e class and add a new class named as encypted
So what happens when the double submit is done, how can i add a check which will see if its encypted once and class of encypted added, skip the encyption step.
2. what if anything changes in the textarea, how will i track that, will i change the class on some event like onpropertychange or anything.
3. do i need to add the code you shared in the try and catch both sections.
my code with your code changes will help me fix the issues i am having and be able to change properly and stop it from encyptig it double.
Aside: The dirt simple fix for this is to...
1) Remove all Javascript encryption.
2) Run HTTPS, so all data transacted is encrypted... far stronger than any Javascript encryption...
3) Once data lands on the server side, if some sort of encryption is required, run the encryption there.
This approach makes for code which is much easier to implement + maintain.
4) If you must encrypt in the browser (shudder...) then the problem you must solve is key bounce.
If someone accidentally bounces a key (double submit or whatever action triggers the encrypt) then you have double encryption.
This means you must add some sort of guard code, as @leakim971 suggested.
1) Remove all Javascript encryption.
2) Run HTTPS, so all data transacted is encrypted... far stronger than any Javascript encryption...
3) Once data lands on the server side, if some sort of encryption is required, run the encryption there.
This approach makes for code which is much easier to implement + maintain.
4) If you must encrypt in the browser (shudder...) then the problem you must solve is key bounce.
If someone accidentally bounces a key (double submit or whatever action triggers the encrypt) then you have double encryption.
This means you must add some sort of guard code, as @leakim971 suggested.
1) So what happens when the double submit is done, how can i add a check which will see if its encrypted once and class of encrypted added, skip the encryption step.
The entire point of guard code is to protect against double submits.
2. what if anything changes in the textarea, how will i track that, will i change the class on some event like onpropertychange or anything.
This is one of the problems of trying to run this type of logic on the client/browser side, rather than server side.
Only you understand the entire context of your code, so only you can answer this question.
You'll have to determine when encrypted data has landed on the server side, then clear then add the notYetEncrypted attr again.
Likely the only reasonable way to do this is to make your code even more complex, by using an AJAX call to ensure data actually land in the server's database, as all manner of server errors (potentially 100s of different errors) can occur where data will never arrive or be logged in it's final destination.
3. do i need to add the code you shared in the try and catch both sections.
I wouldn't as this is more complexity.
The try/catch logic seems a bit... odd...
Simple pseudo code for logic...
Then have your encryption logic follow this simple test.
There seems no good reason to raise an exception here, as raising an exception implies you're going to process the exception + then somehow report an error to a visitor to takes some corrective action, which will be impossible for the visitor to take.
The entire point of guard code is to protect against double submits.
2. what if anything changes in the textarea, how will i track that, will i change the class on some event like onpropertychange or anything.
This is one of the problems of trying to run this type of logic on the client/browser side, rather than server side.
Only you understand the entire context of your code, so only you can answer this question.
You'll have to determine when encrypted data has landed on the server side, then clear then add the notYetEncrypted attr again.
Likely the only reasonable way to do this is to make your code even more complex, by using an AJAX call to ensure data actually land in the server's database, as all manner of server errors (potentially 100s of different errors) can occur where data will never arrive or be logged in it's final destination.
3. do i need to add the code you shared in the try and catch both sections.
I wouldn't as this is more complexity.
The try/catch logic seems a bit... odd...
Simple pseudo code for logic...
if (textarea.notYetEncrypted) return;Then have your encryption logic follow this simple test.
There seems no good reason to raise an exception here, as raising an exception implies you're going to process the exception + then somehow report an error to a visitor to takes some corrective action, which will be impossible for the visitor to take.
ASKER
firstly the website is already using https
and then this is a requirement by client to have text area comments encrypted because I will never do such as it adds complexity for no reason
now the code is hide and in some places it's using server and some places using client side and I have already been taking care of server side
now problem is with client side because when the submit getting clicked
I can see the encryption keeps changing
this is where I need to stop it
and that is why I asked @leakim to help me write a better code so at least double submission should avoid it accidentally
because once it is submitted and keeps on submitting will not change it
and on server side it will be fixed properly
and even if I need to edit it
it gets decrypted before I can edit it
so what I think is adding and removing a class might help but only exception is when I edit it the class will change to not encrypted again because it has to be encrypted back
and that is what I am thinking to either add in JavaScript or server side
and then this is a requirement by client to have text area comments encrypted because I will never do such as it adds complexity for no reason
now the code is hide and in some places it's using server and some places using client side and I have already been taking care of server side
now problem is with client side because when the submit getting clicked
I can see the encryption keeps changing
this is where I need to stop it
and that is why I asked @leakim to help me write a better code so at least double submission should avoid it accidentally
because once it is submitted and keeps on submitting will not change it
and on server side it will be fixed properly
and even if I need to edit it
it gets decrypted before I can edit it
so what I think is adding and removing a class might help but only exception is when I edit it the class will change to not encrypted again because it has to be encrypted back
and that is what I am thinking to either add in JavaScript or server side
1) once you encrypted the textarea, stamp it (add a class)
2) when submitting the form, encrypt textarea without stamp (class)
you already have the code for 1) and 2) in my previous comment
you own your code...
you just need to be agree with the logic
2) when submitting the form, encrypt textarea without stamp (class)
you already have the code for 1) and 2) in my previous comment
you own your code...
you just need to be agree with the logic
ASKER
can you modify your code with my code because there is a catch statement too where I think we need to add
ASKER
and even some kind of hasclass to check if it's already done when double submission done or not
ASKER
I am just considering as much as I try to understand this logic
1) Use @leakim971 guard suggestion to fix double encryption.
2) And if you're already running HTTPS, simple solution is... there's no security benefit to added encryption, so just remove all the Javascript encryption + problem is instantly fixed.
2) And if you're already running HTTPS, simple solution is... there's no security benefit to added encryption, so just remove all the Javascript encryption + problem is instantly fixed.
i would recommend you do not encrypt in place but rather encrypt and build the request on the fly.
As @skullforbrains suggested, best to just allow HTTPS to encrypt data over the wire as no encryption you can add will be better than HTTPS and can only complicate matters.
not quite. i meant encrypting in js, build the query, and submit on the fly.
i do concur using a symmetric encryption before transferring a text record over https seems weird but since this is a requirement...
i do concur using a symmetric encryption before transferring a text record over https seems weird but since this is a requirement...
ASKER
and if you can add that in function where to that would be marvellous
and I do not have to change anywhere just this function right