Password reset #448

マージ済み
elegaanz が 10 個のコミットを password-reset から master へマージ 5年前
elegaanz がコメント 5年前 (github.comから移行)

There is now a link on the login page if you forgot your password. It redirects you to a page asking your email address. An email containing a password reset link will be sent to this address if someone registered with this address. The link is only valid for 15 minutes.

I used the lettre crate for mail finally since I didn't find a way to set a subject with mailstrom (which is very weird). It also allowed me to implement a debug mail sender, that can be enabled with --feature debug-mailer and that will log mails instead of actually sending them.

I should also document the new configuration options for the mail server. Done (but I can still modify it again if you don't like the current approach)

Fixes #298

There is now a link on the login page if you forgot your password. It redirects you to a page asking your email address. An email containing a password reset link will be sent to this address if someone registered with this address. The link is only valid for 15 minutes. I used the `lettre` crate for mail finally since I didn't find a way to set a subject with `mailstrom` (which is very weird). It also allowed me to implement a debug mail sender, that can be enabled with `--feature debug-mailer` and that will log mails instead of actually sending them. ~~I should also document the new configuration options for the mail server.~~ Done (but I can still modify it again if you don't like the current approach) Fixes #298
codecov[bot] がコメント 5年前 (github.comから移行)

Codecov Report

Merging #448 into master will decrease coverage by 0.49%.
The diff coverage is 0%.

@@            Coverage Diff            @@
##           master     #448     +/-   ##
=========================================
- Coverage   25.45%   24.96%   -0.5%     
=========================================
  Files          63       64      +1     
  Lines        6285     6409    +124     
=========================================
  Hits         1600     1600             
- Misses       4685     4809    +124
# [Codecov](https://codecov.io/gh/Plume-org/Plume/pull/448?src=pr&el=h1) Report > Merging [#448](https://codecov.io/gh/Plume-org/Plume/pull/448?src=pr&el=desc) into [master](https://codecov.io/gh/Plume-org/Plume/commit/7bac70a4830eb660506b9cd9603fe013225a74a0?src=pr&el=desc) will **decrease** coverage by `0.49%`. > The diff coverage is `0%`. ```diff @@ Coverage Diff @@ ## master #448 +/- ## ========================================= - Coverage 25.45% 24.96% -0.5% ========================================= Files 63 64 +1 Lines 6285 6409 +124 ========================================= Hits 1600 1600 - Misses 4685 4809 +124 ```
codecov[bot] がコメント 5年前 (github.comから移行)

Codecov Report

Merging #448 into master will increase coverage by 0.03%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #448      +/-   ##
==========================================
+ Coverage   25.45%   25.49%   +0.03%     
==========================================
  Files          63       64       +1     
  Lines        6285     6480     +195     
==========================================
+ Hits         1600     1652      +52     
- Misses       4685     4828     +143
# [Codecov](https://codecov.io/gh/Plume-org/Plume/pull/448?src=pr&el=h1) Report > Merging [#448](https://codecov.io/gh/Plume-org/Plume/pull/448?src=pr&el=desc) into [master](https://codecov.io/gh/Plume-org/Plume/commit/7bac70a4830eb660506b9cd9603fe013225a74a0?src=pr&el=desc) will **increase** coverage by `0.03%`. > The diff coverage is `0%`. ```diff @@ Coverage Diff @@ ## master #448 +/- ## ========================================== + Coverage 25.45% 25.49% +0.03% ========================================== Files 63 64 +1 Lines 6285 6480 +195 ========================================== + Hits 1600 1652 +52 - Misses 4685 4828 +143 ```
trinity-1686a がレビュー 5年前
trinity-1686a がコメント
オーナー

I haven't tested it yet, just made some observations on the code. Most comments are code-style, so this is mostly good

I haven't tested it yet, just made some observations on the code. Most comments are code-style, so this is mostly good
trinity-1686a がコメント 5年前
オーナー

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

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 がコメント 5年前
オーナー

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?
@ -101,3 +105,140 @@ pub fn delete(mut cookies: Cookies) -> Redirect {
}
trinity-1686a がコメント 5年前
オーナー

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)

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 がコメント 5年前
オーナー

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 がコメント 5年前
オーナー

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

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 がコメント 5年前
オーナー

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
trinity-1686a がレビュー 5年前
trinity-1686a がコメント
オーナー

Apparently letter won't compile on Archlinux, it requires an old version of openssl that Arch don't provide. I'll spin up a debian vm this afternoon to actually test the code, and try to fix this with upstream

Apparently letter won't compile on Archlinux, it requires an old version of openssl that Arch don't provide. I'll spin up a debian vm this afternoon to actually test the code, and try to fix this with upstream
trinity-1686a がコメント 5年前
オーナー

that's 24 minutes, not 24 hours

that's 24 minutes, not 24 hours
trinity-1686a がコメント 5年前
オーナー

that's 2 minutes, not 2 hours

that's 2 minutes, not 2 hours
trinity-1686a がコメント 5年前
オーナー

