I set up my program to connect to Relativity Server using DbTableLoginProvider.
Problem 1: the drop down list is a bit too narow and doesn’t even help me with a hint, se this picture .
There are actually 3 different tables that seem to be the same in the list, but they are not! Could be nice if you could do some fix to this
My first guess was that this was just references to tablename and fields and that the login would create a Query of it’s own to do it’s work. As I also need to let the user see data from his own record in the login table, I added a macro to the where-clause in the Statements of the Schema modeller.
As this caused the login to cease working, I got the idea that login mechanism utilized the Query in the modeller. So I made a another copy of the table in the modeller, unchecked it’s public property but didn’t add any where macro, and used it for login.
As login now started working again, everything seems to be as I thought. But even now this looks strange: I removed a few unneccesary fields from the “login version” of the Query, but in the “UserName field” and “Password field” dropdowns I can still see all the fields.
As I am just trying to learn about all this, it would be very helpful if you could shed some light on what is happening?
Last problem: the DbTableLoginProvider looks up the password in the table and compares it directly. What if I want to use a more secure way, where the database field stores a hash of the password, not the password itself? What would be the best way to go?
The column with the dropdowns is resizeable. You’d need either to maximize the AdminTool window (in that comboboxes are resized automatically).
Yes you are right, the Logins table is accessed in the same way as any other Schema table (ie via its query). So adding there any macroses that rely on the login parameters (like f.e. user id or name) won’t work as at the moment of the query they aren’t initialized.
This shouldn’t happen. Could you provide EXACT steps on how to reproduce this? The only scenario that where I can reproduce similar behaviour is when
The Schema is opened in the Schema Modeler
AdminTool is opened on the LoginProvider options
Schema is edited and saved
In that case Schema data (including field lists) is not refreshed while the Login Providers page is opened, so one would see unrefreshed data. This is expected. Navigating to any other page and back will trigger the refresh.
There’s no build-in functionality in Relativity for this. However it is possible to intercept the request to the users table using Scripting and calculate the password hash. At this moment more advanced scenarios would require a custom server application (note that migrating from Relativity to own server requires almost no efforts except for the login management implementation).
.