Source: Introduce Usernames

[oxzi]

Unique usernames were added to Sources for HTTP Authentication.

Before, the HTTP Authentication expected a username based on the Source ID, such as "source-23". This was not very practical. Thus, an unique username column was introduced and the Listener's authentication code was adequately altered.

Blocked By

• Add input field for listener_username icinga-notifications-web#401: Should be merged together, otherwise Web couldn't create working sources.

Fixes #227.
refs Icinga/icinga-notifications-web#398

[sukhwinder33445]

While testing Icinga/icinga-notifications-web#390 with the branch https://github.com/Icinga/icinga-notifications/ pull/324, I noticed that icingadb was unable to connect to the notifications API because I had accidentally omitted to define a “listener_password” when creating a resource.

However, since the column is nullable, no error is displayed if a resource is defined without a password.

As these fields are required, they should not be nullable.

[oxzi]

Both columns are nullable to ease the database schema migration. But, as @yhabteab also suggested above, maybe the primary key can be changed from an ID to this username, being UNIQUE and everything.

[julianbrost]

maybe the primary key can be changed from an ID to this username

I mean technically possible, but that would then also have to be used for foreign keys (obviously) and make it pretty much impossible to change the username for a source. Also keep in mind that it's currently included in the object IDs as objects are handled as being source-specific:

icinga-notifications/internal/object/object.go

Lines 197 to 199 in cea444e

	sourceBytes := make([]byte, 8)
	binary.BigEndian.PutUint64(sourceBytes, uint64(source))
	h.Write(sourceBytes)

[oxzi]

Due to the size of the changes, I am also no fan of changing the primary key.

---

However, back to the original comment:

While testing Icinga/icinga-notifications-web#390 with the branch https://github.com/Icinga/icinga-notifications/ pull/324, I noticed that icingadb was unable to connect to the notifications API because I had accidentally omitted to define a “listener_password” when creating a resource.

Without a password, Icinga Notifications would reject the connection. That's intended.

But, as I commented above, this would allow schema migrations and keep elements of old and now removed sources - such as Icinga 2.

[julianbrost]

Both columns are nullable to ease the database schema migration.

Why both though? I was a bit too focused on listener_password_hash, as that was the culprit in the the original comment. For that one, I see that the nullable for the migration applies: we can't really set a meaningful password during the migration, so the plan for the migration is:

1. Apply the schema upgrade.
2. Manually assign passwords to icinga2 sources in web.
3. Configure these source credentials in Icinga DB.

Note that web should probably enforce that listener_password_hash is set. Otherwise that'll create a source that can't authenticate itself. A corresponding not null constraint can then be added in a migration for a later version (otherwise, the migration for this version would need a second schema migration file that needs to be applied later).

However, for listener_username, the migration file sets the value to the previously used source-${id} string, so I don't see a reason why that shouldn't get a not null constraint.

[oxzi]

Based on @nilmerg's comment and your reply, I have added a CHECK (deleted = 'y' OR listener_username IS NOT NULL) to allow listener_username to be NULL for deleted rows from web. Otherwise, the UNIQUE constraint ensures no username appearing twice.

[julianbrost]

There's still something unaddressed from #338 (comment):

However, for listener_username, the migration file sets the value to the previously used source-${id} string, so I don't see a reason why that shouldn't get a not null constraint.

I've also added references to the Icinga Notifications Web issue + PR in the description.

[nilmerg]

I was also convinced that the user name must not be nullable until right now. But then I saw that for the unique check we'd need to include deleted rows as they are part of the unique constraint still. Thus I'd object it being non-nullable.

[julianbrost]

I see. It should be treated by Notifications Web like a required column for live rows nonetheless. That could be expressed as a deleted = 'y' or listener_username is not null constraint instead of an unconditional not null on the column.

[julianbrost]

Looks good to me now, wait for Icinga/icinga-notifications-web#401 with merging though.

I didn't mark all conversations as resolved as I didn't start them, maybe their authors (@yhabteab @sukhwinder33445) want to take another look as well.

[nilmerg]

Looks good to me now, wait for Icinga/icinga-notifications-web#401 with merging though.

Done.