Introduce table for session management

[ncosta-ic]

This feature introduces a new session table which is needed by the icinga-notifications-web project.
It stores the current authenticated sessions into the table which allows the background daemon (php-based) to validate a connection and its corresponding browser to an authenticated session.

Read #118 for more information about this addition.

[julianbrost]

Please have a look at the code style / indentation in the rest of the file and keep the additions consistent with that.

[julianbrost]

What will id and device_id store? I can't really make sense of the data types here.

[ncosta-ic]

php_session_id stores the session identificator generated by php. We use VARCHAR(256) here as that's the maximum number of allowed characters stated by PHP's documentation.

username's type was defined by double-checking the existing username table definitions found in icingaweb2/schema/pgsql.schema.sql.

device_id stores a device fingerprint generated by creating a jooat hash which consinsts of the authenticated username, concatenated by the full user-agent string. Jooat hashes have a maximum length of 8 bytes, hence the limitation.

[julianbrost]

This comment is now pretty much a "I think it's strange but if you want it, you get it" as per #118 (comment).

For username, I find it a bit weird that it uses a different type here compared to contact.username. Though that one might be subject to a change to citext in #71 based on feedback from @nilmerg on how Icinga Web handles usernames.

device_id stores a device fingerprint generated by creating a jooat hash which consinsts of the authenticated username, concatenated by the full user-agent string. Jooat hashes have a maximum length of 8 bytes, hence the limitation.

uint32_t vs varchar(8), sounds like you want to store an int value as a hex string? And that hash doesn't really sound like it would give something that would qualify as device ID: if I use the same browser on the same OS on two devices, this should give the same device ID whereas if I update my browser on one device, that would change the device ID.

[ncosta-ic]

username uses the type definition from icingaweb2/schema/pgsql.schema as this is the actual type representation of the username that's being passed in the AuthenticationHook parameters. As we're storing the session and its corresponding user in that specific hook, we also want to use the same type definition (I'd say).

You are right with the uint32_t that's used as a return value in jenkins' one at a time hash. We are working with PHP however and a call to hash() returns lowercased hexits by default. It most certainly makes sense to store the uint representation of that value but shouldn't the database reflect the data representation that's also getting used in comparisons and such?
Because in the written PHP code, it will always be compared in its hexadecimal form.

You have a fair point in terms of the device_id column naming convention. It essentially fingerprints a specific browser and its authenticated user. It doesn't really care about the underlying device.
I chose that prefix as other features in the icinga2 suite which also use the user agent string, already refer to it as a device, e.g: icingaweb2/library/Icinga/Web/RememberMeUserDevicesList.php

[ncosta-ic]

@julianbrost updated the code to include your requested changes.
Is this fine for you now?

[ncosta-ic]

Please have a look at the code style / indentation in the rest of the file and keep the additions consistent with that.

Yeah, just noticed it as well. It somehow auto-formatted my modifications when I committed the changes. Should be fixed now.

[julianbrost]

This comment is now pretty much a "I think it's strange but if you want it, you get it" as per #118 (comment).

For username, I find it a bit weird that it uses a different type here compared to contact.username. Though that one might be subject to a change to citext in #71 based on feedback from @nilmerg on how Icinga Web handles usernames.

device_id stores a device fingerprint generated by creating a jooat hash which consinsts of the authenticated username, concatenated by the full user-agent string. Jooat hashes have a maximum length of 8 bytes, hence the limitation.

uint32_t vs varchar(8), sounds like you want to store an int value as a hex string? And that hash doesn't really sound like it would give something that would qualify as device ID: if I use the same browser on the same OS on two devices, this should give the same device ID whereas if I update my browser on one device, that would change the device ID.

[julianbrost]

FYI: I'd wait a bit with merging this until Icinga/icinga-notifications-web#146 seems to get close to finalizing.

[nilmerg]

It's ready. This isn't, anymore, it seems.

[ncosta-ic]

@nilmerg @julianbrost I rebased it to the current main branch and fixed the colliding file name. It's now ready to be merged as Icinga/icinga-notifications-web#146 waits to be merged and requires this change.

[julianbrost]

I've pushed a commit that makes the overall style more consistent with the rest of the schema files.

There's one functional change: I renamed the primary key constraint to pk_browser_session so that it is consistent with pk_${table_name} used in the rest of the file. @ncosta-ic Is that fine for you or do you explicitly refer to it by name somewhere? (Our Go code does when generating upsert statements and uses that to generate the constraint name by default. Not super important as that table isn't intended to be used from Go, but I'd still prefer it to be consistent with the rest.)

[ncosta-ic]

@julianbrost Consistency is always good, thanks for the fixup. The renaming should not interfere with our code as we do not refer to the primary key constraint (for now, at least).