@ -0,0 +1,80 @@
|
||||
|
||||
use lettre_email::Email;
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
use std::env;
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
pub use self::mailer::*;
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
#[cfg(feature = "debug-mailer")]
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
mod mailer {
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
use lettre::{Transport, SendableEmail};
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
use std::{io::Read};
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
pub struct DebugTransport;
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
impl<'a> Transport<'a> for DebugTransport {
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
type Result = Result<(), ()>;
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
fn send(&mut self, email: SendableEmail) -> Self::Result {
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
println!(
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
"{}: from=<{}> to=<{:?}>\n{:#?}",
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
email.message_id().to_string(),
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
email.envelope().from().map(ToString::to_string).unwrap_or_default(),
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
email.envelope().to().to_vec(),
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
{
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
let mut message = String::new();
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
email.message().read_to_string(&mut message).map_err(|_| ())?;
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
message
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
},
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
);
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
Ok(())
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
}
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
}
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
pub type Mailer = Option<DebugTransport>;
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
pub fn init() -> Mailer {
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
Some(DebugTransport)
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
}
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
}
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
#[cfg(not(feature = "debug-mailer"))]
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
mod mailer {
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
use lettre::{
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
SmtpTransport,
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
SmtpClient,
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
smtp::{
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
authentication::{Credentials, Mechanism},
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
extension::ClientId,
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
ConnectionReuseParameters,
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
},
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
};
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
use std::env;
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
pub type Mailer = Option<SmtpTransport>;
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
pub fn init() -> Mailer {
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
let server = env::var("MAIL_SERVER").ok()?;
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
let helo_name = env::var("MAIL_HELO_NAME").unwrap_or_else(|_| "localhost".to_owned());
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
let username = env::var("MAIL_USER").ok()?;
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
let password = env::var("MAIL_PASSWORD").ok()?;
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
let mail = SmtpClient::new_simple(&server).unwrap()
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
.hello_name(ClientId::Domain(helo_name))
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
.credentials(Credentials::new(username, password))
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
.smtp_utf8(true)
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
.authentication_mechanism(Mechanism::Plain)
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
.connection_reuse(ConnectionReuseParameters::NoReuse)
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
.transport();
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
Some(mail)
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
}
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
}
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
pub fn build_mail(dest: String, subject: String, body: String) -> Option<Email> {
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
Email::builder()
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
.from(env::var("MAIL_ADDRESS")
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
.or_else(|_| Ok(format!("{}@{}", env::var("MAIL_USER")?, env::var("MAIL_SERVER")?)) as Result<_, env::VarError>)
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
.expect("Mail server is not correctly configured"))
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
.to(dest)
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
.subject(subject)
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
.text(body)
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
.build()
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
.ok()
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
||||
}
|
||||
trinity-1686a
commented 5 years ago
Review
you should reorder imports so all you should reorder imports so all `feature=debug` and all `not(feature=debug)` are segregated, it'll make thinks easier to read and maintain
The ideal may be to have 2 private mods, one `debug` and one `release` (or whatever), and re-export only the one enabled
trinity-1686a
commented 5 years ago
Review
Maybe this would be more at it's place in plume-model than in plume itself? Maybe this would be more at it's place in plume-model than in plume itself?
|
@ -1,19 +1,23 @@
|
||||
use lettre::Transport;
|
||||
use rocket::{
|
||||
State,
|
||||
http::{Cookie, Cookies, SameSite, uri::Uri},
|
||||
response::Redirect,
|
||||
request::{LenientForm,FlashMessage}
|
||||
request::{LenientForm, FlashMessage, Form}
|
||||
};
|
||||
use rocket::http::ext::IntoOwned;
|
||||
use rocket_i18n::I18n;
|
||||
use std::borrow::Cow;
|
||||
use std::{borrow::Cow, sync::{Arc, Mutex}, time::Instant};
|
||||
use validator::{Validate, ValidationError, ValidationErrors};
|
||||
use template_utils::Ructe;
|
||||
|
||||
use plume_models::{
|
||||
BASE_URL, Error,
|
||||
db_conn::DbConn,
|
||||
users::{User, AUTH_COOKIE}
|
||||
};
|
||||
|
||||
use mail::{build_mail, Mailer};
|
||||
use routes::errors::ErrorPage;
|
||||
|
||||
#[get("/login?<m>")]
|
||||
pub fn new(user: Option<User>, conn: DbConn, m: Option<String>, intl: I18n) -> Ructe {
|
||||
@ -76,7 +80,7 @@ pub fn create(conn: DbConn, form: LenientForm<LoginForm>, flash: Option<FlashMes
|
||||
|
||||
let uri = Uri::parse(&destination)
|
||||
.map(|x| x.into_owned())
|
||||
.map_err(|_| render!(session::login(
|
||||
.map_err(|_| render!(session::login(
|
||||
&(&*conn, &intl.catalog, None),
|
||||
None,
|
||||
&*form,
|
||||
@ -101,3 +105,140 @@ pub fn delete(mut cookies: Cookies) -> Redirect {
|
||||
}
|
||||
trinity-1686a
commented 5 years ago
Review
I think this statement could be made into a single function in I think this statement could be made into a single function in `src/mails.rs` (or wherever it move), which take in parameter subject and content, so it can be easily reused later if we send other kinds of mails (moderation warnings or whatever when it will get implemented)
trinity-1686a
commented 5 years ago
Review
15 minutes seems shorts, I'd advise something like 1 or 2 hours instead, mails can be long to transmit 15 minutes seems shorts, I'd advise something like 1 or 2 hours instead, mails can be long to transmit
trinity-1686a
commented 5 years ago
Review
to prevent the to prevent the `State<...>` from growing up in memory (basically be a memory leak), you should filter and eliminate old entries either with the internal scheduler, or somewhere like here
trinity-1686a
commented 5 years ago
Review
you should check if there haven't already be a link sent recently, otherwise one might use it to spam a user by sending them many reset links you should check if there haven't already be a link sent recently, otherwise one might use it to spam a user by sending them many reset links
|
||||
Redirect::to("/")
|
||||
}
|
||||
|
||||
#[derive(Clone)]
|
||||
pub struct ResetRequest {
|
||||
pub mail: String,
|
||||
pub id: String,
|
||||
pub creation_date: Instant,
|
||||
}
|
||||
|
||||
impl PartialEq for ResetRequest {
|
||||
fn eq(&self, other: &Self) -> bool {
|
||||
self.id == other.id
|
||||
}
|
||||
}
|
||||
|
||||
#[get("/password-reset")]
|
||||
pub fn password_reset_request_form(conn: DbConn, intl: I18n) -> Ructe {
|
||||
render!(session::password_reset_request(
|
||||
&(&*conn, &intl.catalog, None),
|
||||
&ResetForm::default(),
|
||||
ValidationErrors::default()
|
||||
))
|
||||
}
|
||||
|
||||
#[derive(FromForm, Validate, Default)]
|
||||
pub struct ResetForm {
|
||||
#[validate(email)]
|
||||
pub email: String,
|
||||
}
|
||||
|
||||
#[post("/password-reset", data = "<form>")]
|
||||
pub fn password_reset_request(
|
||||
conn: DbConn,
|
||||
intl: I18n,
|
||||
mail: State<Arc<Mutex<Mailer>>>,
|
||||
form: Form<ResetForm>,
|
||||
requests: State<Arc<Mutex<Vec<ResetRequest>>>>
|
||||
) -> Ructe {
|
||||
let mut requests = requests.lock().unwrap();
|
||||
// Remove outdated requests (more than 1 day old) to avoid the list to grow too much
|
||||
requests.retain(|r| r.creation_date.elapsed().as_secs() < 24 * 60 * 60);
|
||||
|
||||
if User::find_by_email(&*conn, &form.email).is_ok() && !requests.iter().any(|x| x.mail == form.email.clone()) {
|
||||
let id = plume_common::utils::random_hex();
|
||||
|
||||
requests.push(ResetRequest {
|
||||
mail: form.email.clone(),
|
||||
id: id.clone(),
|
||||
creation_date: Instant::now(),
|
||||
});
|
||||
|
||||
let link = format!("https://{}/password-reset/{}", *BASE_URL, id);
|
||||
if let Some(message) = build_mail(
|
||||
form.email.clone(),
|
||||
i18n!(intl.catalog, "Password reset"),
|
||||
i18n!(intl.catalog, "Here is the link to reset your password: {0}"; link)
|
||||
) {
|
||||
match *mail.lock().unwrap() {
|
||||
Some(ref mut mail) => { mail.send(message.into()).map_err(|_| eprintln!("Couldn't send password reset mail")).ok(); }
|
||||
None => {}
|
||||
}
|
||||
}
|
||||
}
|
||||
render!(session::password_reset_request_ok(
|
||||
&(&*conn, &intl.catalog, None)
|
||||
))
|
||||
}
|
||||
|
||||
#[get("/password-reset/<token>")]
|
||||
pub fn password_reset_form(conn: DbConn, intl: I18n, token: String, requests: State<Arc<Mutex<Vec<ResetRequest>>>>) -> Result<Ructe, ErrorPage> {
|
||||
requests.lock().unwrap().iter().find(|x| x.id == token.clone()).ok_or(Error::NotFound)?;
|
||||
Ok(render!(session::password_reset(
|
||||
&(&*conn, &intl.catalog, None),
|
||||
&NewPasswordForm::default(),
|
||||
ValidationErrors::default()
|
||||
)))
|
||||
}
|
||||
|
||||
#[derive(FromForm, Default, Validate)]
|
||||
#[validate(
|
||||
schema(
|
||||
function = "passwords_match",
|
||||
skip_on_field_errors = "false",
|
||||
message = "Passwords are not matching"
|
||||
)
|
||||
)]
|
||||
pub struct NewPasswordForm {
|
||||
pub password: String,
|
||||
pub password_confirmation: String,
|
||||
}
|
||||
|
||||
fn passwords_match(form: &NewPasswordForm) -> Result<(), ValidationError> {
|
||||
if form.password != form.password_confirmation {
|
||||
Err(ValidationError::new("password_match"))
|
||||
} else {
|
||||
Ok(())
|
||||
}
|
||||
}
|
||||
|
||||
#[post("/password-reset/<token>", data = "<form>")]
|
||||
pub fn password_reset(
|
||||
conn: DbConn,
|
||||
intl: I18n,
|
||||
token: String,
|
||||
requests: State<Arc<Mutex<Vec<ResetRequest>>>>,
|
||||
form: Form<NewPasswordForm>
|
||||
) -> Result<Redirect, Ructe> {
|
||||
form.validate()
|
||||
.and_then(|_| {
|
||||
let mut requests = requests.lock().unwrap();
|
||||
let req = requests.iter().find(|x| x.id == token.clone()).ok_or(to_validation(0))?.clone();
|
||||
if req.creation_date.elapsed().as_secs() < 60 * 60 * 2 { // Reset link is only valid for 2 hours
|
||||
requests.retain(|r| *r != req);
|
||||
let user = User::find_by_email(&*conn, &req.mail).map_err(to_validation)?;
|
||||
user.reset_password(&*conn, &form.password).ok();
|
||||
Ok(Redirect::to(uri!(new: m = i18n!(intl.catalog, "Your password was successfully reset."))))
|
||||
} else {
|
||||
Ok(Redirect::to(uri!(new: m = i18n!(intl.catalog, "Sorry, but the link expired. Try again"))))
|
||||
}
|
||||
})
|
||||
.map_err(|err| {
|
||||
render!(session::password_reset(
|
||||
&(&*conn, &intl.catalog, None),
|
||||
&form,
|
||||
err
|
||||
))
|
||||
})
|
||||
}
|
||||
|
||||
fn to_validation<T>(_: T) -> ValidationErrors {
|
||||
let mut errors = ValidationErrors::new();
|
||||
errors.add("", ValidationError {
|
||||
code: Cow::from("server_error"),
|
||||
message: Some(Cow::from("An unknown error occured")),
|
||||
params: std::collections::HashMap::new()
|
||||
});
|
||||
errors
|
||||
}
|
||||
|
@ -0,0 +1,16 @@
|
||||
@use template_utils::*;
|
||||
@use templates::base;
|
||||
@use routes::session::NewPasswordForm;
|
||||
@use validator::ValidationErrors;
|
||||
|
||||
@(ctx: BaseContext, form: &NewPasswordForm, errors: ValidationErrors)
|
||||
|
||||
@:base(ctx, i18n!(ctx.1, "Reset your password"), {}, {}, {
|
||||
<h1>@i18n!(ctx.1, "Reset your password")</h1>
|
||||
|
||||
<form method="POST">
|
||||
@input!(ctx.1, password (password), "New password", form, errors.clone(), "minlenght=\"8\"")
|
||||
@input!(ctx.1, password_confirmation (password), "Confirmation", form, errors.clone(), "minlenght=\"8\"")
|
||||
<input type="submit" value="@i18n!(ctx.1, "Update password")" />
|
||||
</form>
|
||||
})
|
@ -0,0 +1,15 @@
|
||||
@use template_utils::*;
|
||||
@use templates::base;
|
||||
@use routes::session::ResetForm;
|
||||
@use validator::ValidationErrors;
|
||||
|
||||
@(ctx: BaseContext, form: &ResetForm, errors: ValidationErrors)
|
||||
|
||||
@:base(ctx, i18n!(ctx.1, "Reset your password"), {}, {}, {
|
||||
<h1>@i18n!(ctx.1, "Reset your password")</h1>
|
||||
|
||||
<form method="POST">
|
||||
@input!(ctx.1, email (email), "E-mail", form, errors.clone(), "minlenght=\"1\"")
|
||||
<input type="submit" value="@i18n!(ctx.1, "Send reset link")" />
|
||||
</form>
|
||||
})
|
@ -0,0 +1,9 @@
|
||||
@use template_utils::*;
|
||||
@use templates::base;
|
||||
|
||||
@(ctx: BaseContext)
|
||||
|
||||
@:base(ctx, i18n!(ctx.1, "Password reset"), {}, {}, {
|
||||
<h1>@i18n!(ctx.1, "Check your inbox!")</h1>
|
||||
<p>@i18n!(ctx.1, "We sent a mail to the address you gave us, with a link to reset your password.")</p>
|
||||
})
|
you should reorder imports so all
feature=debug
and allnot(feature=debug)
are segregated, it'll make thinks easier to read and maintainThe ideal may be to have 2 private mods, one
debug
and onerelease
(or whatever), and re-export only the one enabledyou should reorder imports so all
feature=debug
and allnot(feature=debug)
are segregated, it'll make thinks easier to read and maintainThe ideal may be to have 2 private mods, one
debug
and onerelease
(or whatever), and re-export only the one enabledMaybe this would be more at it's place in plume-model than in plume itself?
Maybe this would be more at it's place in plume-model than in plume itself?