How did you learn about the ability to terminate a user session via 'kill' subcommand? #1
Comments
|
Hi Adam,
I found the command on the ezproxy listserv from Chris Zagar in a message
dated Dec 4, 2015
*It is possible to kill an existing session from the command line
using:ezproxy kill (sessionid)Chris *
The OCLC documentation and support is not quite as good as when it was when
Chris was running the show.
Good luck with your project.
Calvin
…On Wed, Jun 10, 2020 at 5:20 AM Adam Chalkley ***@***.***> wrote:
Hi,
I've been in touch with OCLC Support recently about a way to
programatically terminate EZproxy user sessions. I asked for a way to do it
via an API, command-line, *any* way at all to terminate sessions aside
from using the web admin UI. They've told me that it's not available and
pointed me at various other approaches that in the end don't do what I need.
I stumbled across this project and saw that you've been doing it, and
after testing found that it continues to work with the version of EZproxy
we're currently using.
Since the EZproxy documentation doesn't listed the subcommand, and even
the help output generated by the application itself doesn't list the
subcommand, how did you discover it?
I've been working on a project with similar goals that uses a more
complicated solution; I am now working to implement the same session
termination support using the ezproxy kill subcommand. I'm mostly curious
how you learned of the subcommand, but am also trying to get a sense of how
widely the option is known as a potential measurement of how likely it
would be that OCLC would yank out that subcommand in a future release.
Thanks in advance for your feedback.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAII53GSXOUTMG7FYYIJ5ODRV527ZANCNFSM4N2KQOSA>
.
|
|
@calvinm Thanks! I appreciate you take the time to respond. |
atc0005
added a commit
to atc0005/brick
that referenced
this issue
Jun 30, 2020
BACKSTORY Not long after giving a demo on using brick + fail2ban to timeout existing sessions, I stumbled across another project on GitHub which uses `ezproxy kill` to terminate an active user session: - https://github.com/calvinm/ezproxy-abuse-checker/blob/d7202e617305745cf272df9918b1e95ff030f63f/block_user.pl#L32 - https://github.com/calvinm/ezproxy-abuse-checker/blob/master/block_user.pl Despite OCLC Support indicating otherwise, native support for terminating user sessions was clearly available. This built-in support offers a much safer/localized effect vs banning the IP associated with a reported account; banning the IP has the potential to have a much larger splash radius blocking legitimate user accounts. The primary developer for the `calvinm/ezproxy-abuse-checker` project confirmed that they learned of this support on the EZProxy mailing list: calvinm/ezproxy-abuse-checker#1 This is encouraging, as I am (at least a little) optimistic that this unpublished support will persist in future versions, at least until official, fully documented and supported functionality for terminating sessions is included. IMPLEMENTATION This commit adds (optional) support for terminating user sessions using the official EZProxy binary already present on EZproxy servers. The fully-qualified location of this binary is configurable via command-line flag, environment variable or TOML-format configuration file. Additional settings are provided to tune the sessions search process such as configurable retries and search delay. The session termination process involves reading current sessions from the Active Users and Hosts "state" file that EZproxy uses to track sessions and hosts managed by EZProxy and then using the EZproxy binary to terminate each session via the `kill` subcommand. As part of the early development efforts I initially tried to use the latest Audit logs to pull session IDs, but quickly realized that while the format was easier to parse, it was far less stable due to log rotation and the need to resolve the active state ourselves (logins minus logouts, minus timeouts, etc). Some of that support still remains as of this commit, but may be removed in a future release if found to not be needed. As of this writing I believe it can still be used as part of interacting with a future endpoint. The aforementioned search delay and retry settings are provided to work around an observed race condition between EZproxy recording state changes and other applications (such as ours) attempting to read the current state. The delay in EZproxy writing the changes to disk (or kernel settings?) may result in our application attempting to terminate sessions related to a monitoring system report and not finding them within the Active Users and Hosts "state" file. The defaults attempt to strike a balance between waiting a little longer in order to "find" and terminate those sessions vs moving on with current findings. The defaults may need to be adjusted further depending on the production environment. TEAMS NOTIFICATIONS Minor changes in an effort to better clarify the purpose of the lead-in content: - explicit `step X of Y` labeling to notification titles - consistent use of Note (preferred) and Error (fallback) field values to generate primary "summary" text - rename "Request Annotations" to "Request Errors" to reflect dedicated single purpose vs blend of Note and Error field values as before ADDITIONAL SUPPORT During development, the necessary code to interact with EZProxy was first created as a local package, but was eventually moved to a separate module in order to break out the changes for separate use. See the `atc0005/go-ezproxy` project for further information on that module. Two separate binaries were created during testing: - mock `ezproxy` binary which returns known return codes and results + some extra to help condition validation checks for what I believe will be unknown/unpublished return codes I've yet to encounter - `es` binary used to search for and optionally terminate active user sessions for a specified username. This binary supports the same search retry and delay settings as `brick` refs GH-31, GH-59
atc0005
added a commit
to atc0005/brick
that referenced
this issue
Jun 30, 2020
BACKSTORY Not long after giving a demo on using brick + fail2ban to timeout existing sessions, I stumbled across another project on GitHub which uses `ezproxy kill` to terminate an active user session: - https://github.com/calvinm/ezproxy-abuse-checker/blob/d7202e617305745cf272df9918b1e95ff030f63f/block_user.pl#L32 - https://github.com/calvinm/ezproxy-abuse-checker/blob/master/block_user.pl Despite OCLC Support indicating otherwise, native support for terminating user sessions was clearly available. This built-in support offers a much safer/localized effect vs banning the IP associated with a reported account; banning the IP has the potential to have a much larger splash radius blocking legitimate user accounts. The primary developer for the `calvinm/ezproxy-abuse-checker` project confirmed that they learned of this support on the EZProxy mailing list: calvinm/ezproxy-abuse-checker#1 This is encouraging, as I am (at least a little) optimistic that this unpublished support will persist in future versions, at least until official, fully documented and supported functionality for terminating sessions is included. IMPLEMENTATION This commit adds (optional) support for terminating user sessions using the official EZProxy binary already present on EZproxy servers. The fully-qualified location of this binary is configurable via command-line flag, environment variable or TOML-format configuration file. Additional settings are provided to tune the sessions search process such as configurable retries and search delay. The session termination process involves reading current sessions from the Active Users and Hosts "state" file that EZproxy uses to track sessions and hosts managed by EZProxy and then using the EZproxy binary to terminate each session via the `kill` subcommand. As part of the early development efforts I initially tried to use the latest Audit logs to pull session IDs, but quickly realized that while the format was easier to parse, it was far less stable due to log rotation and the need to resolve the active state ourselves (logins minus logouts, minus timeouts, etc). Some of that support still remains as of this commit, but may be removed in a future release if found to not be needed. As of this writing I believe it can still be used as part of interacting with a future endpoint. The aforementioned search delay and retry settings are provided to work around an observed race condition between EZproxy recording state changes and other applications (such as ours) attempting to read the current state. The delay in EZproxy writing the changes to disk (or kernel settings?) may result in our application attempting to terminate sessions related to a monitoring system report and not finding them within the Active Users and Hosts "state" file. The defaults attempt to strike a balance between waiting a little longer in order to "find" and terminate those sessions vs moving on with current findings. The defaults may need to be adjusted further depending on the production environment. TEAMS NOTIFICATIONS Minor changes in an effort to better clarify the purpose of the lead-in content: - explicit `step X of Y` labeling to notification titles - consistent use of Note (preferred) and Error (fallback) field values to generate primary "summary" text - rename "Request Annotations" to "Request Errors" to reflect dedicated single purpose vs blend of Note and Error field values as before ADDITIONAL SUPPORT During development, the necessary code to interact with EZProxy was first created as a local package, but was eventually moved to a separate module in order to break out the changes for separate use. See the `atc0005/go-ezproxy` project for further information on that module. Two separate binaries were created during testing: - mock `ezproxy` binary which returns known return codes and results + some extra to help condition validation checks for what I believe will be unknown/unpublished return codes I've yet to encounter - `es` binary used to search for and optionally terminate active user sessions for a specified username. This binary supports the same search retry and delay settings as `brick` refs GH-31, GH-59
atc0005
added a commit
to atc0005/brick
that referenced
this issue
Jun 30, 2020
BACKSTORY Not long after giving a demo on using brick + fail2ban to timeout existing sessions, I stumbled across another project on GitHub which uses `ezproxy kill` to terminate an active user session: - https://github.com/calvinm/ezproxy-abuse-checker/blob/d7202e617305745cf272df9918b1e95ff030f63f/block_user.pl#L32 - https://github.com/calvinm/ezproxy-abuse-checker/blob/master/block_user.pl Despite OCLC Support indicating otherwise, native support for terminating user sessions was clearly available. This built-in support offers a much safer/localized effect vs banning the IP associated with a reported account; banning the IP has the potential to have a much larger splash radius blocking legitimate user accounts. The primary developer for the `calvinm/ezproxy-abuse-checker` project confirmed that they learned of this support on the EZProxy mailing list: calvinm/ezproxy-abuse-checker#1 This is encouraging, as I am (at least a little) optimistic that this unpublished support will persist in future versions, at least until official, fully documented and supported functionality for terminating sessions is included. IMPLEMENTATION This commit adds (optional) support for terminating user sessions using the official EZProxy binary already present on EZproxy servers. The fully-qualified location of this binary is configurable via command-line flag, environment variable or TOML-format configuration file. Additional settings are provided to tune the sessions search process such as configurable retries and search delay. The session termination process involves reading current sessions from the Active Users and Hosts "state" file that EZproxy uses to track sessions and hosts managed by EZProxy and then using the EZproxy binary to terminate each session via the `kill` subcommand. As part of the early development efforts I initially tried to use the latest Audit logs to pull session IDs, but quickly realized that while the format was easier to parse, it was far less stable due to log rotation and the need to resolve the active state ourselves (logins minus logouts, minus timeouts, etc). Some of that support still remains as of this commit, but may be removed in a future release if found to not be needed. As of this writing I believe it can still be used as part of interacting with a future endpoint. The aforementioned search delay and retry settings are provided to work around an observed race condition between EZproxy recording state changes and other applications (such as ours) attempting to read the current state. The delay in EZproxy writing the changes to disk (or kernel settings?) may result in our application attempting to terminate sessions related to a monitoring system report and not finding them within the Active Users and Hosts "state" file. The defaults attempt to strike a balance between waiting a little longer in order to "find" and terminate those sessions vs moving on with current findings. The defaults may need to be adjusted further depending on the production environment. TEAMS NOTIFICATIONS Minor changes in an effort to better clarify the purpose of the lead-in content: - explicit `step X of Y` labeling to notification titles - consistent use of Note (preferred) and Error (fallback) field values to generate primary "summary" text - rename "Request Annotations" to "Request Errors" to reflect dedicated single purpose vs blend of Note and Error field values as before ADDITIONAL SUPPORT During development, the necessary code to interact with EZProxy was first created as a local package, but was eventually moved to a separate module in order to break out the changes for separate use. See the `atc0005/go-ezproxy` project for further information on that module. Two separate binaries were created during testing: - mock `ezproxy` binary which returns known return codes and results + some extra to help condition validation checks for what I believe will be unknown/unpublished return codes I've yet to encounter - `es` binary used to search for and optionally terminate active user sessions for a specified username. This binary supports the same search retry and delay settings as `brick` refs GH-31, GH-59
atc0005
added a commit
to atc0005/brick
that referenced
this issue
Jun 30, 2020
BACKSTORY Not long after giving a demo on using brick + fail2ban to timeout existing sessions, I stumbled across another project on GitHub which uses `ezproxy kill` to terminate an active user session: - https://github.com/calvinm/ezproxy-abuse-checker/blob/d7202e617305745cf272df9918b1e95ff030f63f/block_user.pl#L32 - https://github.com/calvinm/ezproxy-abuse-checker/blob/master/block_user.pl Despite OCLC Support indicating otherwise, native support for terminating user sessions was clearly available. This built-in support offers a much safer/localized effect vs banning the IP associated with a reported account; banning the IP has the potential to have a much larger splash radius blocking legitimate user accounts. The primary developer for the `calvinm/ezproxy-abuse-checker` project confirmed that they learned of this support on the EZProxy mailing list: calvinm/ezproxy-abuse-checker#1 This is encouraging, as I am (at least a little) optimistic that this unpublished support will persist in future versions, at least until official, fully documented and supported functionality for terminating sessions is included. IMPLEMENTATION This commit adds (optional) support for terminating user sessions using the official EZProxy binary already present on EZproxy servers. The fully-qualified location of this binary is configurable via command-line flag, environment variable or TOML-format configuration file. Additional settings are provided to tune the sessions search process such as configurable retries and search delay. The session termination process involves reading current sessions from the Active Users and Hosts "state" file that EZproxy uses to track sessions and hosts managed by EZProxy and then using the EZproxy binary to terminate each session via the `kill` subcommand. As part of the early development efforts I initially tried to use the latest Audit logs to pull session IDs, but quickly realized that while the format was easier to parse, it was far less stable due to log rotation and the need to resolve the active state ourselves (logins minus logouts, minus timeouts, etc). Some of that support still remains as of this commit, but may be removed in a future release if found to not be needed. As of this writing I believe it can still be used as part of interacting with a future endpoint. The aforementioned search delay and retry settings are provided to work around an observed race condition between EZproxy recording state changes and other applications (such as ours) attempting to read the current state. The delay in EZproxy writing the changes to disk (or kernel settings?) may result in our application attempting to terminate sessions related to a monitoring system report and not finding them within the Active Users and Hosts "state" file. The defaults attempt to strike a balance between waiting a little longer in order to "find" and terminate those sessions vs moving on with current findings. The defaults may need to be adjusted further depending on the production environment. TEAMS NOTIFICATIONS Minor changes in an effort to better clarify the purpose of the lead-in content: - explicit `step X of Y` labeling to notification titles - consistent use of Note (preferred) and Error (fallback) field values to generate primary "summary" text - rename "Request Annotations" to "Request Errors" to reflect dedicated single purpose vs blend of Note and Error field values as before ADDITIONAL SUPPORT During development, the necessary code to interact with EZProxy was first created as a local package, but was eventually moved to a separate module in order to break out the changes for separate use. See the `atc0005/go-ezproxy` project for further information on that module. Two separate binaries were created during testing: - mock `ezproxy` binary which returns known return codes and results + some extra to help condition validation checks for what I believe will be unknown/unpublished return codes I've yet to encounter - `es` binary used to search for and optionally terminate active user sessions for a specified username. This binary supports the same search retry and delay settings as `brick` refs GH-31, GH-59
atc0005
added a commit
to atc0005/brick
that referenced
this issue
Jun 30, 2020
BACKSTORY Not long after giving a demo on using brick + fail2ban to timeout existing sessions, I stumbled across another project on GitHub which uses `ezproxy kill` to terminate an active user session: - https://github.com/calvinm/ezproxy-abuse-checker/blob/d7202e617305745cf272df9918b1e95ff030f63f/block_user.pl#L32 - https://github.com/calvinm/ezproxy-abuse-checker/blob/master/block_user.pl Despite OCLC Support indicating otherwise, native support for terminating user sessions was clearly available. This built-in support offers a much safer/localized effect vs banning the IP associated with a reported account; banning the IP has the potential to have a much larger splash radius blocking legitimate user accounts. The primary developer for the `calvinm/ezproxy-abuse-checker` project confirmed that they learned of this support on the EZProxy mailing list: calvinm/ezproxy-abuse-checker#1 This is encouraging, as I am (at least a little) optimistic that this unpublished support will persist in future versions, at least until official, fully documented and supported functionality for terminating sessions is included. IMPLEMENTATION This commit adds (optional) support for terminating user sessions using the official EZProxy binary already present on EZproxy servers. The fully-qualified location of this binary is configurable via command-line flag, environment variable or TOML-format configuration file. Additional settings are provided to tune the sessions search process such as configurable retries and search delay. The session termination process involves reading current sessions from the Active Users and Hosts "state" file that EZproxy uses to track sessions and hosts managed by EZProxy and then using the EZproxy binary to terminate each session via the `kill` subcommand. As part of the early development efforts I initially tried to use the latest Audit logs to pull session IDs, but quickly realized that while the format was easier to parse, it was far less stable due to log rotation and the need to resolve the active state ourselves (logins minus logouts, minus timeouts, etc). Some of that support still remains as of this commit, but may be removed in a future release if found to not be needed. As of this writing I believe it can still be used as part of interacting with a future endpoint. The aforementioned search delay and retry settings are provided to work around an observed race condition between EZproxy recording state changes and other applications (such as ours) attempting to read the current state. The delay in EZproxy writing the changes to disk (or kernel settings?) may result in our application attempting to terminate sessions related to a monitoring system report and not finding them within the Active Users and Hosts "state" file. The defaults attempt to strike a balance between waiting a little longer in order to "find" and terminate those sessions vs moving on with current findings. The defaults may need to be adjusted further depending on the production environment. TEAMS NOTIFICATIONS Minor changes in an effort to better clarify the purpose of the lead-in content: - explicit `step X of Y` labeling to notification titles - consistent use of Note (preferred) and Error (fallback) field values to generate primary "summary" text - rename "Request Annotations" to "Request Errors" to reflect dedicated single purpose vs blend of Note and Error field values as before ADDITIONAL SUPPORT During development, the necessary code to interact with EZProxy was first created as a local package, but was eventually moved to a separate module in order to break out the changes for separate use. See the `atc0005/go-ezproxy` project for further information on that module. Two separate binaries were created during testing: - mock `ezproxy` binary which returns known return codes and results + some extra to help condition validation checks for what I believe will be unknown/unpublished return codes I've yet to encounter - `es` binary used to search for and optionally terminate active user sessions for a specified username. This binary supports the same search retry and delay settings as `brick` refs GH-31, GH-59
atc0005
added a commit
to atc0005/brick
that referenced
this issue
Jun 30, 2020
BACKSTORY Not long after giving a demo on using brick + fail2ban to timeout existing sessions, I stumbled across another project on GitHub which uses `ezproxy kill` to terminate an active user session: - https://github.com/calvinm/ezproxy-abuse-checker/blob/d7202e617305745cf272df9918b1e95ff030f63f/block_user.pl#L32 - https://github.com/calvinm/ezproxy-abuse-checker/blob/master/block_user.pl Despite OCLC Support indicating otherwise, native support for terminating user sessions was clearly available. This built-in support offers a much safer/localized effect vs banning the IP associated with a reported account; banning the IP has the potential to have a much larger splash radius blocking legitimate user accounts. The primary developer for the `calvinm/ezproxy-abuse-checker` project confirmed that they learned of this support on the EZProxy mailing list: calvinm/ezproxy-abuse-checker#1 This is encouraging, as I am (at least a little) optimistic that this unpublished support will persist in future versions, at least until official, fully documented and supported functionality for terminating sessions is included. IMPLEMENTATION This commit adds (optional) support for terminating user sessions using the official EZProxy binary already present on EZproxy servers. The fully-qualified location of this binary is configurable via command-line flag, environment variable or TOML-format configuration file. Additional settings are provided to tune the sessions search process such as configurable retries and search delay. The session termination process involves reading current sessions from the Active Users and Hosts "state" file that EZproxy uses to track sessions and hosts managed by EZProxy and then using the EZproxy binary to terminate each session via the `kill` subcommand. As part of the early development efforts I initially tried to use the latest Audit logs to pull session IDs, but quickly realized that while the format was easier to parse, it was far less stable due to log rotation and the need to resolve the active state ourselves (logins minus logouts, minus timeouts, etc). Some of that support still remains as of this commit, but may be removed in a future release if found to not be needed. As of this writing I believe it can still be used as part of interacting with a future endpoint. The aforementioned search delay and retry settings are provided to work around an observed race condition between EZproxy recording state changes and other applications (such as ours) attempting to read the current state. The delay in EZproxy writing the changes to disk (or kernel settings?) may result in our application attempting to terminate sessions related to a monitoring system report and not finding them within the Active Users and Hosts "state" file. The defaults attempt to strike a balance between waiting a little longer in order to "find" and terminate those sessions vs moving on with current findings. The defaults may need to be adjusted further depending on the production environment. TEAMS NOTIFICATIONS Minor changes in an effort to better clarify the purpose of the lead-in content: - explicit `step X of Y` labeling to notification titles - consistent use of Note (preferred) and Error (fallback) field values to generate primary "summary" text - rename "Request Annotations" to "Request Errors" to reflect dedicated single purpose vs blend of Note and Error field values as before ADDITIONAL SUPPORT During development, the necessary code to interact with EZProxy was first created as a local package, but was eventually moved to a separate module in order to break out the changes for separate use. See the `atc0005/go-ezproxy` project for further information on that module. Two separate binaries were created during testing: - mock `ezproxy` binary which returns known return codes and results + some extra to help condition validation checks for what I believe will be unknown/unpublished return codes I've yet to encounter - `es` binary used to search for and optionally terminate active user sessions for a specified username. This binary supports the same search retry and delay settings as `brick` refs GH-31, GH-59
atc0005
added a commit
to atc0005/brick
that referenced
this issue
Jun 30, 2020
BACKSTORY Not long after giving a demo on using brick + fail2ban to timeout existing sessions, I stumbled across another project on GitHub which uses `ezproxy kill` to terminate an active user session: - https://github.com/calvinm/ezproxy-abuse-checker/blob/d7202e617305745cf272df9918b1e95ff030f63f/block_user.pl#L32 - https://github.com/calvinm/ezproxy-abuse-checker/blob/master/block_user.pl Despite OCLC Support indicating otherwise, native support for terminating user sessions was clearly available. This built-in support offers a much safer/localized effect vs banning the IP associated with a reported account; banning the IP has the potential to have a much larger splash radius blocking legitimate user accounts. The primary developer for the `calvinm/ezproxy-abuse-checker` project confirmed that they learned of this support on the EZProxy mailing list: calvinm/ezproxy-abuse-checker#1 This is encouraging, as I am (at least a little) optimistic that this unpublished support will persist in future versions, at least until official, fully documented and supported functionality for terminating sessions is included. IMPLEMENTATION This commit adds (optional) support for terminating user sessions using the official EZProxy binary already present on EZproxy servers. The fully-qualified location of this binary is configurable via command-line flag, environment variable or TOML-format configuration file. Additional settings are provided to tune the sessions search process such as configurable retries and search delay. The session termination process involves reading current sessions from the Active Users and Hosts "state" file that EZproxy uses to track sessions and hosts managed by EZProxy and then using the EZproxy binary to terminate each session via the `kill` subcommand. As part of the early development efforts I initially tried to use the latest Audit logs to pull session IDs, but quickly realized that while the format was easier to parse, it was far less stable due to log rotation and the need to resolve the active state ourselves (logins minus logouts, minus timeouts, etc). Some of that support still remains as of this commit, but may be removed in a future release if found to not be needed. As of this writing I believe it can still be used as part of interacting with a future endpoint. The aforementioned search delay and retry settings are provided to work around an observed race condition between EZproxy recording state changes and other applications (such as ours) attempting to read the current state. The delay in EZproxy writing the changes to disk (or kernel settings?) may result in our application attempting to terminate sessions related to a monitoring system report and not finding them within the Active Users and Hosts "state" file. The defaults attempt to strike a balance between waiting a little longer in order to "find" and terminate those sessions vs moving on with current findings. The defaults may need to be adjusted further depending on the production environment. TEAMS NOTIFICATIONS Minor changes in an effort to better clarify the purpose of the lead-in content: - explicit `step X of Y` labeling to notification titles - consistent use of Note (preferred) and Error (fallback) field values to generate primary "summary" text - rename "Request Annotations" to "Request Errors" to reflect dedicated single purpose vs blend of Note and Error field values as before ADDITIONAL SUPPORT During development, the necessary code to interact with EZProxy was first created as a local package, but was eventually moved to a separate module in order to break out the changes for separate use. See the `atc0005/go-ezproxy` project for further information on that module. Two separate binaries were created during testing: - mock `ezproxy` binary which returns known return codes and results + some extra to help condition validation checks for what I believe will be unknown/unpublished return codes I've yet to encounter - `es` binary used to search for and optionally terminate active user sessions for a specified username. This binary supports the same search retry and delay settings as `brick` refs GH-31, GH-59
atc0005
added a commit
to atc0005/brick
that referenced
this issue
Jun 30, 2020
BACKSTORY Not long after giving a demo on using brick + fail2ban to timeout existing sessions, I stumbled across another project on GitHub which uses `ezproxy kill` to terminate an active user session: - https://github.com/calvinm/ezproxy-abuse-checker/blob/d7202e617305745cf272df9918b1e95ff030f63f/block_user.pl#L32 - https://github.com/calvinm/ezproxy-abuse-checker/blob/master/block_user.pl Despite OCLC Support indicating otherwise, native support for terminating user sessions was clearly available. This built-in support offers a much safer/localized effect vs banning the IP associated with a reported account; banning the IP has the potential to have a much larger splash radius blocking legitimate user accounts. The primary developer for the `calvinm/ezproxy-abuse-checker` project confirmed that they learned of this support on the EZProxy mailing list: calvinm/ezproxy-abuse-checker#1 This is encouraging, as I am (at least a little) optimistic that this unpublished support will persist in future versions, at least until official, fully documented and supported functionality for terminating sessions is included. IMPLEMENTATION This commit adds (optional) support for terminating user sessions using the official EZProxy binary already present on EZproxy servers. The fully-qualified location of this binary is configurable via command-line flag, environment variable or TOML-format configuration file. Additional settings are provided to tune the sessions search process such as configurable retries and search delay. The session termination process involves reading current sessions from the Active Users and Hosts "state" file that EZproxy uses to track sessions and hosts managed by EZProxy and then using the EZproxy binary to terminate each session via the `kill` subcommand. As part of the early development efforts I initially tried to use the latest Audit logs to pull session IDs, but quickly realized that while the format was easier to parse, it was far less stable due to log rotation and the need to resolve the active state ourselves (logins minus logouts, minus timeouts, etc). Some of that support still remains as of this commit, but may be removed in a future release if found to not be needed. As of this writing I believe it can still be used as part of interacting with a future endpoint. The aforementioned search delay and retry settings are provided to work around an observed race condition between EZproxy recording state changes and other applications (such as ours) attempting to read the current state. The delay in EZproxy writing the changes to disk (or kernel settings?) may result in our application attempting to terminate sessions related to a monitoring system report and not finding them within the Active Users and Hosts "state" file. The defaults attempt to strike a balance between waiting a little longer in order to "find" and terminate those sessions vs moving on with current findings. The defaults may need to be adjusted further depending on the production environment. TEAMS NOTIFICATIONS Minor changes in an effort to better clarify the purpose of the lead-in content: - explicit `step X of Y` labeling to notification titles - consistent use of Note (preferred) and Error (fallback) field values to generate primary "summary" text - rename "Request Annotations" to "Request Errors" to reflect dedicated single purpose vs blend of Note and Error field values as before ADDITIONAL SUPPORT During development, the necessary code to interact with EZProxy was first created as a local package, but was eventually moved to a separate module in order to break out the changes for separate use. See the `atc0005/go-ezproxy` project for further information on that module. Two separate binaries were created during testing: - mock `ezproxy` binary which returns known return codes and results + some extra to help condition validation checks for what I believe will be unknown/unpublished return codes I've yet to encounter - `es` binary used to search for and optionally terminate active user sessions for a specified username. This binary supports the same search retry and delay settings as `brick` refs GH-31, GH-59
atc0005
added a commit
to atc0005/brick
that referenced
this issue
Jun 30, 2020
BACKSTORY Not long after giving a demo on using brick + fail2ban to timeout existing sessions, I stumbled across another project on GitHub which uses `ezproxy kill` to terminate an active user session: - https://github.com/calvinm/ezproxy-abuse-checker/blob/d7202e617305745cf272df9918b1e95ff030f63f/block_user.pl#L32 - https://github.com/calvinm/ezproxy-abuse-checker/blob/master/block_user.pl Despite OCLC Support indicating otherwise, native support for terminating user sessions was clearly available. This built-in support offers a much safer/localized effect vs banning the IP associated with a reported account; banning the IP has the potential to have a much larger splash radius blocking legitimate user accounts. The primary developer for the `calvinm/ezproxy-abuse-checker` project confirmed that they learned of this support on the EZProxy mailing list: calvinm/ezproxy-abuse-checker#1 This is encouraging, as I am (at least a little) optimistic that this unpublished support will persist in future versions, at least until official, fully documented and supported functionality for terminating sessions is included. IMPLEMENTATION This commit adds (optional) support for terminating user sessions using the official EZProxy binary already present on EZproxy servers. The fully-qualified location of this binary is configurable via command-line flag, environment variable or TOML-format configuration file. Additional settings are provided to tune the sessions search process such as configurable retries and search delay. The session termination process involves reading current sessions from the Active Users and Hosts "state" file that EZproxy uses to track sessions and hosts managed by EZProxy and then using the EZproxy binary to terminate each session via the `kill` subcommand. As part of the early development efforts I initially tried to use the latest Audit logs to pull session IDs, but quickly realized that while the format was easier to parse, it was far less stable due to log rotation and the need to resolve the active state ourselves (logins minus logouts, minus timeouts, etc). Some of that support still remains as of this commit, but may be removed in a future release if found to not be needed. As of this writing I believe it can still be used as part of interacting with a future endpoint. The aforementioned search delay and retry settings are provided to work around an observed race condition between EZproxy recording state changes and other applications (such as ours) attempting to read the current state. The delay in EZproxy writing the changes to disk (or kernel settings?) may result in our application attempting to terminate sessions related to a monitoring system report and not finding them within the Active Users and Hosts "state" file. The defaults attempt to strike a balance between waiting a little longer in order to "find" and terminate those sessions vs moving on with current findings. The defaults may need to be adjusted further depending on the production environment. TEAMS NOTIFICATIONS Minor changes in an effort to better clarify the purpose of the lead-in content: - explicit `step X of Y` labeling to notification titles - consistent use of Note (preferred) and Error (fallback) field values to generate primary "summary" text - rename "Request Annotations" to "Request Errors" to reflect dedicated single purpose vs blend of Note and Error field values as before ADDITIONAL SUPPORT During development, the necessary code to interact with EZProxy was first created as a local package, but was eventually moved to a separate module in order to break out the changes for separate use. See the `atc0005/go-ezproxy` project for further information on that module. Two separate binaries were created during testing: - mock `ezproxy` binary which returns known return codes and results + some extra to help condition validation checks for what I believe will be unknown/unpublished return codes I've yet to encounter - `es` binary used to search for and optionally terminate active user sessions for a specified username. This binary supports the same search retry and delay settings as `brick` refs GH-31, GH-59
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
I've been in touch with OCLC Support recently about a way to programatically terminate EZproxy user sessions. I asked for a way to do it via an API, command-line, any way at all to terminate sessions aside from using the web admin UI. They've told me that it's not available and pointed me at various other approaches that in the end don't do what I need.
I stumbled across this project and saw that you've been doing it, and after testing found that it continues to work with the version of EZproxy we're currently using.
Since the EZproxy documentation doesn't listed the subcommand, and even the help output generated by the application itself doesn't list the subcommand, how did you discover it?
I've been working on a project with similar goals that uses a more complicated solution; I am now working to implement the same session termination support using the
ezproxy killsubcommand. I'm mostly curious how you learned of the subcommand, but am also trying to get a sense of how widely the option is known as a potential measurement of how likely it would be that OCLC would yank out that subcommand in a future release.Thanks in advance for your feedback.
The text was updated successfully, but these errors were encountered: