Hello everyone,

Yesterday i hit the following situation: My aim was to restrict access to collection "test" to certain users. Reading the docs, I created a test_viewers role and connected certain users to the viewrestrcoll authorization to the test collection (all using the web interface). But, instead of entering "test" in the collection argument of the viewrestrcoll, I mistakenly added "Test". The issue I found was that, even though the parameter 'collection' is entered and kept in the DB in the case you enter it, you cannot add ie "test" if you have previously added "TEST" or "Test". If you try that you get a warning saying "sorry, authorization could not be added, it probably already exists". This is obviously related to the DB having uf8_general_ci collation, so the relevant check returns a row, regardless if you search for "Test", "test", or "TEST"... Having said that, some(?) python libraries distinguish arguments passed to authorizations in a case-sensitive way (probably because they work with IDs). For example,
search_engine.collection_restricted_p('Test')   is true, while
search_engine.collection_restricted_p('test')  is not.
Furthermore the entries in accARGUMENT are never(?) deleted even if you delete the appropriate authorization. This means that if one for some reason enters a value for keyword in this table, that value in all lower/capital letter combinations is reserved for ever... I don't know if this is the desired operation, but if not, you might either consider changing collation (dangerous?) to utf8_bin for certain tables (accARGUMENT for example), or alternatively change certain functions (like collection_restricted_p) to be case insensitive.

Although my problem is now solved by changing the string in the DB, I thought I should raise the issue in case you wanted to deal with it in the future :)

Best regards,
Theodoros

Reply via email to