Feature: Add support for email notifications when disabling user #3

atc0005 · 2020-01-24T13:20:36Z

Username disabled
time/date
Splunk Webhook submission (raw)?
File path, applicable details
?

atc0005 · 2020-06-29T11:05:08Z

The goal here is to provide initial support with one or more follow-up PRs to flesh out the feature.

atc0005 · 2020-06-29T11:08:57Z

I'll also have to decide whether to have email notifications function like the current Teams notifications (one per step in the event chain), or queue up the messages until I'm fairly confident that all of them have been generated and then build a combined notification that includes all relevant details.

If the latter, I'll need some way to indicate this in the Record type, some sort of field like Last, Final, or another similar name.

The easiest approach is to generate separate emails and that may be where I go first with this.

atc0005 · 2020-07-09T13:19:15Z

The easiest approach is to generate separate emails and that may be where I go first with this.

This is what I've opted for as a first draft.

I'm on the fence now about co-opting the MessageCard type from the go-teams-notify package or going with a new structure.

atc0005 · 2020-07-09T14:08:34Z

See notes on atc0005/learn#47. Not sure yet which package to use.

atc0005 · 2020-07-09T18:05:06Z

I'm going to go with the absolute bare necessities at this time, just the standard library net/smtp package for the time being. Still working on stubbing it out (config struct, flags, config file, validation, etc), hoping to begin actual testing in the next handful of days.

BACKSTORY As I went to start work towards implementing email notification support per GH-3, I was struck by how unclear the arguments to the `emailNotifier` function (and similarly, the `teamsNotifier` function) were. The difference between `config.NotifyMgrEmailNotificationDelay` and `cfg.EmailNotificationDelay()` were not immediately clear and it took longer than I'd like to admit to fully backtrack and confirm not only the original intent, but the current behavior surrounding those settings. This commit attempts to clarify not only the original intent, but the purpose behind each related portion of code surrounding what I know understand to be handling the rate limit (formerly named `config.NotifyMgrEmailNotificationDelay`) and notification retry delay. CHANGES - documentation - README.md - update "feature" entry to emphasize configurable retries, but hard-coded notifications rate-limit (hopefully soon to change) - configure.md - updated description - updated command-line flag name - updated environment variable name - updated help text/description for flag - doc.go - explicitly note that it is the retry delay that is configurable - configuration file - rename `delay` to `retry_delay` - add missing doc comments for each msteams section setting - code - search/replace across codebase to replace `Delay` with `RetryDelay` - this includes renaming the `Delay` field for the `MSTeams` type, and its associated flag, environment variable and TOML config file setting - replace `sendDelay` parameter with `sendRateLimit` to better communicate what the incoming value to `teamsNotifier` and `emailNotifier` is intended for - doc comments - fixes to correct wrong information - fixes to better communicate the intent and real behavior REFERENCES - refs GH-85

BACKSTORY As I went to start work towards implementing email notification support per GH-3, I was struck by how unclear the arguments to the `emailNotifier` function (and similarly, the `teamsNotifier` function) were. The difference between `config.NotifyMgrEmailNotificationDelay` and `cfg.EmailNotificationDelay()` were not immediately clear and it took longer than I'd like to admit to fully backtrack and confirm not only the original intent, but the current behavior surrounding those settings. This commit attempts to clarify not only the original intent, but the purpose behind each related portion of code surrounding what I know understand to be handling the rate limit (formerly named `config.NotifyMgrEmailNotificationDelay`) and notification retry delay. CHANGES - documentation - README.md - update "feature" entry to emphasize configurable retries, but hard-coded notifications rate limit (hopefully soon to change) - configure.md - updated description - updated command-line flag name - updated environment variable name - updated help text/description for flag - doc.go - explicitly note that it is the retry delay that is configurable - configuration file - rename `delay` to `retry_delay` - add missing doc comments for each msteams section setting - code - search/replace across codebase to replace `Delay` with `RetryDelay` - this includes renaming the `Delay` field for the `MSTeams` type, and its associated flag, environment variable and TOML config file setting - replace `sendDelay` parameter with `sendRateLimit` to better communicate what the incoming value to `teamsNotifier` and `emailNotifier` is intended for - doc comments - fixes to correct wrong information - fixes to better communicate the intent and real behavior REFERENCES - refs GH-85

BACKSTORY As I went to start work towards implementing email notification support per GH-3, I was struck by how unclear the arguments to the `emailNotifier` function (and similarly, the `teamsNotifier` function) were. The difference between `config.NotifyMgrEmailNotificationDelay` and `cfg.EmailNotificationDelay()` were not immediately clear and it took longer than I'd like to admit to fully backtrack and confirm not only the original intent, but the current behavior surrounding those settings. This commit attempts to clarify not only the original intent, but the purpose behind each related portion of code surrounding what I now understand to be handling the rate limit (formerly named `config.NotifyMgrEmailNotificationDelay`) and notification retry delay. CHANGES - documentation - README.md - update "feature" entry to emphasize configurable retries, but hard-coded notifications rate limit (hopefully soon to change) - configure.md - updated description - updated command-line flag name - updated environment variable name - updated help text/description for flag - doc.go - explicitly note that it is the retry delay that is configurable - configuration file - rename `delay` to `retry_delay` - add missing doc comments for each msteams section setting - code - search/replace across codebase to replace `Delay` with `RetryDelay` - this includes renaming the `Delay` field for the `MSTeams` type, and its associated flag, environment variable and TOML config file setting - replace `sendDelay` parameter with `sendRateLimit` to better communicate what the incoming value to `teamsNotifier` and `emailNotifier` is intended for - doc comments - fixes to correct wrong information - fixes to better communicate the intent and real behavior REFERENCES - refs GH-85

BACKSTORY As I went to start work towards implementing email notification support per GH-3, I was struck by how unclear the arguments to the `emailNotifier` function (and similarly, the `teamsNotifier` function) were. The difference between `config.NotifyMgrEmailNotificationDelay` and `cfg.EmailNotificationDelay()` were not immediately clear and it took longer than I'd like to admit to fully backtrack and confirm not only the original intent, but the current behavior surrounding those settings. This commit attempts to clarify not only the original intent, but the purpose behind each related portion of code surrounding what I now understand to be handling the rate limit and notification retry delay. CHANGES - documentation - README.md - update "feature" entry to emphasize configurable retries, but hard-coded notifications rate limit (hopefully soon to change) - configure.md - updated description - updated command-line flag name - updated environment variable name - updated help text/description for flag - doc.go - explicitly note that it is the retry delay that is configurable - configuration file - rename `delay` to `retry_delay` - add missing doc comments for each msteams section setting - code - search/replace across codebase to replace `Delay` with `RetryDelay` - this includes renaming the `Delay` field for the `MSTeams` type, and its associated flag, environment variable and TOML config file setting - replace `sendDelay` parameter with `sendRateLimit` to better communicate what the incoming value to `teamsNotifier` and `emailNotifier` is intended for - doc comments - fixes to correct wrong information - fixes to better communicate the intent and real behavior REFERENCES - refs GH-85

SUMMARY As a follow-up to GH-87, this commit exposes a new setting that allows directly configuring the rate limit used for Teams notifications. GH-3 will be responsible for exposing the same setting for email notifications. CHANGES - update documentation to note new setting - README - GoDoc - configure - configuration file - new `rate_limit` setting - code - remove rate limit constants in favor of external settings (email rate limit setting scheduled for GH-3) and default const value if not specified externally - new `TeamsNotificationRateLimit` getter func - new `EmailNotificationRateLimit` getter func - stub only; further work scheduled for GH-3 REFERENCES refs GH-87, GH-85, GH-19, GH-3

atc0005 · 2020-07-11T11:51:15Z

I've rebased recent work from v0.3.0 into the associated branch. I've got a good bit of the settings-related "plumbing" stubbed out, and I still need to implement the core functionality.

At the moment I'm staring at sender_email and recipient_emails config file settings, so I'll need to pick back up at this point.

atc0005 · 2020-07-13T10:33:42Z

I'm looking over the validation options for email addresses and this seems like an excellent starting point:

https://golangcode.com/validate-an-email-address/

length check
W3C-provided regex pattern match
MX record verification

I think these all make sense when accepting email address values from (potentially) untrusted sources, but since our use case is a CLI flag, environment variable or config file, the sysadmin is already trusted. I think it's probably worth implementing and enforcing the first item as-is, implementing the second and enabling a DEBUG message indicating a validation failure, but skipping the last one?

atc0005 · 2020-07-13T11:36:13Z

Next steps:

setup template for outgoing email notification
- potentially templates, but likely just one for now
setup createMessage analogue
- maybe also rename the existing func to createTeamsMessage
setup sendMessage analogue
- maybe also rename the existing func to sendTeamsMessage

SUMMARY This commit adds support for sending email notifications using the same behavioral feature set as Microsoft Teams notifications: - configurable retries and retry delay - configurable rate limit - a separate notification per event - e.g., request received, username disabled, sessions terminated The following settings are configurable: - destination email address(es) - sender address - SMTP server IP/FQDN - SMTP server port - client identity - hostname provided to the SMTP server - as noted elsewhere, some SMTP servers will perform forward/reverse DNS lookups to confirm that this provided value matches what DNS has recorded for the sending IP Address Some known weaknesses/lack of support: - hard-coded email template - as of this commit, the template using Textile formatting is enabled - future efforts are intended to move hard-coded templates out of source code constants to on-disk files for easier customization by the sysadmin(s) supporting this application - unauthenticated connections to target SMTP used - the initial use-case is a local relay which restricts connections based on source IP Address - future efforts are intended to provide support for authentication Behavior worth noting: - automatic client identity value generated from available DNS information if not specified by the sysadmin - the `Showmax/go-fqdn` package is used to retrieve the FQDN of the sending system, with a fallback to - email address verification applied using the provided W3C regex - using a guide from golangcode.com CHANGES The following items note (non-exhaustive) changes since the last point release. Many of these changes will see further refactoring as part of GH-22. - Duplicate client/alert request headers so that in-place formatting modifications performed on values in the slice do not spill over to the values used for email notifications (where a different formatting is used) - Replace placeholder "getter" methods with full-featured equivalents to existing MS Teams methods - Add new "getter" methods to cover new functionality - Add flags, environment variables to cover new functionality - Rename existing generically named functions used for Teams notification handling to explicitly mention relation to Teams notifications - this was needed to make room for email-specific notification functionality - Rework some existing Teams-specific functions to allow use with Teams and email notifications (DRY) - Add email-specific functions, methods, types to mirror existing Microsoft Teams notifications support - Replace placeholder email notification template with a "default", mostly text-only friendly format and a Textile formatted template to be used with older Redmine systems (prior to Markdown support being introduced) - `MessageTrailer` func updated to take a template string for generation of a format-specific branding string - e.g., Textile-formatted repo link or Markdown-formatted repo link - Update config Stringer interface - it is growing quite large at this point, might be time to rethink how it is handled - TOML configuration file - extended with new settings - rename some settings in an effort to better communicate intent REFERENCES - refs GH-3 - https://golangcode.com/validate-an-email-address/ - https://www.w3.org/TR/2016/REC-html51-20161101/sec-forms.html - https://github.com/Showmax/go-fqdn

SUMMARY This commit adds support for sending email notifications using the same behavioral feature set as Microsoft Teams notifications: - configurable retries and retry delay - configurable rate limit - a separate notification per event - e.g., request received, username disabled, sessions terminated The following settings are configurable: - destination email address(es) - sender address - SMTP server IP/FQDN - SMTP server port - client identity - hostname provided to the SMTP server - as noted elsewhere, some SMTP servers will perform forward/reverse DNS lookups to confirm that this provided value matches what DNS has recorded for the sending IP Address Some known weaknesses/lack of support: - hard-coded email template - as of this commit, the template using Textile formatting is enabled - future efforts are intended to move hard-coded templates out of source code constants to on-disk files for easier customization by the sysadmin(s) supporting this application - unauthenticated connections to SMTP server - the initial use-case is a local relay which restricts connections based on source IP Address - future efforts are intended to provide support for authentication Behavior worth noting: - automatic client identity value generated from available DNS information if not specified by the sysadmin - the `Showmax/go-fqdn` package is used to retrieve the FQDN of the sending system, with a fallback to - email address verification applied using the provided W3C regex - using a guide from golangcode.com CHANGES The following items note (non-exhaustive) changes since the last point release. Many of these changes will see further refactoring as part of GH-22. - Duplicate client/alert request headers so that in-place formatting modifications performed on values in the slice do not spill over to the values used for email notifications (where a different formatting is used) - Replace placeholder "getter" methods with full-featured equivalents to existing MS Teams methods - Add new "getter" methods to cover new functionality - Add flags, environment variables to cover new functionality - Rename existing generically named functions used for Teams notification handling to explicitly mention relation to Teams notifications - this was needed to make room for email-specific notification functionality - Rework some existing Teams-specific functions to allow use with Teams and email notifications (DRY) - Add email-specific functions, methods, types to mirror existing Microsoft Teams notifications support - Replace placeholder email notification template with a "default", mostly text-only friendly format and a Textile formatted template to be used with older Redmine systems (prior to Markdown support being introduced) - `MessageTrailer` func updated to take a template string for generation of a format-specific branding string - e.g., Textile-formatted repo link or Markdown-formatted repo link - Update config Stringer interface - it is growing quite large at this point, might be time to rethink how it is handled - TOML configuration file - extended with new settings - rename some settings in an effort to better communicate intent REFERENCES - refs GH-3 - https://golangcode.com/validate-an-email-address/ - https://www.w3.org/TR/2016/REC-html51-20161101/sec-forms.html - https://github.com/Showmax/go-fqdn

