Auth DB Module - #148
Conversation
Checks credentials passed in message, and if they are RFIDCard credentials, check to see if they exist in the database. Implementation for fetching from the database TODO.
Gets the user from the database that owns the credentials
Allows for doorman module to have door schedules - doorman tries to check door states during start up (if schedules are set). FGPIO::isOn() called with "STATE" command. LIBGPIOD did not have this message handled. This fix now has libgpiod handle the "STATE" message and sends the state back as "ON" or "OFF".
Sometimes kickback will occur due to the nature of inductors. Solenoid strikers send kicback through the lines when they close. Additionally, wiegand lines can be very sensitive to noise. As a result, noise can come into the D0 and D1 lines and result in false negatives. This commit adds config variables to allow the user to ignore a certain amount of bits coming in that they might consider noise to have the software ignore it as an access attempt.
No longer needed since authdb tables are set up in leosac_db creation
Used as a helper to clear schedules so doorman can constantly check if each door has updated schedules.
Groups timeframes by days, then checks if a full day should be closed
Prevents closed start/end being the same as open start/end of open schedules. Causes a 1 minute conflict without this.
Config states bits_x_threshold checks less than or equal to. While the code was only checking less than (and vise versa).
Was missing the first two schedule comparison
For each instance, an object for every door in the config was created. This makes it so only objects for the doors under the instance are created.
Before - always_closed schedules would prevent access to the door even if the user was authorized. I've removed this because this should be configured instead. If the door shouldn't have access to it then this should be configured in the schedule mapping itself for the user(s) that should not be allowed access during that time. Ultimately, there likely is never going to be a door that should be denied access by all users ever. And if there is, then it can be configured so in the schedule mapping to prevent user access during a certain timeframe.
Related to commit af2fd4f
Link leosac_db and lib properly, and set doorman to require them as well since doorman now works with the database
Old code was temporarily only returning the first profile it found. This fixes this by merging all schedules into one.
Maxhy
left a comment
Maxhy
left a comment
There was a problem hiding this comment.
Globally it's a great addition, thanks a lot. It was missing a proper implementation.
Just some comments to better understand part of your changes.
| AUTH_DENIED = 0x21 & AL_USER, | ||
|
|
||
| LAST__ = 0xffff | ||
| // 0..63 reserved to keep masks within 64-bit numeric serialization |
There was a problem hiding this comment.
I'm not sure to understand why this enum values & flag use have to be changed?
There was a problem hiding this comment.
These have been changed because we were getting something like this:
USER_CREATED = 0x10 & AL_SYSTEM being 0x10 & 0x1000 which is 0x00 because:
0x10: 0000 0000 0001 0000
0x1000: 0001 0000 0000 0000
-------------------
&: 0000 0000 0000 0000 = 0x00
So everything was defaulting to 0x00. As a result, when the code called
if (event_mask_ & EventType::AUTH_GRANTED)
ss << "Access Granted to Credential " << generate_credential_description() << ".";
else if (event_mask_ & EventType::AUTH_DENIED)
ss << "Access Denied to Credential " << generate_credential_description() << ".";It would always result in
ss << "Access Granted to Credential " << generate_credential_description() << ".";I used sequential numbers as a fix to simplify it.
There was a problem hiding this comment.
Oh yes indeed. You're right that was an issue/mistake, but I would prefer to keep using flags logic to be able to easily filter USER and SYSTEMS records if required. It would be better to fix the enum values with the original expected values in my opinion, that means replacing & by |.
eg. USER_CREATED = 0x10 & AL_SYSTEM => USER_CREATED = 0x10 | AL_SYSTEM
| auto target = find_target(action.target_); | ||
| if (target && (target->is_always_closed(std::chrono::system_clock::now()) || | ||
| target->is_always_open(std::chrono::system_clock::now()))) | ||
| if (target && target->is_always_open(std::chrono::system_clock::now())) |
There was a problem hiding this comment.
Why removing is_always_closed check? Some door strike may require the inverse mode.
There was a problem hiding this comment.
I had to make this change based off of the solution I came up when using the database to schedule doors being open or not. My solution to use the DB to set door schedules was a bit rushed - I didn't want to have to make a new DB table since I didn't have the time, so I chose to create closed and open schedules through the existing logic. I found that closed schedules don't let anyone through though, even if a user is authorized due to this line of code. Here is my commit message:
Before - always_closed schedules would prevent access to
the door even if the user was authorized. I've removed this
because this should be configured instead. If the door
shouldn't have access to it then this should be configured
in the schedule mapping itself for the user(s) that should
not be allowed access during that time.
Ultimately, there likely is never going to be a door
that should be denied access by all users ever. And if
there is, then it can be configured so in the schedule
mapping to prevent user access during a certain timeframe.
I could be incorrect in my understanding, but this is the issue I was running into when a door was in an always_closed state - I couldn't open a door with my card even if I was authorized.
There was a problem hiding this comment.
Now I understand what you were saying :). You're right this would be an issue in your case.
On the other side I believe some people are using the always closed schedule for such purpose, so I may end up merging your changes here and adding back a similar feature/check differently according to feedbacks.
2 participants
Implements the auth-db module
Updates the door module