bramvdbogaerde
Allow advanced validation of the cookie
With the introduction of private cookies in Rocket 0.3.0 the project removed the FromCookie trait that allowed users to create their own mechanism of storing cookies.
However, there are some use cases in which the user would want to have additional validation of the cookiestring aside of the validation that rocket provides.
This issue is created to invistigate this and to track the progress made on that.
There's still an option in Rocket to handle plain-text cookies by using the "add" and "get" functions instead of the "add_private" and "get_private" functions. So I think if someone wants to opt-out from the Rocket cookie encryption system and implement their own, it's possible. I was concentrating on making cookie encryption work out-of-the-box in my PR, but if this is a requirement, we can definitely create some generics for cookie handling for advanced users, but still using the Rocket internal handling by default for new users.
However when you say "additional validation", I imagine a validator trait for custom validations AFTER the cookie decryption happens. This could be used to check DBs and stuff based on the data received in the cookie.
Which option would you prefer? Do you think custom encryption is required or is it enough to provide a custom validator for decrypted cookies?
Thanks for your input.
I think the option to return another type than a string for user_id would be a meaningful addition.
The best way to do this in my opinion would be to use an extra type parameter and a trait that provides functions to serialise and deserialiaze the user specified type to a string that can be stored inside the private cookie.
The user can then decide to serialise a User struct to a user id. To deserialise it can make a connection to a database.
As for other encryption methods, I think we should stick with rocket private cookies but provide an option to the user to override this behaviour.
Alright. I implemented a way for the user to specify what kind the user field should be in UserPass. I also got rid of Authenticator::COOKIE_IDENTIFIER because I thought I didn't really belong there, because someone who implements Authenticator shouldn't worry about cookie storage, the library should handle that. Instead the correct cookie identifier is fetched from Rocket's config in case the user wants to change it.
It's looking good, I especially like the config option for the cookie identifier. The example login form is a good idea as well, could help a lot for new Rocket users.
One comment:
format!("Restricted administration area, user logged in with ID: {}", info.user)
This should be changed as well, the info.user is not an "ID" anymore.