Increase flexibility of SecretSource?

[gorhamc]

The existing SecretSource method is great and follows the RFC, as it should. However, relying on IP source to determine what secret should be used is difficult in very large environments that don't necessarily standardize IP space deployments. In my employer's use case, it would be much simpler to rely on something like Nas-Identifier.

Would you be open to supporting something like that? I'm happy to do a PR and discuss approaches further.

[Deleted user]

I'm open to suggestions. Please make a PR and I can review.

…

-------- Original Message --------

On Sep 26, 2020, 8:17 AM, Chris Gorham wrote: The existing SecretSource method is great and follows the RFC, as it should. However, relying on IP source to determine what secret should be used is difficult in very large environments that don't necessarily standardize IP space deployments. In my employer's use case, it would be much simpler to rely on something like Nas-Identifier. Would you be open to supporting something like that? I'm happy to do a PR and discuss approaches further. — You are receiving this because you are subscribed to this thread. Reply to this email directly, [view it on GitHub](#82), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAA3CI3QPR4AJUWJIIPGK2LSHXSWZANCNFSM4R24TP3Q).

[gorhamc]

Added a PR, please let me know what you think. I took an approach that would not impact any existing code using SecretSource.RADIUSSecret. If you are ok with a 'breaking' change, the cleaner/easier solution would be to simply add the []bytes parameter to that method, rather than a second interface like I have done in my first attempt.