tandem
/
numerus
2
0
Fork 0
Code Issues 39 Pull Requests Packages Projects 1 Releases 1 Wiki Activity
numerus/test/check_cookie.sql

116 lines
3.5 KiB
MySQL
Raw Normal View History

Implement login cookie, its verification, and logout At first i thought that i would need to implement sessions, the ones that keep small files onto the disk, to know which user is talking to the server, but then i realized that, for now at least, i only need a very large number, plus the email address, to be used as a lookup, and that can be stored in the user table, in a separate schema. Had to change login to avoid raising exceptions when login failed because i now keep a record of login attemps, and functions are always run in a single transaction, thus the exception would prevent me to insert into login_attempt. Even if i use a separate procedure, i could not keep the records. I did not want to add a parameter to the logout function because i was afraid that it could be called from separate users. I do not know whether it is possible with the current approach, since the settings variable is also set by the same applications; time will tell.
2023-01-17 19:48:50 +00:00
-- Test check_cookie
set client_min_messages to warning;
create extension if not exists pgtap;
reset client_min_messages;
begin;
Add a function to set request settings and the role I did not like the idea that it was the Go server who should set values such as request.user or set the role, because this is mostly something that only the database wants for itself, such as when calling logout. I am also planning to use these setings for row security with the user’s id, that the Go application has no need for, but with the current approach i would need to return it from check_cookie so that it can return it back to the database when acquiring the connection. I would have used the same function to set the settings and the role, but security definer functions—obviously in retrospect—can not set the role, because then could switch to any role of the user that defined the function, not the roles they are member of. Thus, a new function. I did not want to do that every time i needed the database connection within the same request, because it would perform the same operations each time—it is the same cookie, afterall—, so new connections are request scoped and passed along in the context.
2023-01-19 12:07:32 +00:00
select plan(21);
Implement login cookie, its verification, and logout At first i thought that i would need to implement sessions, the ones that keep small files onto the disk, to know which user is talking to the server, but then i realized that, for now at least, i only need a very large number, plus the email address, to be used as a lookup, and that can be stored in the user table, in a separate schema. Had to change login to avoid raising exceptions when login failed because i now keep a record of login attemps, and functions are always run in a single transaction, thus the exception would prevent me to insert into login_attempt. Even if i use a separate procedure, i could not keep the records. I did not want to add a parameter to the logout function because i was afraid that it could be called from separate users. I do not know whether it is possible with the current approach, since the settings variable is also set by the same applications; time will tell.
2023-01-17 19:48:50 +00:00
set search_path to auth, numerus, public;
Move check_cookie to public and give access to authenticator I do not want to give access to authenticator until i know who the user is, herefore that function can not be in the numerus schema as the authenticator user can not see it.
2023-01-18 13:12:59 +00:00
select has_function('public', 'check_cookie', array ['text']);
select function_lang_is('public', 'check_cookie', array ['text'], 'plpgsql');
Add a function to set request settings and the role I did not like the idea that it was the Go server who should set values such as request.user or set the role, because this is mostly something that only the database wants for itself, such as when calling logout. I am also planning to use these setings for row security with the user’s id, that the Go application has no need for, but with the current approach i would need to return it from check_cookie so that it can return it back to the database when acquiring the connection. I would have used the same function to set the settings and the role, but security definer functions—obviously in retrospect—can not set the role, because then could switch to any role of the user that defined the function, not the roles they are member of. Thus, a new function. I did not want to do that every time i needed the database connection within the same request, because it would perform the same operations each time—it is the same cookie, afterall—, so new connections are request scoped and passed along in the context.
2023-01-19 12:07:32 +00:00
select function_returns('public', 'check_cookie', array ['text'], 'name');
Move check_cookie to public and give access to authenticator I do not want to give access to authenticator until i know who the user is, herefore that function can not be in the numerus schema as the authenticator user can not see it.
2023-01-18 13:12:59 +00:00
select is_definer('public', 'check_cookie', array ['text']);
select volatility_is('public', 'check_cookie', array ['text'], 'stable');
select function_privs_are('public', 'check_cookie', array ['text'], 'guest', array []::text[]);
select function_privs_are('public', 'check_cookie', array ['text'], 'invoicer', array []::text[]);
select function_privs_are('public', 'check_cookie', array ['text'], 'admin', array []::text[]);
select function_privs_are('public', 'check_cookie', array ['text'], 'authenticator', array ['EXECUTE']);
Implement login cookie, its verification, and logout At first i thought that i would need to implement sessions, the ones that keep small files onto the disk, to know which user is talking to the server, but then i realized that, for now at least, i only need a very large number, plus the email address, to be used as a lookup, and that can be stored in the user table, in a separate schema. Had to change login to avoid raising exceptions when login failed because i now keep a record of login attemps, and functions are always run in a single transaction, thus the exception would prevent me to insert into login_attempt. Even if i use a separate procedure, i could not keep the records. I did not want to add a parameter to the logout function because i was afraid that it could be called from separate users. I do not know whether it is possible with the current approach, since the settings variable is also set by the same applications; time will tell.
2023-01-17 19:48:50 +00:00
set client_min_messages to warning;
truncate auth."user" cascade;
reset client_min_messages;
Add a function to set request settings and the role I did not like the idea that it was the Go server who should set values such as request.user or set the role, because this is mostly something that only the database wants for itself, such as when calling logout. I am also planning to use these setings for row security with the user’s id, that the Go application has no need for, but with the current approach i would need to return it from check_cookie so that it can return it back to the database when acquiring the connection. I would have used the same function to set the settings and the role, but security definer functions—obviously in retrospect—can not set the role, because then could switch to any role of the user that defined the function, not the roles they are member of. Thus, a new function. I did not want to do that every time i needed the database connection within the same request, because it would perform the same operations each time—it is the same cookie, afterall—, so new connections are request scoped and passed along in the context.
2023-01-19 12:07:32 +00:00
insert into auth."user" (user_id, email, name, password, role, cookie, cookie_expires_at)
values (1, 'demo@tandem.blog', 'Demo', 'test', 'invoicer', '44facbb30d8a419dfd4bfbc44a4b5539d4970148dfc84bed0e', current_timestamp + interval '1 month')
, (9, 'admin@tandem.blog', 'Demo', 'test', 'admin', '12af4c88b528c2ad4222e3740496ecbc58e76e26f087657524', current_timestamp + interval '1 month')
Implement login cookie, its verification, and logout At first i thought that i would need to implement sessions, the ones that keep small files onto the disk, to know which user is talking to the server, but then i realized that, for now at least, i only need a very large number, plus the email address, to be used as a lookup, and that can be stored in the user table, in a separate schema. Had to change login to avoid raising exceptions when login failed because i now keep a record of login attemps, and functions are always run in a single transaction, thus the exception would prevent me to insert into login_attempt. Even if i use a separate procedure, i could not keep the records. I did not want to add a parameter to the logout function because i was afraid that it could be called from separate users. I do not know whether it is possible with the current approach, since the settings variable is also set by the same applications; time will tell.
2023-01-17 19:48:50 +00:00
;
Add a function to set request settings and the role I did not like the idea that it was the Go server who should set values such as request.user or set the role, because this is mostly something that only the database wants for itself, such as when calling logout. I am also planning to use these setings for row security with the user’s id, that the Go application has no need for, but with the current approach i would need to return it from check_cookie so that it can return it back to the database when acquiring the connection. I would have used the same function to set the settings and the role, but security definer functions—obviously in retrospect—can not set the role, because then could switch to any role of the user that defined the function, not the roles they are member of. Thus, a new function. I did not want to do that every time i needed the database connection within the same request, because it would perform the same operations each time—it is the same cookie, afterall—, so new connections are request scoped and passed along in the context.
2023-01-19 12:07:32 +00:00
prepare user_info as
Add user_profile view to update the profile with form Since users do not have access to the auth scheme, i had to add a view that selects only the data that they can see of themselves (i.e., no password or cookie). I wanted to use the `request.user.id` setting that i set in check_cookie, but this would be bad because anyone can change that parameter and, since the view is created by the owner, could see and *change* the values of everyone just by knowing their id. Thus, now i use the cookie instead, because it is way harder to figure out, and if you already have it you can just set to your browser and the user is fucked anyway; the database can not help here. I **am** going to use the user id in row level security policies, but not the value coming for the setting but instaed the one in the `user_profile`, since it already is “derived” from the cookie, that’s why i added that column to the view. The profile includes the language, that i do not use it yet to switch the locale, so i had to add a relation of the available languages, for constraint purposes. There is no NULL language, and instead i added the “Undefined” language, with ‘und’ tag’, to represent “do not know/use content negotiation”. The languages in that relation are the same i used to have inside locale.go, because there is no point on having options for languages i do not have the translation for, so i now configure the list of available languages user in content negotiation from that relation. Finally, i have added all font from RemixIcon because that’s what we used in the design and i am going to use quite a lot of them. There is duplication in the views; i will address that in a different commit.
2023-01-22 01:23:09 +00:00
select current_setting('request.user.id', true)::integer
, current_setting('request.user.email', true)
, current_setting('request.user.cookie', true)
;
Add a function to set request settings and the role I did not like the idea that it was the Go server who should set values such as request.user or set the role, because this is mostly something that only the database wants for itself, such as when calling logout. I am also planning to use these setings for row security with the user’s id, that the Go application has no need for, but with the current approach i would need to return it from check_cookie so that it can return it back to the database when acquiring the connection. I would have used the same function to set the settings and the role, but security definer functions—obviously in retrospect—can not set the role, because then could switch to any role of the user that defined the function, not the roles they are member of. Thus, a new function. I did not want to do that every time i needed the database connection within the same request, because it would perform the same operations each time—it is the same cookie, afterall—, so new connections are request scoped and passed along in the context.
2023-01-19 12:07:32 +00:00
select is (
check_cookie('44facbb30d8a419dfd4bfbc44a4b5539d4970148dfc84bed0e/demo@tandem.blog'),
'invoicer'::name,
Implement login cookie, its verification, and logout At first i thought that i would need to implement sessions, the ones that keep small files onto the disk, to know which user is talking to the server, but then i realized that, for now at least, i only need a very large number, plus the email address, to be used as a lookup, and that can be stored in the user table, in a separate schema. Had to change login to avoid raising exceptions when login failed because i now keep a record of login attemps, and functions are always run in a single transaction, thus the exception would prevent me to insert into login_attempt. Even if i use a separate procedure, i could not keep the records. I did not want to add a parameter to the logout function because i was afraid that it could be called from separate users. I do not know whether it is possible with the current approach, since the settings variable is also set by the same applications; time will tell.
2023-01-17 19:48:50 +00:00
'Should validate the cookie for the first user'
);
select results_eq (
Add a function to set request settings and the role I did not like the idea that it was the Go server who should set values such as request.user or set the role, because this is mostly something that only the database wants for itself, such as when calling logout. I am also planning to use these setings for row security with the user’s id, that the Go application has no need for, but with the current approach i would need to return it from check_cookie so that it can return it back to the database when acquiring the connection. I would have used the same function to set the settings and the role, but security definer functions—obviously in retrospect—can not set the role, because then could switch to any role of the user that defined the function, not the roles they are member of. Thus, a new function. I did not want to do that every time i needed the database connection within the same request, because it would perform the same operations each time—it is the same cookie, afterall—, so new connections are request scoped and passed along in the context.
2023-01-19 12:07:32 +00:00
'user_info',
Add user_profile view to update the profile with form Since users do not have access to the auth scheme, i had to add a view that selects only the data that they can see of themselves (i.e., no password or cookie). I wanted to use the `request.user.id` setting that i set in check_cookie, but this would be bad because anyone can change that parameter and, since the view is created by the owner, could see and *change* the values of everyone just by knowing their id. Thus, now i use the cookie instead, because it is way harder to figure out, and if you already have it you can just set to your browser and the user is fucked anyway; the database can not help here. I **am** going to use the user id in row level security policies, but not the value coming for the setting but instaed the one in the `user_profile`, since it already is “derived” from the cookie, that’s why i added that column to the view. The profile includes the language, that i do not use it yet to switch the locale, so i had to add a relation of the available languages, for constraint purposes. There is no NULL language, and instead i added the “Undefined” language, with ‘und’ tag’, to represent “do not know/use content negotiation”. The languages in that relation are the same i used to have inside locale.go, because there is no point on having options for languages i do not have the translation for, so i now configure the list of available languages user in content negotiation from that relation. Finally, i have added all font from RemixIcon because that’s what we used in the design and i am going to use quite a lot of them. There is duplication in the views; i will address that in a different commit.
2023-01-22 01:23:09 +00:00
$$ values (1, 'demo@tandem.blog', '44facbb30d8a419dfd4bfbc44a4b5539d4970148dfc84bed0e') $$,
Add a function to set request settings and the role I did not like the idea that it was the Go server who should set values such as request.user or set the role, because this is mostly something that only the database wants for itself, such as when calling logout. I am also planning to use these setings for row security with the user’s id, that the Go application has no need for, but with the current approach i would need to return it from check_cookie so that it can return it back to the database when acquiring the connection. I would have used the same function to set the settings and the role, but security definer functions—obviously in retrospect—can not set the role, because then could switch to any role of the user that defined the function, not the roles they are member of. Thus, a new function. I did not want to do that every time i needed the database connection within the same request, because it would perform the same operations each time—it is the same cookie, afterall—, so new connections are request scoped and passed along in the context.
2023-01-19 12:07:32 +00:00
'Should have updated the settings with the user info'
);
select is (
check_cookie('12af4c88b528c2ad4222e3740496ecbc58e76e26f087657524/admin@tandem.blog'),
'admin'::name,
Implement login cookie, its verification, and logout At first i thought that i would need to implement sessions, the ones that keep small files onto the disk, to know which user is talking to the server, but then i realized that, for now at least, i only need a very large number, plus the email address, to be used as a lookup, and that can be stored in the user table, in a separate schema. Had to change login to avoid raising exceptions when login failed because i now keep a record of login attemps, and functions are always run in a single transaction, thus the exception would prevent me to insert into login_attempt. Even if i use a separate procedure, i could not keep the records. I did not want to add a parameter to the logout function because i was afraid that it could be called from separate users. I do not know whether it is possible with the current approach, since the settings variable is also set by the same applications; time will tell.
2023-01-17 19:48:50 +00:00
'Should validate the cookie for the second user'
);
select results_eq (
Add a function to set request settings and the role I did not like the idea that it was the Go server who should set values such as request.user or set the role, because this is mostly something that only the database wants for itself, such as when calling logout. I am also planning to use these setings for row security with the user’s id, that the Go application has no need for, but with the current approach i would need to return it from check_cookie so that it can return it back to the database when acquiring the connection. I would have used the same function to set the settings and the role, but security definer functions—obviously in retrospect—can not set the role, because then could switch to any role of the user that defined the function, not the roles they are member of. Thus, a new function. I did not want to do that every time i needed the database connection within the same request, because it would perform the same operations each time—it is the same cookie, afterall—, so new connections are request scoped and passed along in the context.
2023-01-19 12:07:32 +00:00
'user_info',
Add user_profile view to update the profile with form Since users do not have access to the auth scheme, i had to add a view that selects only the data that they can see of themselves (i.e., no password or cookie). I wanted to use the `request.user.id` setting that i set in check_cookie, but this would be bad because anyone can change that parameter and, since the view is created by the owner, could see and *change* the values of everyone just by knowing their id. Thus, now i use the cookie instead, because it is way harder to figure out, and if you already have it you can just set to your browser and the user is fucked anyway; the database can not help here. I **am** going to use the user id in row level security policies, but not the value coming for the setting but instaed the one in the `user_profile`, since it already is “derived” from the cookie, that’s why i added that column to the view. The profile includes the language, that i do not use it yet to switch the locale, so i had to add a relation of the available languages, for constraint purposes. There is no NULL language, and instead i added the “Undefined” language, with ‘und’ tag’, to represent “do not know/use content negotiation”. The languages in that relation are the same i used to have inside locale.go, because there is no point on having options for languages i do not have the translation for, so i now configure the list of available languages user in content negotiation from that relation. Finally, i have added all font from RemixIcon because that’s what we used in the design and i am going to use quite a lot of them. There is duplication in the views; i will address that in a different commit.
2023-01-22 01:23:09 +00:00
$$ values (9, 'admin@tandem.blog', '12af4c88b528c2ad4222e3740496ecbc58e76e26f087657524') $$,
Add a function to set request settings and the role I did not like the idea that it was the Go server who should set values such as request.user or set the role, because this is mostly something that only the database wants for itself, such as when calling logout. I am also planning to use these setings for row security with the user’s id, that the Go application has no need for, but with the current approach i would need to return it from check_cookie so that it can return it back to the database when acquiring the connection. I would have used the same function to set the settings and the role, but security definer functions—obviously in retrospect—can not set the role, because then could switch to any role of the user that defined the function, not the roles they are member of. Thus, a new function. I did not want to do that every time i needed the database connection within the same request, because it would perform the same operations each time—it is the same cookie, afterall—, so new connections are request scoped and passed along in the context.
2023-01-19 12:07:32 +00:00
'Should have updated the settings with the other user info'
);
select is (
check_cookie('44facbb30d8a419dfd4bfbc44a4b5539d4970148dfc84bed0e/admin@tandem.blog'),
'guest'::name,
Implement login cookie, its verification, and logout At first i thought that i would need to implement sessions, the ones that keep small files onto the disk, to know which user is talking to the server, but then i realized that, for now at least, i only need a very large number, plus the email address, to be used as a lookup, and that can be stored in the user table, in a separate schema. Had to change login to avoid raising exceptions when login failed because i now keep a record of login attemps, and functions are always run in a single transaction, thus the exception would prevent me to insert into login_attempt. Even if i use a separate procedure, i could not keep the records. I did not want to add a parameter to the logout function because i was afraid that it could be called from separate users. I do not know whether it is possible with the current approach, since the settings variable is also set by the same applications; time will tell.
2023-01-17 19:48:50 +00:00
'Should only match with the correct email'
);
select results_eq (
Add a function to set request settings and the role I did not like the idea that it was the Go server who should set values such as request.user or set the role, because this is mostly something that only the database wants for itself, such as when calling logout. I am also planning to use these setings for row security with the user’s id, that the Go application has no need for, but with the current approach i would need to return it from check_cookie so that it can return it back to the database when acquiring the connection. I would have used the same function to set the settings and the role, but security definer functions—obviously in retrospect—can not set the role, because then could switch to any role of the user that defined the function, not the roles they are member of. Thus, a new function. I did not want to do that every time i needed the database connection within the same request, because it would perform the same operations each time—it is the same cookie, afterall—, so new connections are request scoped and passed along in the context.
2023-01-19 12:07:32 +00:00
'user_info',
Add user_profile view to update the profile with form Since users do not have access to the auth scheme, i had to add a view that selects only the data that they can see of themselves (i.e., no password or cookie). I wanted to use the `request.user.id` setting that i set in check_cookie, but this would be bad because anyone can change that parameter and, since the view is created by the owner, could see and *change* the values of everyone just by knowing their id. Thus, now i use the cookie instead, because it is way harder to figure out, and if you already have it you can just set to your browser and the user is fucked anyway; the database can not help here. I **am** going to use the user id in row level security policies, but not the value coming for the setting but instaed the one in the `user_profile`, since it already is “derived” from the cookie, that’s why i added that column to the view. The profile includes the language, that i do not use it yet to switch the locale, so i had to add a relation of the available languages, for constraint purposes. There is no NULL language, and instead i added the “Undefined” language, with ‘und’ tag’, to represent “do not know/use content negotiation”. The languages in that relation are the same i used to have inside locale.go, because there is no point on having options for languages i do not have the translation for, so i now configure the list of available languages user in content negotiation from that relation. Finally, i have added all font from RemixIcon because that’s what we used in the design and i am going to use quite a lot of them. There is duplication in the views; i will address that in a different commit.
2023-01-22 01:23:09 +00:00
$$ values (0, '', '') $$,
Add a function to set request settings and the role I did not like the idea that it was the Go server who should set values such as request.user or set the role, because this is mostly something that only the database wants for itself, such as when calling logout. I am also planning to use these setings for row security with the user’s id, that the Go application has no need for, but with the current approach i would need to return it from check_cookie so that it can return it back to the database when acquiring the connection. I would have used the same function to set the settings and the role, but security definer functions—obviously in retrospect—can not set the role, because then could switch to any role of the user that defined the function, not the roles they are member of. Thus, a new function. I did not want to do that every time i needed the database connection within the same request, because it would perform the same operations each time—it is the same cookie, afterall—, so new connections are request scoped and passed along in the context.
2023-01-19 12:07:32 +00:00
'Should have updated the settings with a guest user'
);
select is (
check_cookie('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/admin@tandem.blog'),
'guest'::name,
Implement login cookie, its verification, and logout At first i thought that i would need to implement sessions, the ones that keep small files onto the disk, to know which user is talking to the server, but then i realized that, for now at least, i only need a very large number, plus the email address, to be used as a lookup, and that can be stored in the user table, in a separate schema. Had to change login to avoid raising exceptions when login failed because i now keep a record of login attemps, and functions are always run in a single transaction, thus the exception would prevent me to insert into login_attempt. Even if i use a separate procedure, i could not keep the records. I did not want to add a parameter to the logout function because i was afraid that it could be called from separate users. I do not know whether it is possible with the current approach, since the settings variable is also set by the same applications; time will tell.
2023-01-17 19:48:50 +00:00
'Should only match with the correct cookie value'
);
Add a function to set request settings and the role I did not like the idea that it was the Go server who should set values such as request.user or set the role, because this is mostly something that only the database wants for itself, such as when calling logout. I am also planning to use these setings for row security with the user’s id, that the Go application has no need for, but with the current approach i would need to return it from check_cookie so that it can return it back to the database when acquiring the connection. I would have used the same function to set the settings and the role, but security definer functions—obviously in retrospect—can not set the role, because then could switch to any role of the user that defined the function, not the roles they are member of. Thus, a new function. I did not want to do that every time i needed the database connection within the same request, because it would perform the same operations each time—it is the same cookie, afterall—, so new connections are request scoped and passed along in the context.
2023-01-19 12:07:32 +00:00
select results_eq (
'user_info',
Add user_profile view to update the profile with form Since users do not have access to the auth scheme, i had to add a view that selects only the data that they can see of themselves (i.e., no password or cookie). I wanted to use the `request.user.id` setting that i set in check_cookie, but this would be bad because anyone can change that parameter and, since the view is created by the owner, could see and *change* the values of everyone just by knowing their id. Thus, now i use the cookie instead, because it is way harder to figure out, and if you already have it you can just set to your browser and the user is fucked anyway; the database can not help here. I **am** going to use the user id in row level security policies, but not the value coming for the setting but instaed the one in the `user_profile`, since it already is “derived” from the cookie, that’s why i added that column to the view. The profile includes the language, that i do not use it yet to switch the locale, so i had to add a relation of the available languages, for constraint purposes. There is no NULL language, and instead i added the “Undefined” language, with ‘und’ tag’, to represent “do not know/use content negotiation”. The languages in that relation are the same i used to have inside locale.go, because there is no point on having options for languages i do not have the translation for, so i now configure the list of available languages user in content negotiation from that relation. Finally, i have added all font from RemixIcon because that’s what we used in the design and i am going to use quite a lot of them. There is duplication in the views; i will address that in a different commit.
2023-01-22 01:23:09 +00:00
$$ values (0, '', '') $$,
Add a function to set request settings and the role I did not like the idea that it was the Go server who should set values such as request.user or set the role, because this is mostly something that only the database wants for itself, such as when calling logout. I am also planning to use these setings for row security with the user’s id, that the Go application has no need for, but with the current approach i would need to return it from check_cookie so that it can return it back to the database when acquiring the connection. I would have used the same function to set the settings and the role, but security definer functions—obviously in retrospect—can not set the role, because then could switch to any role of the user that defined the function, not the roles they are member of. Thus, a new function. I did not want to do that every time i needed the database connection within the same request, because it would perform the same operations each time—it is the same cookie, afterall—, so new connections are request scoped and passed along in the context.
2023-01-19 12:07:32 +00:00
'Should have left the settings with a guest user'
);
Implement login cookie, its verification, and logout At first i thought that i would need to implement sessions, the ones that keep small files onto the disk, to know which user is talking to the server, but then i realized that, for now at least, i only need a very large number, plus the email address, to be used as a lookup, and that can be stored in the user table, in a separate schema. Had to change login to avoid raising exceptions when login failed because i now keep a record of login attemps, and functions are always run in a single transaction, thus the exception would prevent me to insert into login_attempt. Even if i use a separate procedure, i could not keep the records. I did not want to add a parameter to the logout function because i was afraid that it could be called from separate users. I do not know whether it is possible with the current approach, since the settings variable is also set by the same applications; time will tell.
2023-01-17 19:48:50 +00:00
update "user" set cookie_expires_at = current_timestamp - interval '1 minute';
Add a function to set request settings and the role I did not like the idea that it was the Go server who should set values such as request.user or set the role, because this is mostly something that only the database wants for itself, such as when calling logout. I am also planning to use these setings for row security with the user’s id, that the Go application has no need for, but with the current approach i would need to return it from check_cookie so that it can return it back to the database when acquiring the connection. I would have used the same function to set the settings and the role, but security definer functions—obviously in retrospect—can not set the role, because then could switch to any role of the user that defined the function, not the roles they are member of. Thus, a new function. I did not want to do that every time i needed the database connection within the same request, because it would perform the same operations each time—it is the same cookie, afterall—, so new connections are request scoped and passed along in the context.
2023-01-19 12:07:32 +00:00
select is (
check_cookie('44facbb30d8a419dfd4bfbc44a4b5539d4970148dfc84bed0e/demo@tandem.blog'),
'guest'::name,
Implement login cookie, its verification, and logout At first i thought that i would need to implement sessions, the ones that keep small files onto the disk, to know which user is talking to the server, but then i realized that, for now at least, i only need a very large number, plus the email address, to be used as a lookup, and that can be stored in the user table, in a separate schema. Had to change login to avoid raising exceptions when login failed because i now keep a record of login attemps, and functions are always run in a single transaction, thus the exception would prevent me to insert into login_attempt. Even if i use a separate procedure, i could not keep the records. I did not want to add a parameter to the logout function because i was afraid that it could be called from separate users. I do not know whether it is possible with the current approach, since the settings variable is also set by the same applications; time will tell.
2023-01-17 19:48:50 +00:00
'Should not allow expired cookies'
);
select results_eq (
Add a function to set request settings and the role I did not like the idea that it was the Go server who should set values such as request.user or set the role, because this is mostly something that only the database wants for itself, such as when calling logout. I am also planning to use these setings for row security with the user’s id, that the Go application has no need for, but with the current approach i would need to return it from check_cookie so that it can return it back to the database when acquiring the connection. I would have used the same function to set the settings and the role, but security definer functions—obviously in retrospect—can not set the role, because then could switch to any role of the user that defined the function, not the roles they are member of. Thus, a new function. I did not want to do that every time i needed the database connection within the same request, because it would perform the same operations each time—it is the same cookie, afterall—, so new connections are request scoped and passed along in the context.
2023-01-19 12:07:32 +00:00
'user_info',
Add user_profile view to update the profile with form Since users do not have access to the auth scheme, i had to add a view that selects only the data that they can see of themselves (i.e., no password or cookie). I wanted to use the `request.user.id` setting that i set in check_cookie, but this would be bad because anyone can change that parameter and, since the view is created by the owner, could see and *change* the values of everyone just by knowing their id. Thus, now i use the cookie instead, because it is way harder to figure out, and if you already have it you can just set to your browser and the user is fucked anyway; the database can not help here. I **am** going to use the user id in row level security policies, but not the value coming for the setting but instaed the one in the `user_profile`, since it already is “derived” from the cookie, that’s why i added that column to the view. The profile includes the language, that i do not use it yet to switch the locale, so i had to add a relation of the available languages, for constraint purposes. There is no NULL language, and instead i added the “Undefined” language, with ‘und’ tag’, to represent “do not know/use content negotiation”. The languages in that relation are the same i used to have inside locale.go, because there is no point on having options for languages i do not have the translation for, so i now configure the list of available languages user in content negotiation from that relation. Finally, i have added all font from RemixIcon because that’s what we used in the design and i am going to use quite a lot of them. There is duplication in the views; i will address that in a different commit.
2023-01-22 01:23:09 +00:00
$$ values (0, '', '') $$,
Add a function to set request settings and the role I did not like the idea that it was the Go server who should set values such as request.user or set the role, because this is mostly something that only the database wants for itself, such as when calling logout. I am also planning to use these setings for row security with the user’s id, that the Go application has no need for, but with the current approach i would need to return it from check_cookie so that it can return it back to the database when acquiring the connection. I would have used the same function to set the settings and the role, but security definer functions—obviously in retrospect—can not set the role, because then could switch to any role of the user that defined the function, not the roles they are member of. Thus, a new function. I did not want to do that every time i needed the database connection within the same request, because it would perform the same operations each time—it is the same cookie, afterall—, so new connections are request scoped and passed along in the context.
2023-01-19 12:07:32 +00:00
'Should have left the settings with a guest user'
);
select is (
check_cookie('12af4c88b528c2ad4222e3740496ecbc58e76e26f087657524/admin@tandem.blog'),
'guest'::name,
Implement login cookie, its verification, and logout At first i thought that i would need to implement sessions, the ones that keep small files onto the disk, to know which user is talking to the server, but then i realized that, for now at least, i only need a very large number, plus the email address, to be used as a lookup, and that can be stored in the user table, in a separate schema. Had to change login to avoid raising exceptions when login failed because i now keep a record of login attemps, and functions are always run in a single transaction, thus the exception would prevent me to insert into login_attempt. Even if i use a separate procedure, i could not keep the records. I did not want to add a parameter to the logout function because i was afraid that it could be called from separate users. I do not know whether it is possible with the current approach, since the settings variable is also set by the same applications; time will tell.
2023-01-17 19:48:50 +00:00
'Should not allow expired cookied for the other user as well'
);
Add a function to set request settings and the role I did not like the idea that it was the Go server who should set values such as request.user or set the role, because this is mostly something that only the database wants for itself, such as when calling logout. I am also planning to use these setings for row security with the user’s id, that the Go application has no need for, but with the current approach i would need to return it from check_cookie so that it can return it back to the database when acquiring the connection. I would have used the same function to set the settings and the role, but security definer functions—obviously in retrospect—can not set the role, because then could switch to any role of the user that defined the function, not the roles they are member of. Thus, a new function. I did not want to do that every time i needed the database connection within the same request, because it would perform the same operations each time—it is the same cookie, afterall—, so new connections are request scoped and passed along in the context.
2023-01-19 12:07:32 +00:00
select results_eq (
'user_info',
Add user_profile view to update the profile with form Since users do not have access to the auth scheme, i had to add a view that selects only the data that they can see of themselves (i.e., no password or cookie). I wanted to use the `request.user.id` setting that i set in check_cookie, but this would be bad because anyone can change that parameter and, since the view is created by the owner, could see and *change* the values of everyone just by knowing their id. Thus, now i use the cookie instead, because it is way harder to figure out, and if you already have it you can just set to your browser and the user is fucked anyway; the database can not help here. I **am** going to use the user id in row level security policies, but not the value coming for the setting but instaed the one in the `user_profile`, since it already is “derived” from the cookie, that’s why i added that column to the view. The profile includes the language, that i do not use it yet to switch the locale, so i had to add a relation of the available languages, for constraint purposes. There is no NULL language, and instead i added the “Undefined” language, with ‘und’ tag’, to represent “do not know/use content negotiation”. The languages in that relation are the same i used to have inside locale.go, because there is no point on having options for languages i do not have the translation for, so i now configure the list of available languages user in content negotiation from that relation. Finally, i have added all font from RemixIcon because that’s what we used in the design and i am going to use quite a lot of them. There is duplication in the views; i will address that in a different commit.
2023-01-22 01:23:09 +00:00
$$ values (0, '', '') $$,
Add a function to set request settings and the role I did not like the idea that it was the Go server who should set values such as request.user or set the role, because this is mostly something that only the database wants for itself, such as when calling logout. I am also planning to use these setings for row security with the user’s id, that the Go application has no need for, but with the current approach i would need to return it from check_cookie so that it can return it back to the database when acquiring the connection. I would have used the same function to set the settings and the role, but security definer functions—obviously in retrospect—can not set the role, because then could switch to any role of the user that defined the function, not the roles they are member of. Thus, a new function. I did not want to do that every time i needed the database connection within the same request, because it would perform the same operations each time—it is the same cookie, afterall—, so new connections are request scoped and passed along in the context.
2023-01-19 12:07:32 +00:00
'Should have left the settings with a guest user'
);
Implement login cookie, its verification, and logout At first i thought that i would need to implement sessions, the ones that keep small files onto the disk, to know which user is talking to the server, but then i realized that, for now at least, i only need a very large number, plus the email address, to be used as a lookup, and that can be stored in the user table, in a separate schema. Had to change login to avoid raising exceptions when login failed because i now keep a record of login attemps, and functions are always run in a single transaction, thus the exception would prevent me to insert into login_attempt. Even if i use a separate procedure, i could not keep the records. I did not want to add a parameter to the logout function because i was afraid that it could be called from separate users. I do not know whether it is possible with the current approach, since the settings variable is also set by the same applications; time will tell.
2023-01-17 19:48:50 +00:00
select *
from finish();
rollback;