bleedingdeacons / fellowship / 33931714234
90%

DEFAULT BRANCH: main
Ran
Jobs 1
Files 57
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 24.646% (+0.2%) from 24.405%
33931714234

push

github

web-flow 
feat: email a member a password code from the admin (#5)

There was no way to help a member who could not sign in. Passwords are
set only on request, and the request could only come from the app -- so
a member whose address is not a Google, Microsoft, Apple or Facebook
account, and who never got the first code, had nobody who could start
the flow for them.

Triggering is not setting, and that distinction is the whole reason this
is safe. The code goes to the member's own address, so an admin can
start the flow and cannot finish it. A screen that set a password
directly would be a way to enrol a handset as somebody else and read
their messages, which is why there is not one.

A form taking an address rather than a per-row button: the member who
most needs this has no handset yet, so a button on the device table
would be missing for exactly the case it exists to solve.

This screen answers honestly where the REST endpoint deliberately will
not. The public endpoint cannot say whether an address belongs to a
member without becoming a way to enumerate the fellowship; here the
operator is already authenticated and can already read the member list,
so saying so leaks nothing and saves them watching for a mail that was
never going to arrive.

beginReset now answers whether it queued anything. The REST layer
ignores it and must go on ignoring it -- its response still does not
vary -- but the admin needs it: without it the cooldown made the button
report success and send nothing, which is a button somebody presses four
more times.

The handler's body is split into sendResetCodeFromRequest so it can be
driven past the redirect and exit, following Reach's precedent. It reads
$_POST through sanitize_email/is_email rather than filter_input, which
reads the original request and cannot be driven at all -- the validation
is not weaker for it.

Eleven tests, including that the mail goes to the member and never to
the admin, that a refused attempt writes no audit entry,... (continued)

854 of 3465 relevant lines covered (24.65%)

1.74 hits per line

Coverage Regressions

Lines Coverage ∆ File
116
11.56
11.56% fellowship/fellowship/src/Admin/DevicesPage.php
4
91.21
0.1% fellowship/fellowship/src/Auth/PasswordAuthenticator.php
2
0.0
0.0% fellowship/fellowship/src/Core/FellowshipServiceProvider.php
1
83.33
-8.33% fellowship/fellowship/src/Auth/Base64Url.php
Jobs
ID Job ID Ran Files Coverage
1 33931714234.1 57
24.65
GitHub Action Run
Source Files on build 33931714234