Commit Graph

54 Commits

Author SHA1 Message Date
jordi fita mas 97ac586a3b “Merge” find_user_role and login
I honestly do not remember why i thought i needed the find_user
function: it is just a select with a query that i only need in a single
place—when login.

I belive it was a missguided attempt to “write the function safer”, in
hopes that calling a function won’t have the same problems as when
querying a table, but this is fixed with the search_path, that i added.

There is no pgTAP for this, i believe.
2023-01-17 13:18:12 +01:00
jordi fita mas 8fd22672c7 Create pgcrypto extension into auth schema
Will only be used there, no need to be in public, and this way i can
limit the search_path for security definer functions.
2023-01-17 13:12:18 +01:00
jordi fita mas b63f7e7c54 Change find_user_role’s and login’s volatility to stable
According to PostgreSQL’s manual[0]:

  “STABLE indicates that the function cannot modify the database, and
   that within a single table scan it will consistently return the same
   result for the same argument values, but that its result could change
   across SQL statements.”

This definition matches both functions.  Moreover, find_user_role did
not need to be written in plpgsql, that i assume—but did not test—are
slower than sql functions.

[0]: https://www.postgresql.org/docs/14/sql-createfunction.html
2023-01-16 10:02:31 +01:00
jordi fita mas c17662ec6b Setup authentication schema and user relation
User authentication is based on PostgREST’s[0]: There is a noninherit
role, authenticator, whose function is only to switch to a different
role according to the application’s session.  Accordingly, this role has
no permission for anything.

The roles that this authentication can switch to are guest, invoicer, or
admin.  Guest is for anonymous users, when they need to login or
register; invoicers are regular users; and admin are application’s
administrators, that can change other user’s status, when they have to
be removed or have they password changed, for example.

The user relation is actually inaccessible to all roles and can only be
used through a security definer function, login, so that passwords are
not accessible from the application.

I hesitated on what to use as the user’s primary key.  The email seemed
a good candiate, because it will be used for login.  But something rubs
me the wrong way.

It is not that they can change because, despite what people on the
Internet keeps parroting, they do not need to be “immutable”, PostgreSQL
can cascade updates to foreign keys, and people do **not** change email
addresses that ofter.

What i **do** know is that email addresses should be unique in order to
be used for login and password, hovewer i had to decide what “unique”
means here, because the domain part is case insensitive, but the local
part who knows?  I made the arbitrary decision of assuming that the
whole address is case sensitive.

I have the feeling that this will bite me harder in the ass than using
it as the primary key.

[0]: https://postgrest.org/en/stable/auth.html
2023-01-13 20:30:21 +01:00