You should maintain the lock instead of locking and unlocking many times

You should maintain the lock instead of locking and unlocking many times
trinity-1686a がコメント 5年前
オーナー

I think using ! .any(|x|...) would be easier to read

I think using ! .any(|x|...) would be easier to read
trinity-1686a がコメント 5年前
オーナー

you should remove before checking if there is already an entry, otherwise one asking for a second reset link after, says, 12 hours, won't get it's mail. Also this mean the vec is cleaned only when a valid request is made, so if nobody else request a password reset, one wont ever get unlocked

you should remove before checking if there is already an entry, otherwise one asking for a second reset link after, says, 12 hours, won't get it's mail. Also this mean the vec is cleaned only when a valid request is made, so if nobody else request a password reset, one wont ever get unlocked
trinity-1686a がコメント 5年前
オーナー

Instead of building a Vec, then "substracting" if from the one stored, building directly the right one and mem::replace-ing it seems easier to read, and don't require to enable another feature
snippet :

let a = Mutex::new(vec![1,2,3]);
std::mem::replace(&mut *a.lock().unwrap(), vec![4,5,6]);
Instead of building a Vec, then "substracting" if from the one stored, building directly the right one and mem::replace-ing it seems easier to read, and don't require to enable another feature snippet : ```rust let a = Mutex::new(vec![1,2,3]); std::mem::replace(&mut *a.lock().unwrap(), vec![4,5,6]); ```
elegaanz (github.comから移行) がレビュー 5年前
elegaanz (github.comから移行) がコメント 5年前

Oops looks like I don't know how time is working 😬

Oops looks like I don't know how time is working :grimacing:
elegaanz (github.comから移行) がレビュー 5年前
elegaanz (github.comから移行) がコメント 5年前

I can't because I need to borrow it both mutably and immutably and Rust won't let me do that. But maybe there is a solution to do it I didn't find?

I can't because I need to borrow it both mutably and immutably and Rust won't let me do that. But maybe there is a solution to do it I didn't find?
trinity-1686a がレビュー 5年前
trinity-1686a がコメント 5年前
オーナー

I've removed a lot of code, but here is a poc of how I would do it (and some other things, trashing old things sooner and don't use the feature) https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=2c32af184c99ff62ee99f94aa2e4fa13
Sadly I can't compile this branch so I can't give you a clean commit, but it should put you on the right track

I've removed a lot of code, but here is a poc of how I would do it (and some other things, trashing old things sooner and don't use the feature) https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=2c32af184c99ff62ee99f94aa2e4fa13 Sadly I can't compile this branch so I can't give you a clean commit, but it should put you on the right track
trinity-1686a がレビュー 5年前
trinity-1686a がコメント 5年前
オーナー

(I found a better way to do it, see the link to the playground)

(I found a better way to do it, see the link to the playground)
trinity-1686a がレビュー 5年前
trinity-1686a がコメント 5年前
オーナー

and again, that's 2.4 hours

and again, that's 2.4 hours
igalic (github.comから移行) がレビュー 5年前
igalic (github.comから移行) がコメント 5年前

why is math so hard? why are there no as_minutes() and as_hours() functions?!??

why is math so hard? why are there no `as_minutes()` and `as_hours()` functions?!??
trinity-1686a がレビュー 5年前
trinity-1686a がコメント
オーナー

👍

:+1:
trinity-1686a がコメント 5年前
オーナー

It doesn't seems to compile with debug-mailer on

It doesn't seems to compile with debug-mailer on
trinity-1686a が変更を承認 5年前
trinity-1686a がコメント
オーナー

Something should also be added in the documentation regarding new environment variables

Something should also be added in the documentation regarding new environment variables
elegaanz がコメント 5年前 (github.comから移行)
Already done :grin:, see https://docs.joinplu.me/environment/ and https://docs.joinplu.me/installation/config/
trinity-1686a がコメント 5年前
オーナー

Mb, I did not check it before. I think however Docker documentation should be updated, as it says only 2 vars need changes, whereas MAIL_* do too

Mb, I did not check it before. I think however Docker documentation should be updated, as it says only 2 vars need changes, whereas MAIL_* do too

レビューア

trinity-1686a が変更を承認 5年前
プルリクエストは a2b9d7ec44 でマージされています。
コマンドラインの手順も確認できます。

ステップ 1:

あなたのプロジェクトリポジトリで新しいブランチをチェックアウトし、変更内容をテストします。
git checkout -b password-reset master
git pull origin password-reset

ステップ 2:

変更内容をマージして、Forgejoに反映します。
git checkout master
git merge --no-ff password-reset
git push origin master
サインインしてこの会話に参加。
レビューアなし
マイルストーンなし
担当者なし
2 人の参加者
通知
期日
期日が正しくないか範囲を超えています。 'yyyy-mm-dd' の形式で入力してください。

期日は未設定です。

依存関係

依存関係が設定されていません。

リファレンス: Plume/Plume#448
読み込み中…
まだ内容がありません