4.2Security, user rights & groupware
The essentials in 30 seconds
- WinDev's Groupware Utilisateur provides out of the box authentication, user and group management, and rights down to window and field level — a considerable gain over a custom build.
- Golden rule: least privilege — everyone gets only the rights strictly needed; think in groups (business profiles) and never store a password in plain text (hash).
- ⚠️ Interface security is not enough: hiding a button does not prevent accessing the data another way — you must also secure the data side (HFSQL Client/Serveur rights, constraints), trace sensitive operations and protect backups.
Mini-case thread — Yacine locks down his trading business rights
Yacine, a WinDev developer at an electrical equipment trading SME in Oran, must prepare the application for production. Today everyone can do everything: a storekeeper can approve a discount, a salesperson can delete an invoice. Yacine enables the Groupware Utilisateur: he creates groups that follow the real roles — salesperson, storekeeper, accountant, manager, administrator — and applies least privilege, each group getting only what it needs. He knows that hiding a button in the interface is not enough: he also secures the data side (HFSQL Client/Serveur rights) and centralizes business rules in procedures so that imports benefit from them. He traces sensitive operations (who changed what, when) for auditing, protects backups and stores passwords as hashes. He notes the reflex: an overly fine-grained rights system becomes unmanageable — therefore insecure; start simple then refine where the need is real.
Standalone case for this section: it returns in the course, the diagram, the script and the 48h challenge of section 4.2.
1. The Groupware Utilisateur
The security of a management application covers several dimensions: who can log in, who can see what, who can do what, and how the data is protected. WinDev offers the Groupware Utilisateur, an integrated module that provides out of the box authentication (identifier/password), management of users and groups, and above all the definition of rights down to windows and fields: a given group does not see this button, another has this field read-only. It is a considerable time saver compared with a custom build, and it covers the classic needs of business applications.
2. Security principles
Regardless of the tool, a few principles apply. (1) Least privilege: everyone has only the strictly necessary rights — the golden rule. (2) Never store a password in plain text: keep a hash. (3) Interface security is not enough: hiding a button does not prevent accessing the data another way — you must also secure the data side (HFSQL Client/Serveur rights, constraints). (4) Trace sensitive operations (who changed what, when), essential for auditing and disputes. (5) Encrypt what must be encrypted and protect backups: a stolen backup is the whole database stolen.
3. Groups, simplicity, legal
In practice, think in groups (business profiles) rather than person by person: arrivals, departures and role changes are handled by a simple assignment. Apply least privilege with simple rules (view / create-edit / delete / approve / administer) and add fine-grained rules only where the need is real: an overly complex rights system ends up badly administered, therefore insecure. Finally, the protection of personal data falls under legal obligations that vary by country (GDPR in Europe, local legislation elsewhere): find out about the applicable law and seek advice — this guide is not legal advice.
🔎 Concrete example — 🔎 Concrete example — Authenticate and check a right
The skeleton of an authentication and a rights check, like Yacine's:
// Authentifier l'utilisateur via le Groupware Utilisateur
SI gpwOuvre("CnxNegoce") ET gpwConnecte(sLogin, sMotDePasse) ALORS
// Contrôler un droit AVANT l'action sensible
SI gpwDroit("FACTURE", gpwSuppression) ALORS
// ... suppression de la facture autorisée ...
SINON
Info("Votre profil ne permet pas de supprimer une facture.")
FIN
SINON
Erreur("Identifiant ou mot de passe incorrect.")
FIN
gpwFerme()Reading: authentication identifies who is acting; the rights check decides whether the action is allowed — at the role level, not just the screen.
Lesson: the right is checked in the process (and on the data side), so that imports and batch processes benefit from the same controls.
Section vocabulary
- Groupware Utilisateur
- Integrated WinDev module providing out of the box authentication, user and group management, and rights down to windows and fields.
Simple example: Yacine enables the Groupware Utilisateur for his trading application.
What it is not: a custom security build, long and risky.
Reflex: out-of-the-box rights → the Groupware Utilisateur.
- Least privilege
- Everyone has only the rights strictly necessary for their work — limits damage in case of error or a compromised account.
Simple example: Yacine's storekeeper cannot approve a discount.
What it is not: giving everyone administrator rights 'to simplify'.
Reflex: just what is needed → least privilege.
- Passwords (⚠️)
- Never store a password in plain text: keep a hash.
Simple example: Yacine checks that passwords are hashed in the database.
What it is not: a plain-text password file, a major flaw.
Reflex: protect credentials → hashing.
- Data-side security
- Hiding a button is not enough: you must also secure at the data level (HFSQL Client/Serveur rights, constraints).
Simple example: Yacine defines rights on the server side, not only on screen.
What it is not: relying only on the interface to protect the data.
Reflex: real barrier → data-side security.
- Traceability
- Record who did what and when on sensitive operations, for auditing, disputes and incident diagnosis.
Simple example: Yacine logs invoice deletions.
What it is not: no trace of sensitive modifications.
Reflex: be able to audit → traceability.
In practice — In practice — Secure your application
- Set up authentication and user groups (Groupware Utilisateur) applying least privilege: everyone gets only what is needed, like Yacine.
- Never store passwords in plain text (hash) and also secure the data side (HFSQL Client/Serveur rights), not only the interface.
- Trace sensitive operations (who, what, when) for auditing and diagnosis, and encrypt sensitive exchanges and data.
- Protect backups (a stolen backup = the whole database stolen) and check your legal obligations on personal data in your country.
Step-by-step script — secure like Yacine (5 min)
1) Enable the Groupware Utilisateur and connect a first administrator. 2) Create the groups corresponding to real roles (salesperson, storekeeper, accountant, manager, administrator). 3) Assign each group the strictly necessary rights (view / create-edit / delete / approve / administer). 4) Add a rights check on a sensitive operation (invoice deletion). 5) Also secure on the HFSQL Client/Serveur side and log sensitive operations. 6) Protect backups and check your obligations regarding personal data.
Start with simple rules and refine only where the need is real: an overly fine-grained rights system becomes unmanageable, therefore insecure.
Copy-paste template — my security sheet
Groupware Utilisateur : auth + utilisateurs + groupes, droits clé en main
Moindre privilege : chacun n'a QUE le necessaire
Mots de passe : jamais en clair -> empreinte (hachage)
Interface != securite : securiser AUSSI cote DONNEES (droits HFSQL C/S)
Tracabilite : qui a modifie quoi, quand (audit, litiges)
Sauvegardes : une sauvegarde volee = toute la base volee
Donnees personnelles : obligations LEGALES variables selon les paysGroups by role
Yacine creates salesperson, storekeeper, accountant, manager and administrator, rather than person-by-person rights.
Right on an operation
Yacine checks the delete right before allowing an invoice to be deleted.
Data-side security
Yacine backs up the interface check with HFSQL Client/Serveur rights.
Audit trail
Yacine logs sensitive modifications to answer an accounting audit.
✓ Best practices
- Think in groups (business roles), not person by person.
- Secure the data side, not only the screen.
- Stay simple: an overly fine-grained rights system becomes unmanageable.
✗ Common pitfalls
- Believing that hiding a button is enough to secure things.
- Storing a password in plain text (major flaw).
- Granting administration rights 'to simplify'.
Key takeaways
- The Groupware Utilisateur provides out of the box authentication, groups and rights down to windows and fields.
- Golden rule: least privilege, and never plain-text passwords.
- ⚠️ Interface security is not enough: also secure the data side.
- Trace sensitive operations and protect backups; personal data falls under local law.
48h challenge — apply it tomorrow
Like Yacine, enable the Groupware Utilisateur on your application and create at least three groups corresponding to real business roles. Apply least privilege: check that a member of a group cannot perform an action outside their role. Add a rights check on a sensitive operation (deletion, approval) and verify that the check holds even outside the interface (data side). Finally, write in one sentence what you trace for auditing.
- I create groups by role and apply least privilege.
- I secure data at the right level, not only on screen.
- I trace sensitive operations and protect backups.
Frequently asked questions
Why is security at the interface level not enough?
Because the interface is only one path to the data: hiding a button or graying out a field prevents the normal user from acting, but does not prevent reaching the database another way — direct access, administration tool, ODBC connection, copied files, export, recovered backup, or an import from your own application that does not have the same controls. The real barrier is at the data level (HFSQL Client/Serveur rights, integrity constraints) and in centralized business rules, so that batch processes also benefit from them.
How do you manage user rights without over-complicating things?
By thinking in groups (business profiles) rather than per person, applying least privilege with simple rules, and adding fine-grained rules only where the need is real. Create groups that follow roles (salesperson, accountant, storekeeper, manager, administrator); people are attached to them, so an arrival or departure is handled with one assignment. Distinguish five essential levels: view, create-edit, delete, approve, administer. An overly fine-grained system becomes unmanageable — and chaotic administration creates flaws: complexity is the enemy of security.
Why is securing only the interface of an application not enough?