Is there authentication for almost everyone (database)?

Question

By checking at the end of the document, I mean that during the triggers, CHECK, Procedure (Insert, Update, Delete), etc. How practical or necessary , now that most of these validations are handled strictly in the interface. How many internal checks are suitable for the program? Should small things be excluded from the internal audit?

For example: Suppose we have an age barrier for people to enter data. This can be done in the background using triggers or checking in the age column. It can also be performed in an interface. Do I need to have an internal check when there is strict age confirmation in the interface?

Answer 1

This is a conceptual question. In general, modern programs are built in 3 layers:

• Presentation
• Business logic
• Database

As a rule, Level 1 can choose to check all the input data in a modern application, providing the user with quick feedback about possible problems (for example, the JS pop-up message "this is not a valid email address").

Level 2 must always perform a full audit. This is the gateway to the server, and it can check complex relational constraints. This ensures that no corrupted data can enter the database in any way that is validated against the limitations of the application. These restrictions are more complicated than you can check in the database in any case (for example, the bank account number here in the Netherlands should be from 3 to 7 numbers, or 9 or 10 and correspond to the value to check the check digit ).

Level 3 can perform a check. If there is only one “client”, this is not a necessity in itself, if there is more (especially if there are “less trusted” users of the same database), it must also be in the database. If the application is critical, it is recommended that you also perform a full check in the database using triggers and restrictions, just to have double protection against errors in the business logic. The task of the database is to ensure its integrity, and not compliance with certain business rules.

There are no clear answers to this question, it depends on what your application does and how important it is. In the banking application - check all 3 levels. In an online forum, check only where necessary and serve additional users with performance benefits.

Answer 2

This can help:

• Authentication on the front side (interface) is intended to help with data entry and conflict messages. This ensures that the user is able to freely enter data; and minimizes the backstop required to verify correctness.

• Application level checking is designed to test business logic. The values ​​are correct, but do they make sense. This is the kind of test that you are here, and most of your efforts should be in this area.

• Databases are not checked. They provide data restriction methods, and their scope should provide referential integrity . Referential integrity ensures that your queries (especially crosstabs) work as expected. Just as no database server will stop you from entering 4000 in a numeric column, there should also be no place to check 40, since this does not affect data integrity. However, ensuring that the deleted row does not leave orphans is a referential integrity and must be run at the database level.

Answer 3

final checks are needed!

if the front end uses JavaScript validation and the user disables JavaScript in the browser, the validation is complete. Therefore, there is a need for authentication.

Answer 4

Put contretints in your database. This is NOT a business validation, rather like data validation, for example, foreign key constraints, or make sure your primary keys are unique. This ensures that your data is consistent.

The validation you are talking about is a business check, and such a check should be at the business level, for example in your domain, and should be the main source for the check. If these rules change, you change them at the business level, and all your customers are immediately affected.

In the user interface, you can / must also perform basic introductory checks - for example, checking required fields or valid email addresses; and updating or disabling user interface controls based on this. I would say that this is a validation that does not change (a lot).

Answer 5

Old answer: it depends.

It really depends on your needs. If users will modify the database directly, I would say that you absolutely need to limit your database. However, a large number of databases are modified only by the web application. Although you definitely need server-side validation in the web application itself, since users can crawl your web pages, you may not need database restrictions.

You should still do client-side validation as a convenience to the client.

Answer 6

If you are concerned about security, everything should be checked on the server so that someone does not create an alternative client to access your database. The front end is also necessary, as it increases efficiency and prevents access to the server using inadequate data.