SUMMARY This commit adds support for sending email notifications using the same behavioral feature set as Microsoft Teams notifications: - configurable retries and retry delay - configurable rate limit - a separate notification per event - e.g., request received, username disabled, sessions terminated The following settings are configurable: - destination email address(es) - sender address - SMTP server IP/FQDN - SMTP server port - client identity - hostname provided to the SMTP server - as noted elsewhere, some SMTP servers will perform forward/reverse DNS lookups to confirm that this provided value matches what DNS has recorded for the sending IP Address Some known weaknesses/lack of support: - hard-coded email template - as of this commit, the template using Textile formatting is enabled - future efforts are intended to move hard-coded templates out of source code constants to on-disk files for easier customization by the sysadmin(s) supporting this application - unauthenticated connections to SMTP server - the initial use-case is a local relay which restricts connections based on source IP Address - future efforts are intended to provide support for authentication Behavior worth noting: - automatic client identity value generated from available DNS information if not specified by the sysadmin - the `Showmax/go-fqdn` package is used to retrieve the FQDN of the sending system, with a fallback to - email address verification applied using the provided W3C regex - using a guide from golangcode.com CHANGES The following items note (non-exhaustive) changes since the last point release. Many of these changes will see further refactoring as part of GH-22. - Duplicate client/alert request headers so that in-place formatting modifications performed on values in the slice do not spill over to the values used for email notifications (where a different formatting is used) - Replace placeholder "getter" methods with full-featured equivalents to existing MS Teams methods - Add new "getter" methods to cover new functionality - Add flags, environment variables to cover new functionality - Rename existing generically named functions used for Teams notification handling to explicitly mention relation to Teams notifications - this was needed to make room for email-specific notification functionality - Rework some existing Teams-specific functions to allow use with Teams and email notifications (DRY) - Add email-specific functions, methods, types to mirror existing Microsoft Teams notifications support - Replace placeholder email notification template with a "default", mostly text-only friendly format and a Textile formatted template to be used with older Redmine systems (prior to Markdown support being introduced) - `MessageTrailer` func updated to take a template string for generation of a format-specific branding string - e.g., Textile-formatted repo link or Markdown-formatted repo link - Update config Stringer interface - it is growing quite large at this point, might be time to rethink how it is handled - TOML configuration file - extended with new settings - rename some settings in an effort to better communicate intent - Documentation - Cover new flags, environment variables and config file settings - Misc fixes for existing rate limit, number of retries and retry delay - Refresh existing setup/deploy steps to briefly cover email configuration REFERENCES - refs GH-3 - https://golangcode.com/validate-an-email-address/ - https://www.w3.org/TR/2016/REC-html51-20161101/sec-forms.html - https://github.com/Showmax/go-fqdn

atc0005 mentioned this issue Jan 24, 2020

Feature: Add support for Microsoft Teams notifications #4

Closed

atc0005 changed the title ~~Add support for email notifications when blocking user~~ Feature: Add support for email notifications when blocking user Mar 6, 2020

atc0005 added enhancement New feature or request email notification labels Mar 6, 2020

atc0005 added the template label Mar 15, 2020

atc0005 modified the milestones: Futrue, Future, v0.3.0 May 3, 2020

atc0005 changed the title ~~Feature: Add support for email notifications when blocking user~~ Feature: Add support for email notifications when disabling user May 19, 2020

atc0005 pinned this issue May 19, 2020

atc0005 mentioned this issue Jul 9, 2020

Notification delays and timeouts are not clear #85

Closed

atc0005 mentioned this issue Jul 11, 2020

Retry delay: Update flag, vars and docs to clarify #87

Merged

atc0005 mentioned this issue Jul 11, 2020

Expose Teams notifications rate limit setting #88

Merged

atc0005 mentioned this issue Jul 17, 2020

Add support for email notifications #97

Merged

atc0005 closed this as completed in #97 Jul 18, 2020

atc0005 unpinned this issue Jul 18, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feature: Add support for email notifications when disabling user #3

Feature: Add support for email notifications when disabling user #3

atc0005 commented Jan 24, 2020 •

edited

Loading

atc0005 commented Jun 29, 2020

atc0005 commented Jun 29, 2020

atc0005 commented Jul 9, 2020

atc0005 commented Jul 9, 2020

atc0005 commented Jul 9, 2020

atc0005 commented Jul 11, 2020

atc0005 commented Jul 13, 2020

atc0005 commented Jul 13, 2020

Feature: Add support for email notifications when disabling user #3

Feature: Add support for email notifications when disabling user #3

Comments

atc0005 commented Jan 24, 2020 • edited Loading

atc0005 commented Jun 29, 2020

atc0005 commented Jun 29, 2020

atc0005 commented Jul 9, 2020

atc0005 commented Jul 9, 2020

atc0005 commented Jul 9, 2020

atc0005 commented Jul 11, 2020

atc0005 commented Jul 13, 2020

atc0005 commented Jul 13, 2020

atc0005 commented Jan 24, 2020 •

edited

Loading