Closed johnnyshields closed 4 months ago
I want to avoid more non-real necessary changes on 2.0
We can consider this in the future 2.1, but at the moment, I don't see it as a blocker. Also, I don't think we're going to deprecate more parameters from the security hash in the near future.
Agreed lets not do it for 2.0.
Currently a RubySaml::Settings object has some parameters which are normal settings, while there is a
security
method that returns a hash.We should get rid of the
security
Hash entirely, and migrate them to just be normal settings. One reason is that it's hard to control deprecation warnings for a hash.This could be done in a backward compatible fashion.
settings.security
could be made into a new "SettingsHash" object that extends Hash, but also sets the proper settings value.settings.security=
could coerce any Hash you set to the special SettingsHash object.