Adding a cookie validation interface to block disabled accounts #16
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
One thing I thought of was that if you disable the user account in the user repository, the user will still be authentified by the http module. And if the user has a persistent cookie, he can keep on having it refreshed and never expired, and keep on being logged even with a disabled account.
Same thing if the user changes his password. Any cookie on other browsers will still be valid, even if the password that was used to validate them has changed.
.
So I added a ICookieValidation interface, that allows the user repository to verify the cookie, i.e check the user account is not disabled , and if cookie date is > last password change date.
Injection of depedencies on an http module (loaded before the application_start) can be tricky, but http://haacked.com/archive/2011/06/03/dependency-injection-with-asp-net-httpmodules.aspx/ worked.