Sharing backend and frontend input validation The Next CEO of Stack OverflowValidate decimal numbers in JavaScript - IsNumeric()How to validate an email address in JavaScript?A comprehensive regex for phone number validation(Built-in) way in JavaScript to check if a string is a valid numberHow to validate an email address using a regular expression?What is the maximum length of a valid email address?Disable/enable an input with jQuery?Best way to share a js object between a Typescript frontend and NodeJs backendUnified frontend side and backend side forms validationhow to share code between Webpack build and NodeJS server process?
If the heap is initialized for security, then why is the stack uninitialized?
Why do remote companies require working in the US?
Has this building technique been used in an official set?
How did the Bene Gesserit know how to make a Kwisatz Haderach?
Novel about a guy who is possessed by the divine essence and the world ends?
Is it ever safe to open a suspicious html file (e.g. email attachment)?
Contours of a clandestine nature
Limits on contract work without pre-agreed price/contract (UK)
Can you replace a racial trait cantrip when leveling up?
How do we know the LHC results are robust?
What is the purpose of the Evocation wizard's Potent Cantrip feature?
Why am I allowed to create multiple unique pointers from a single object?
Why is the US ranked as #45 in Press Freedom ratings, despite its extremely permissive free speech laws?
Won the lottery - how do I keep the money?
Why has the US not been more assertive in confronting Russia in recent years?
What's the best way to handle refactoring a big file?
What does "Its cash flow is deeply negative" mean?
Is "for causing autism in X" grammatical?
Why do we use the plural of movies in this phrase "We went to the movies last night."?
Inappropriate reference requests from Journal reviewers
Interfacing a button to MCU (and PC) with 50m long cable
How do I make a variable always equal to the result of some calculations?
What can we do to stop prior company from asking us questions?
Would this house-rule that treats advantage as a +1 to the roll instead (and disadvantage as -1) and allows them to stack be balanced?
Sharing backend and frontend input validation
The Next CEO of Stack OverflowValidate decimal numbers in JavaScript - IsNumeric()How to validate an email address in JavaScript?A comprehensive regex for phone number validation(Built-in) way in JavaScript to check if a string is a valid numberHow to validate an email address using a regular expression?What is the maximum length of a valid email address?Disable/enable an input with jQuery?Best way to share a js object between a Typescript frontend and NodeJs backendUnified frontend side and backend side forms validationhow to share code between Webpack build and NodeJS server process?
I want to share input validation because:
- User experience in frontend, instantly tells the user if the input is good/wrong
- Security concerns in backend, even if the user bypass the frontend javascript, a user cannot mess with the RESTful API
- Also javascript in frontend is always conditional to the browser interpreting it and cannot be trusted
What is the best way to share input validation in a full javascript web app (frontend: react, backend: nodejs)?
The solution I am thinking of is creating a validator module with all my javascript validators at the root of my codebase:
- If on localhost, both environments use this module to validate input.
- If in production/preprod, my deployment script copy the module in both frontend and backend before deploying.
- Import code would look like this each time I try to validate an input:
const validator = process.env.ENV === 'local' ? require('../../validator') : require('/validator')
Is there any other widely accepted method to do this (I guess it is a very common problem but I didn't find similar issues)? If not, is my method correct?
EDIT:
Takeaways from answers and implementation:
- Implementation works and is a good way to take advantage of a fullstack javascript app
- It creates some complexity and you need to be careful not to implement libraries/javascript methods that won't behave the same between two very different environments (on a client browser and on a nodejs backend). Thus I won't be using any third-party library and only vanilla javascript in my validator
- If you want to avoid bugs in production, you shall always deploy both in frontend and backend each time you modify your
validator
module and test in both environments
javascript node.js reactjs validation
add a comment |
I want to share input validation because:
- User experience in frontend, instantly tells the user if the input is good/wrong
- Security concerns in backend, even if the user bypass the frontend javascript, a user cannot mess with the RESTful API
- Also javascript in frontend is always conditional to the browser interpreting it and cannot be trusted
What is the best way to share input validation in a full javascript web app (frontend: react, backend: nodejs)?
The solution I am thinking of is creating a validator module with all my javascript validators at the root of my codebase:
- If on localhost, both environments use this module to validate input.
- If in production/preprod, my deployment script copy the module in both frontend and backend before deploying.
- Import code would look like this each time I try to validate an input:
const validator = process.env.ENV === 'local' ? require('../../validator') : require('/validator')
Is there any other widely accepted method to do this (I guess it is a very common problem but I didn't find similar issues)? If not, is my method correct?
EDIT:
Takeaways from answers and implementation:
- Implementation works and is a good way to take advantage of a fullstack javascript app
- It creates some complexity and you need to be careful not to implement libraries/javascript methods that won't behave the same between two very different environments (on a client browser and on a nodejs backend). Thus I won't be using any third-party library and only vanilla javascript in my validator
- If you want to avoid bugs in production, you shall always deploy both in frontend and backend each time you modify your
validator
module and test in both environments
javascript node.js reactjs validation
2
You are correct in wanting to validate in both front end and back end. How you do that is up to you, but your solution could work if your validation is a module of some sort. I would argue you need different validation for FE vs BE, as you have different goals. FE - user journey, not allowing input that will fail / error. BE - not allowing data will break / harm system, and FE+BE - ensuring data is 'valid' (i.e. phone number is a phone number, etc.).
– Liam MacDonald
Mar 7 at 15:06
But sharing the code would be extremely useful. A user with an up to date browser not trying to bypass the frontend validation would always get his errors before submitting its input. So I would at least need a backend validation that is as stringent as my frontend, and then I can add some custom validation in backend. Sharing it would save a lot of time, avoid duplicate code, and synchronise backend and frontend teams when they change inputs validation. Thanks for raising the interesting difference between valid and harmful data
– Quentin C
Mar 7 at 15:16
add a comment |
I want to share input validation because:
- User experience in frontend, instantly tells the user if the input is good/wrong
- Security concerns in backend, even if the user bypass the frontend javascript, a user cannot mess with the RESTful API
- Also javascript in frontend is always conditional to the browser interpreting it and cannot be trusted
What is the best way to share input validation in a full javascript web app (frontend: react, backend: nodejs)?
The solution I am thinking of is creating a validator module with all my javascript validators at the root of my codebase:
- If on localhost, both environments use this module to validate input.
- If in production/preprod, my deployment script copy the module in both frontend and backend before deploying.
- Import code would look like this each time I try to validate an input:
const validator = process.env.ENV === 'local' ? require('../../validator') : require('/validator')
Is there any other widely accepted method to do this (I guess it is a very common problem but I didn't find similar issues)? If not, is my method correct?
EDIT:
Takeaways from answers and implementation:
- Implementation works and is a good way to take advantage of a fullstack javascript app
- It creates some complexity and you need to be careful not to implement libraries/javascript methods that won't behave the same between two very different environments (on a client browser and on a nodejs backend). Thus I won't be using any third-party library and only vanilla javascript in my validator
- If you want to avoid bugs in production, you shall always deploy both in frontend and backend each time you modify your
validator
module and test in both environments
javascript node.js reactjs validation
I want to share input validation because:
- User experience in frontend, instantly tells the user if the input is good/wrong
- Security concerns in backend, even if the user bypass the frontend javascript, a user cannot mess with the RESTful API
- Also javascript in frontend is always conditional to the browser interpreting it and cannot be trusted
What is the best way to share input validation in a full javascript web app (frontend: react, backend: nodejs)?
The solution I am thinking of is creating a validator module with all my javascript validators at the root of my codebase:
- If on localhost, both environments use this module to validate input.
- If in production/preprod, my deployment script copy the module in both frontend and backend before deploying.
- Import code would look like this each time I try to validate an input:
const validator = process.env.ENV === 'local' ? require('../../validator') : require('/validator')
Is there any other widely accepted method to do this (I guess it is a very common problem but I didn't find similar issues)? If not, is my method correct?
EDIT:
Takeaways from answers and implementation:
- Implementation works and is a good way to take advantage of a fullstack javascript app
- It creates some complexity and you need to be careful not to implement libraries/javascript methods that won't behave the same between two very different environments (on a client browser and on a nodejs backend). Thus I won't be using any third-party library and only vanilla javascript in my validator
- If you want to avoid bugs in production, you shall always deploy both in frontend and backend each time you modify your
validator
module and test in both environments
javascript node.js reactjs validation
javascript node.js reactjs validation
edited Mar 19 at 16:30
Quentin C
asked Mar 7 at 14:54
Quentin CQuentin C
22810
22810
2
You are correct in wanting to validate in both front end and back end. How you do that is up to you, but your solution could work if your validation is a module of some sort. I would argue you need different validation for FE vs BE, as you have different goals. FE - user journey, not allowing input that will fail / error. BE - not allowing data will break / harm system, and FE+BE - ensuring data is 'valid' (i.e. phone number is a phone number, etc.).
– Liam MacDonald
Mar 7 at 15:06
But sharing the code would be extremely useful. A user with an up to date browser not trying to bypass the frontend validation would always get his errors before submitting its input. So I would at least need a backend validation that is as stringent as my frontend, and then I can add some custom validation in backend. Sharing it would save a lot of time, avoid duplicate code, and synchronise backend and frontend teams when they change inputs validation. Thanks for raising the interesting difference between valid and harmful data
– Quentin C
Mar 7 at 15:16
add a comment |
2
You are correct in wanting to validate in both front end and back end. How you do that is up to you, but your solution could work if your validation is a module of some sort. I would argue you need different validation for FE vs BE, as you have different goals. FE - user journey, not allowing input that will fail / error. BE - not allowing data will break / harm system, and FE+BE - ensuring data is 'valid' (i.e. phone number is a phone number, etc.).
– Liam MacDonald
Mar 7 at 15:06
But sharing the code would be extremely useful. A user with an up to date browser not trying to bypass the frontend validation would always get his errors before submitting its input. So I would at least need a backend validation that is as stringent as my frontend, and then I can add some custom validation in backend. Sharing it would save a lot of time, avoid duplicate code, and synchronise backend and frontend teams when they change inputs validation. Thanks for raising the interesting difference between valid and harmful data
– Quentin C
Mar 7 at 15:16
2
2
You are correct in wanting to validate in both front end and back end. How you do that is up to you, but your solution could work if your validation is a module of some sort. I would argue you need different validation for FE vs BE, as you have different goals. FE - user journey, not allowing input that will fail / error. BE - not allowing data will break / harm system, and FE+BE - ensuring data is 'valid' (i.e. phone number is a phone number, etc.).
– Liam MacDonald
Mar 7 at 15:06
You are correct in wanting to validate in both front end and back end. How you do that is up to you, but your solution could work if your validation is a module of some sort. I would argue you need different validation for FE vs BE, as you have different goals. FE - user journey, not allowing input that will fail / error. BE - not allowing data will break / harm system, and FE+BE - ensuring data is 'valid' (i.e. phone number is a phone number, etc.).
– Liam MacDonald
Mar 7 at 15:06
But sharing the code would be extremely useful. A user with an up to date browser not trying to bypass the frontend validation would always get his errors before submitting its input. So I would at least need a backend validation that is as stringent as my frontend, and then I can add some custom validation in backend. Sharing it would save a lot of time, avoid duplicate code, and synchronise backend and frontend teams when they change inputs validation. Thanks for raising the interesting difference between valid and harmful data
– Quentin C
Mar 7 at 15:16
But sharing the code would be extremely useful. A user with an up to date browser not trying to bypass the frontend validation would always get his errors before submitting its input. So I would at least need a backend validation that is as stringent as my frontend, and then I can add some custom validation in backend. Sharing it would save a lot of time, avoid duplicate code, and synchronise backend and frontend teams when they change inputs validation. Thanks for raising the interesting difference between valid and harmful data
– Quentin C
Mar 7 at 15:16
add a comment |
2 Answers
2
active
oldest
votes
It is a good practice to use validations as a module but you should consider what would happen if for some reason you will have/want to change the back-end tech to something that is not Javascript like node.
In case you are going to implement it - you will have a dependency of the client and server on this module and you'll have to maintain different versions of this module or deploy client code and server code any time you have a validation change - which leads to some complexity you should take into your consideration as well .
add a comment |
Usually you would make simple validations on front-end and more complex validation on the backend
For example: validate if e-mail with regex on front-end, send a simple mail to confirm existence of that email
More complex often means that you can at least build upon the simple one. So that's why I would like to duplicate the frontend validation with backend. It does not imply that I am not doing custom validation in backend. The resulting code in backend may not be optimised following this method, but I am more looking for extra safety + frontend/backend synchronisation than extra performance here.
– Quentin C
Mar 7 at 15:25
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55046707%2fsharing-backend-and-frontend-input-validation%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
It is a good practice to use validations as a module but you should consider what would happen if for some reason you will have/want to change the back-end tech to something that is not Javascript like node.
In case you are going to implement it - you will have a dependency of the client and server on this module and you'll have to maintain different versions of this module or deploy client code and server code any time you have a validation change - which leads to some complexity you should take into your consideration as well .
add a comment |
It is a good practice to use validations as a module but you should consider what would happen if for some reason you will have/want to change the back-end tech to something that is not Javascript like node.
In case you are going to implement it - you will have a dependency of the client and server on this module and you'll have to maintain different versions of this module or deploy client code and server code any time you have a validation change - which leads to some complexity you should take into your consideration as well .
add a comment |
It is a good practice to use validations as a module but you should consider what would happen if for some reason you will have/want to change the back-end tech to something that is not Javascript like node.
In case you are going to implement it - you will have a dependency of the client and server on this module and you'll have to maintain different versions of this module or deploy client code and server code any time you have a validation change - which leads to some complexity you should take into your consideration as well .
It is a good practice to use validations as a module but you should consider what would happen if for some reason you will have/want to change the back-end tech to something that is not Javascript like node.
In case you are going to implement it - you will have a dependency of the client and server on this module and you'll have to maintain different versions of this module or deploy client code and server code any time you have a validation change - which leads to some complexity you should take into your consideration as well .
answered Mar 7 at 15:27
EladBashEladBash
716
716
add a comment |
add a comment |
Usually you would make simple validations on front-end and more complex validation on the backend
For example: validate if e-mail with regex on front-end, send a simple mail to confirm existence of that email
More complex often means that you can at least build upon the simple one. So that's why I would like to duplicate the frontend validation with backend. It does not imply that I am not doing custom validation in backend. The resulting code in backend may not be optimised following this method, but I am more looking for extra safety + frontend/backend synchronisation than extra performance here.
– Quentin C
Mar 7 at 15:25
add a comment |
Usually you would make simple validations on front-end and more complex validation on the backend
For example: validate if e-mail with regex on front-end, send a simple mail to confirm existence of that email
More complex often means that you can at least build upon the simple one. So that's why I would like to duplicate the frontend validation with backend. It does not imply that I am not doing custom validation in backend. The resulting code in backend may not be optimised following this method, but I am more looking for extra safety + frontend/backend synchronisation than extra performance here.
– Quentin C
Mar 7 at 15:25
add a comment |
Usually you would make simple validations on front-end and more complex validation on the backend
For example: validate if e-mail with regex on front-end, send a simple mail to confirm existence of that email
Usually you would make simple validations on front-end and more complex validation on the backend
For example: validate if e-mail with regex on front-end, send a simple mail to confirm existence of that email
answered Mar 7 at 15:08
koFTTkoFTT
293
293
More complex often means that you can at least build upon the simple one. So that's why I would like to duplicate the frontend validation with backend. It does not imply that I am not doing custom validation in backend. The resulting code in backend may not be optimised following this method, but I am more looking for extra safety + frontend/backend synchronisation than extra performance here.
– Quentin C
Mar 7 at 15:25
add a comment |
More complex often means that you can at least build upon the simple one. So that's why I would like to duplicate the frontend validation with backend. It does not imply that I am not doing custom validation in backend. The resulting code in backend may not be optimised following this method, but I am more looking for extra safety + frontend/backend synchronisation than extra performance here.
– Quentin C
Mar 7 at 15:25
More complex often means that you can at least build upon the simple one. So that's why I would like to duplicate the frontend validation with backend. It does not imply that I am not doing custom validation in backend. The resulting code in backend may not be optimised following this method, but I am more looking for extra safety + frontend/backend synchronisation than extra performance here.
– Quentin C
Mar 7 at 15:25
More complex often means that you can at least build upon the simple one. So that's why I would like to duplicate the frontend validation with backend. It does not imply that I am not doing custom validation in backend. The resulting code in backend may not be optimised following this method, but I am more looking for extra safety + frontend/backend synchronisation than extra performance here.
– Quentin C
Mar 7 at 15:25
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55046707%2fsharing-backend-and-frontend-input-validation%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
You are correct in wanting to validate in both front end and back end. How you do that is up to you, but your solution could work if your validation is a module of some sort. I would argue you need different validation for FE vs BE, as you have different goals. FE - user journey, not allowing input that will fail / error. BE - not allowing data will break / harm system, and FE+BE - ensuring data is 'valid' (i.e. phone number is a phone number, etc.).
– Liam MacDonald
Mar 7 at 15:06
But sharing the code would be extremely useful. A user with an up to date browser not trying to bypass the frontend validation would always get his errors before submitting its input. So I would at least need a backend validation that is as stringent as my frontend, and then I can add some custom validation in backend. Sharing it would save a lot of time, avoid duplicate code, and synchronise backend and frontend teams when they change inputs validation. Thanks for raising the interesting difference between valid and harmful data
– Quentin C
Mar 7 at 15:16