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

77 lines
2.5 KiB
MySQL
Raw Normal View History

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
-- Test set_cookie
set client_min_messages to warning;
create extension if not exists pgtap;
reset client_min_messages;
begin;
select plan(15);
set search_path to auth, numerus, public;
select has_function('public', 'set_cookie', array ['text']);
select function_lang_is('public', 'set_cookie', array ['text'], 'sql');
select function_returns('public', 'set_cookie', array ['text'], 'void');
select isnt_definer('public', 'set_cookie', array ['text']);
select volatility_is('public', 'set_cookie', array ['text'], 'stable');
select function_privs_are('public', 'set_cookie', array ['text'], 'guest', array []::text[]);
select function_privs_are('public', 'set_cookie', array ['text'], 'invoicer', array []::text[]);
select function_privs_are('public', 'set_cookie', array ['text'], 'admin', array []::text[]);
select function_privs_are('public', 'set_cookie', array ['text'], 'authenticator', array ['EXECUTE']);
set client_min_messages to warning;
truncate auth."user" cascade;
reset client_min_messages;
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')
, (5, 'admin@tandem.blog', 'Demo', 'test', 'admin', '12af4c88b528c2ad4222e3740496ecbc58e76e26f087657524', current_timestamp + interval '1 month')
;
prepare user_info as
Use user’ß email for auth funcs and return cookie on email change This is for security, just in case two users have the same cookie, althought it is unlikely, but nevertheless less guessable. I also need to refresh the cookie when the user changes their email address, because it is liked toghether. It does mean that it will logout from everywhere else, but i can not do anything about that.
2023-01-23 20:18:55 +00:00
select current_user_email(), current_user_cookie(), current_user;
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 lives_ok(
$$ select set_cookie('44facbb30d8a419dfd4bfbc44a4b5539d4970148dfc84bed0e/demo@tandem.blog') $$,
'Should run ok for a valid cookie'
);
select results_eq(
'user_info',
Use user’ß email for auth funcs and return cookie on email change This is for security, just in case two users have the same cookie, althought it is unlikely, but nevertheless less guessable. I also need to refresh the cookie when the user changes their email address, because it is liked toghether. It does mean that it will logout from everywhere else, but i can not do anything about that.
2023-01-23 20:18:55 +00:00
$$ values ('demo@tandem.blog', '44facbb30d8a419dfd4bfbc44a4b5539d4970148dfc84bed0e', 'invoicer'::name) $$,
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 info with the correct user'
);
reset role;
select lives_ok(
$$ select set_cookie('12af4c88b528c2ad4222e3740496ecbc58e76e26f087657524/admin@tandem.blog') $$,
'Should run ok for a different cookie'
);
select results_eq(
'user_info',
Use user’ß email for auth funcs and return cookie on email change This is for security, just in case two users have the same cookie, althought it is unlikely, but nevertheless less guessable. I also need to refresh the cookie when the user changes their email address, because it is liked toghether. It does mean that it will logout from everywhere else, but i can not do anything about that.
2023-01-23 20:18:55 +00:00
$$ values ('admin@tandem.blog', '12af4c88b528c2ad4222e3740496ecbc58e76e26f087657524', 'admin'::name) $$,
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 info with the other user'
);
reset role;
select lives_ok(
$$ select set_cookie('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/admin@tandem.blog') $$,
'Should run ok even for an invalid cookie'
);
select results_eq(
'user_info',
Use user’ß email for auth funcs and return cookie on email change This is for security, just in case two users have the same cookie, althought it is unlikely, but nevertheless less guessable. I also need to refresh the cookie when the user changes their email address, because it is liked toghether. It does mean that it will logout from everywhere else, but i can not do anything about that.
2023-01-23 20:18:55 +00:00
$$ values ('', '', 'guest'::name) $$,
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 info as a guest user'
);
reset role;
select *
from finish();
rollback;