zeroCode gives you the option to implement security in a generated site at multiple levels – you can choose the level to be applied to your site based on the database structures you have included. The three major types of security zeroCode can include in your site are the following:   The first type of security is login security, where you can create a login page that allows users into your site only if they have a valid username/password recorded in a table in your database. Once into your site, a user can access all pages and functions in the site, with no restriction. To generate a site with this type of security, you must include in your schema a table that has at least two columns – one that carries valid user IDs and one that carries a password for each such user ID. If a non-logged-in user attempts to access a URL that is protected by your login, s/he will be redirected to the login page.     The second type of security is at a page level, where you can choose to restrict users to specific pages in your site. This implies a high degree of function-level security too, since each function on a page is a separate page by itself. For example, the ability to add an order when looking at a list of orders take the user to a separate page – you can control usage such that, while a given user can see the list of orders, s/he cannot add one or delete one. To implement this type of security, your database schema must include at least three tables – one where you record valid user IDs and passwords (as in the login type security mechanism), one that records a list of the pages in the site and a linking table between to two, where you tie specific users to a given list of page. A more advanced mechanism would be to implement group-level security by adding a table of user groups and another one linking users to groups. In that case, when generating a site, you would. choose to tie the security mechanism to your Groups table, thereby giving yourself the option of classifying users into various groups and then assigning permissions to groups. Implement this option from zDE "Advanced" tab during site generation. If you haven't enabled this option at the time of site creation, you can choose the Standard UDMs option in zDE and enable this option while recreating the site. The third type of security is data-based security, where you can restrict the data shown in a given page by user ID, group ID or some such identifier. This restriction can be implemented on each UDM via an appropriate predicate. zeroCode  applications provide you enhanced security by making it cookie-based. The default site generated by you uses a cookie whose value is a magic string -- the key generated by Apache Jserv, which is based on the current time and a random-number generator. There is no other cookie used by the generated site (unless, of course, you introduce one). The result is that the cookie is meaningful only within the context of the zeroCode application. A hacker cannot just snarf up the cookie and attempt to interpret it, because it has no meaning outside the context of the Java app and the zeroCode runtime database. This is in contrast with many typical commercial sites, that use things such as the user's login/password combination or e-mail address in the cookie (or encrypted versions thereof), thus enabling a cracker to use the cookie-stealing approach. To know more about this click here.