camper/test/redsys.sql

246 lines
9.8 KiB
MySQL
Raw Normal View History

Implement Redsys request signature in PostgreSQL Every company need to have its own merchant code and encryption key, thus it is not possible to use environment variables to keep that data, and i have to store it in the database. I do not want to give SELECT permission on the encryption key to guest, because i am going to fuck it up sooner or later, and everyone would be able to read that secret; i know it would. Therefore, i need a security definer function that takes the data to encrypt, use the key to encrypt it, and returns the result; nobody else should have access to that key, not even admins! By the way, i found out that every merchant receives the same key, thus it is not a problem to keep it in the repository. Since i need that SQL function to encrypt the data, i thought that i may go the whole nine yards and sign the request in PostgreSQL too, after all the data to sign comes from there, and it has JSON functions to create and base64-code an object. Fortunately, pg_crypto has all the functions that i need, but i can no longer keep that extension inside the auth schema, because it is used from others, and the public schema, like every other extensions, seems more appropriate. Instead of having the list of currency and language codes that Redsys uses as constants in the code, i moved that as field to the currency and language relations, so i can simply pass the lang_tag to the function and it can transform that tag to the correct code; the currency is from the company’s relation, since it is the only currency used in the whole application (for now). As a consequence, i had to grant execute to currency and the parse_price functions to guest, too. To generate the test data used in the unit tests, i used a third-party PHP implementation[0], but i only got from that the resulting base64-coded JSON object and signature, using the same that as in the unit test, and did not use any code from there. PostgreSQL formats the JSON as text differently than most implementations i have seen: it adds spaces between the key name and the colons, and space between the value and the separating comma. The first implementation used replace() to format the JSON as exactly as the PHP implementation, so that the result matches, and then tried to do generate the form by hand using the output from PostgreSQL without the replace(), to verify that Redsys would still accept my input. Finally, i adjusted the unit test to whatever pg_prove said it was getting from the function. I still have the form’s action hard-codded to the test environment, but the idea is that administrators should be able to switch from test to live themselves. That means that i need that info in the redsys relation as well. I think this is one of the few use cases for SQL’s types, because it is unlikely to change anytime soon, and i do not need the actual labels. Unfortunately, i could not use enumerations for the request’s transaction type because i can not attach an arbitrary number to the enum’s values. Having a relation is overkill, because i would need a constant in Go to refer to its primary key anyway, thus i kept the same constant i had before for that. Language and currency constant went out, as this is in the corresponding relations. In setup_redsys i must have a separate update if the encrypt_key is null because PostgreSQL checks constraints before key conflict, and i do not want to give a default value to the key if the row is not there yet. The problem is that i want to use null to mean “keep the same password”, because it is what i intend to do with the user-facing form: leave the input empty to keep the same password. As now Go needs to pass composite types back and forth with PostgreSQL, i need to register these types, and i have to do it every time because the only moment i have access to the non-pooled connection is in the AfterConnect function, but at that point i have no idea whether the user is going to request a payment. I do not know how much the performance degrades because of this. [0]: https://github.com/ssheduardo/sermepa/blob/master/src/Sermepa/Tpv/Tpv.php
2023-10-26 23:52:04 +00:00
-- Test redsys
set client_min_messages to warning;
create extension if not exists pgtap;
reset client_min_messages;
begin;
select plan(75);
set search_path to camper, public;
select has_table('redsys');
select has_pk('redsys');
select table_privs_are('redsys', 'guest', array []::text[]);
select table_privs_are('redsys', 'employee', array []::text[]);
select table_privs_are('redsys', 'admin', array ['DELETE']);
select table_privs_are('redsys', 'authenticator', array []::text[]);
select has_column('redsys', 'company_id');
select col_is_pk('redsys', 'company_id');
select col_is_fk('redsys', 'company_id');
select fk_ok('redsys', 'company_id', 'company', 'company_id');
select col_type_is('redsys', 'company_id', 'integer');
select col_not_null('redsys', 'company_id');
select col_hasnt_default('redsys', 'company_id');
select column_privs_are('redsys', 'company_id', 'guest', array ['SELECT']);
select column_privs_are('redsys', 'company_id', 'employee', array ['SELECT']);
select column_privs_are('redsys', 'company_id', 'admin', array ['SELECT', 'INSERT', 'UPDATE']);
select column_privs_are('redsys', 'company_id', 'authenticator', array []::text[]);
select has_column('redsys', 'merchant_code');
select col_type_is('redsys', 'merchant_code', 'text');
select col_not_null('redsys', 'merchant_code');
select col_hasnt_default('redsys', 'merchant_code');
select column_privs_are('redsys', 'merchant_code', 'guest', array ['SELECT']);
select column_privs_are('redsys', 'merchant_code', 'employee', array ['SELECT']);
select column_privs_are('redsys', 'merchant_code', 'admin', array ['SELECT', 'INSERT', 'UPDATE']);
select column_privs_are('redsys', 'merchant_code', 'authenticator', array []::text[]);
select has_column('redsys', 'terminal_number');
select col_type_is('redsys', 'terminal_number', 'integer');
select col_not_null('redsys', 'terminal_number');
select col_hasnt_default('redsys', 'terminal_number');
select column_privs_are('redsys', 'terminal_number', 'guest', array ['SELECT']);
select column_privs_are('redsys', 'terminal_number', 'employee', array ['SELECT']);
select column_privs_are('redsys', 'terminal_number', 'admin', array ['SELECT', 'INSERT', 'UPDATE']);
select column_privs_are('redsys', 'terminal_number', 'authenticator', array []::text[]);
select has_column('redsys', 'environment');
select col_type_is('redsys', 'environment', 'redsys_environment');
select col_not_null('redsys', 'environment');
select col_hasnt_default('redsys', 'environment');
select column_privs_are('redsys', 'environment', 'guest', array ['SELECT']);
select column_privs_are('redsys', 'environment', 'employee', array ['SELECT']);
select column_privs_are('redsys', 'environment', 'admin', array ['SELECT', 'INSERT', 'UPDATE']);
select column_privs_are('redsys', 'environment', 'authenticator', array []::text[]);
select has_column('redsys', 'integration');
select col_type_is('redsys', 'integration', 'redsys_integration');
select col_not_null('redsys', 'integration');
select col_hasnt_default('redsys', 'integration');
select column_privs_are('redsys', 'integration', 'guest', array ['SELECT']);
select column_privs_are('redsys', 'integration', 'employee', array ['SELECT']);
select column_privs_are('redsys', 'integration', 'admin', array ['SELECT', 'INSERT', 'UPDATE']);
select column_privs_are('redsys', 'integration', 'authenticator', array []::text[]);
select has_column('redsys', 'encrypt_key');
select col_type_is('redsys', 'encrypt_key', 'bytea');
select col_not_null('redsys', 'encrypt_key');
select col_hasnt_default('redsys', 'encrypt_key');
select column_privs_are('redsys', 'encrypt_key', 'guest', array []::text[]);
select column_privs_are('redsys', 'encrypt_key', 'employee', array []::text[]);
select column_privs_are('redsys', 'encrypt_key', 'admin', array ['INSERT', 'UPDATE']);
select column_privs_are('redsys', 'encrypt_key', 'authenticator', array []::text[]);
set client_min_messages to warning;
truncate redsys cascade;
truncate company_host cascade;
truncate company_user cascade;
truncate company cascade;
truncate auth."user" cascade;
reset client_min_messages;
insert into auth."user" (user_id, email, name, password, cookie, cookie_expires_at)
values (1, 'demo@tandem.blog', 'Demo', 'test', '44facbb30d8a419dfd4bfbc44a4b5539d4970148dfc84bed0e', current_timestamp + interval '1 month')
, (5, 'admin@tandem.blog', 'Demo', 'test', '12af4c88b528c2ad4222e3740496ecbc58e76e26f087657524', current_timestamp + interval '1 month')
;
insert into company (company_id, business_name, vatin, trade_name, phone, email, web, address, city, province, postal_code, rtc_number, tourist_tax, tourist_tax_max_days, country_code, currency_code, default_lang_tag)
values ( 2, 'Company 2', 'XX123', '', '555-555-555', 'a@a', '', '', '', '', '', '', 60, 7, 'ES', 'EUR', 'ca')
, ( 4, 'Company 4', 'XX234', '', '666-666-666', 'b@b', '', '', '', '', '', '', 60, 7, 'FR', 'USD', 'ca')
, ( 6, 'Company 6', 'XX345', '', '777-777-777', 'c@c', '', '', '', '', '', '', 60, 7, 'GB', 'EUR', 'en')
, ( 8, 'Company 8', 'XX456', '', '888-888-888', 'd@d', '', '', '', '', '', '', 60, 7, 'DE', 'USD', 'es')
Implement Redsys request signature in PostgreSQL Every company need to have its own merchant code and encryption key, thus it is not possible to use environment variables to keep that data, and i have to store it in the database. I do not want to give SELECT permission on the encryption key to guest, because i am going to fuck it up sooner or later, and everyone would be able to read that secret; i know it would. Therefore, i need a security definer function that takes the data to encrypt, use the key to encrypt it, and returns the result; nobody else should have access to that key, not even admins! By the way, i found out that every merchant receives the same key, thus it is not a problem to keep it in the repository. Since i need that SQL function to encrypt the data, i thought that i may go the whole nine yards and sign the request in PostgreSQL too, after all the data to sign comes from there, and it has JSON functions to create and base64-code an object. Fortunately, pg_crypto has all the functions that i need, but i can no longer keep that extension inside the auth schema, because it is used from others, and the public schema, like every other extensions, seems more appropriate. Instead of having the list of currency and language codes that Redsys uses as constants in the code, i moved that as field to the currency and language relations, so i can simply pass the lang_tag to the function and it can transform that tag to the correct code; the currency is from the company’s relation, since it is the only currency used in the whole application (for now). As a consequence, i had to grant execute to currency and the parse_price functions to guest, too. To generate the test data used in the unit tests, i used a third-party PHP implementation[0], but i only got from that the resulting base64-coded JSON object and signature, using the same that as in the unit test, and did not use any code from there. PostgreSQL formats the JSON as text differently than most implementations i have seen: it adds spaces between the key name and the colons, and space between the value and the separating comma. The first implementation used replace() to format the JSON as exactly as the PHP implementation, so that the result matches, and then tried to do generate the form by hand using the output from PostgreSQL without the replace(), to verify that Redsys would still accept my input. Finally, i adjusted the unit test to whatever pg_prove said it was getting from the function. I still have the form’s action hard-codded to the test environment, but the idea is that administrators should be able to switch from test to live themselves. That means that i need that info in the redsys relation as well. I think this is one of the few use cases for SQL’s types, because it is unlikely to change anytime soon, and i do not need the actual labels. Unfortunately, i could not use enumerations for the request’s transaction type because i can not attach an arbitrary number to the enum’s values. Having a relation is overkill, because i would need a constant in Go to refer to its primary key anyway, thus i kept the same constant i had before for that. Language and currency constant went out, as this is in the corresponding relations. In setup_redsys i must have a separate update if the encrypt_key is null because PostgreSQL checks constraints before key conflict, and i do not want to give a default value to the key if the row is not there yet. The problem is that i want to use null to mean “keep the same password”, because it is what i intend to do with the user-facing form: leave the input empty to keep the same password. As now Go needs to pass composite types back and forth with PostgreSQL, i need to register these types, and i have to do it every time because the only moment i have access to the non-pooled connection is in the AfterConnect function, but at that point i have no idea whether the user is going to request a payment. I do not know how much the performance degrades because of this. [0]: https://github.com/ssheduardo/sermepa/blob/master/src/Sermepa/Tpv/Tpv.php
2023-10-26 23:52:04 +00:00
;
insert into company_user (company_id, user_id, role)
values (2, 1, 'admin')
, (4, 5, 'admin')
;
insert into company_host (company_id, host)
values (2, 'co2')
, (4, 'co4')
;
insert into redsys(company_id, merchant_code, terminal_number, environment, integration, encrypt_key)
values (4, '444444444', 4, 'live', 'insite', E'\\x44')
, (8, '888888888', 8, 'test', 'redirect', E'\\x88')
;
prepare redsys_data as
select company_id, merchant_code, terminal_number
from redsys
;
set role guest;
select bag_eq(
'redsys_data',
$$ values (4, '444444444', 4)
, (8, '888888888', 8)
$$,
'Everyone should be able to list Redsys settings from all companies'
);
reset role;
select set_cookie('44facbb30d8a419dfd4bfbc44a4b5539d4970148dfc84bed0e/demo@tandem.blog', 'co2');
select lives_ok(
$$ insert into redsys(company_id, merchant_code, terminal_number, environment, integration, encrypt_key) values (2, '222222222', 2, 'live', 'insite', E'\\x22' ) $$,
'Admin from company 2 should be able to set up their Redsys settings.'
);
select bag_eq(
'redsys_data',
$$ values (2, '222222222', 2)
, (4, '444444444', 4)
, (8, '888888888', 8)
$$,
'The new row should have been added'
);
select lives_ok(
$$ update redsys set merchant_code = '121212121', terminal_number = 1, encrypt_key = E'\\x12' where company_id = 2 $$,
'Admin from company 2 should be able to update their Redsys settings.'
);
select bag_eq(
'redsys_data',
$$ values (2, '121212121', 1)
, (4, '444444444', 4)
, (8, '888888888', 8)
$$,
'The row should have been updated.'
);
select lives_ok(
$$ delete from redsys where company_id = 2 $$,
'Admin from company 2 should be able to delete their Redsys settings.'
);
select bag_eq(
'redsys_data',
$$ values (4, '444444444', 4)
, (8, '888888888', 8)
$$,
'The row should have been deleted.'
);
select throws_ok(
$$ insert into redsys (company_id, merchant_code, terminal_number, environment, integration, encrypt_key) values (6, '666666666', 6, 'live', 'insite', E'\x66' ) $$,
'42501', 'new row violates row-level security policy for table "redsys"',
'Admin from company 2 should NOT be able to setup Redsys for another company.'
);
select lives_ok(
$$ update redsys set merchant_code = '123456789', terminal_number = 10 where company_id = 4 $$,
'Admin from company 2 should NOT be able to update the Redsys settings of company 4, but no error'
);
select bag_eq(
'redsys_data',
$$ values (4, '444444444', 4)
, (8, '888888888', 8)
$$,
'No row should have been updated.'
);
select lives_ok(
$$ update redsys set company_id = 2 where company_id = 4 $$,
'Admin from company 2 should NOT be able to usurp the Redsys settings of company 4, but no error because company_id is primary key'
);
select lives_ok(
$$ delete from redsys where company_id = 4 $$,
'Admin from company 2 should NOT be able to delete the Redsys of company 4, but not error is thrown'
);
select bag_eq(
'redsys_data',
$$ values (4, '444444444', 4)
, (8, '888888888', 8)
$$,
'No row should have been deleted'
);
select throws_ok(
$$ insert into redsys (company_id, merchant_code, terminal_number, environment, integration, encrypt_key) values (2, '22222222', 1, 'live', 'insite', E'\\x22') $$,
'23514', 'new row for relation "redsys" violates check constraint "merchant_code_valid"',
'Should not be able to insert a merchant code less than 9 digits long.'
);
select throws_ok(
$$ insert into redsys (company_id, merchant_code, terminal_number, environment, integration, encrypt_key) values (2, '2222222222', 1, 'live', 'insite', E'\\x22') $$,
'23514', 'new row for relation "redsys" violates check constraint "merchant_code_valid"',
'Should not be able to insert a merchant code more than 9 digits long.'
);
select throws_ok(
$$ insert into redsys (company_id, merchant_code, terminal_number, environment, integration, encrypt_key) values (2, '2222a2222', 1, 'live', 'insite', E'\\x22') $$,
'23514', 'new row for relation "redsys" violates check constraint "merchant_code_valid"',
'Should not be able to insert a merchant code that contains a non-digit character.'
);
select throws_ok(
$$ insert into redsys (company_id, merchant_code, terminal_number, environment, integration, encrypt_key) values (2, '222222222', 0, 'live', 'insite', E'\\x22') $$,
'23514', 'new row for relation "redsys" violates check constraint "terminal_number_in_range"',
'Should not be able to insert a terminal code smaller than 1.'
);
select throws_ok(
$$ insert into redsys (company_id, merchant_code, terminal_number, environment, integration, encrypt_key) values (2, '222222222', 1000, 'live', 'insite', E'\\x22') $$,
'23514', 'new row for relation "redsys" violates check constraint "terminal_number_in_range"',
'Should not be able to insert a terminal code greater than 999.'
);
reset role;
select *
from finish();
rollback;