You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
johnnyshields
changed the title
Move settings.security Hash parameters to be regular parameters.
v2.0: Move settings.security Hash parameters to be regular parameters.
Jul 9, 2024
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.
johnnyshields
changed the title
v2.0: Move settings.security Hash parameters to be regular parameters.
Future: Move settings.security Hash parameters to be regular parameters.
Jul 9, 2024
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.The text was updated successfully, but these errors were encountered: