add: implement to check if user has valid challenges for roles
This is just the basic work for upcoming patches to enforce the
requirement to have a challenge passed within in the given time for
valid tests for certain areas. see issue #150
Felix Dörre [Sun, 9 Dec 2018 12:01:13 +0000 (13:01 +0100)]
fix: make MyDetails/SwitchToOrg work again
MyDetails.java needs this parameter to know to which form to dispatch
the request as there are two forms that post
to the same url. See src/club/wpia/gigi/pages/account/MyDetails.java#L49
Associating a checkbox with its label improves accessibility and makes
it more convenient to toggle the checkbox.
For most checkboxes, this adds an `id` for the checkbox and associates
the label with it via the `for` attribute, but for checkboxes in a loop
we can’t use that (multiple checkboxes would have the same `id`), so
there the technique of wrapping the input inside the label is used
instead.
The last of the four assertions is intended to record the fact that we
don’t currently check the hash of a “simplified” (here: lowercased)
version of the password. We might want to do this in the future, but in
my opinion that should then be a deliberate decision, which includes
updating the test accordingly.
For short files (or, presumably, for very rare hashes on all files),
PasswordHashChecker would occasionally attempt to read before the start
or past the end of a file; avoid this with clamping (in two cases where
there is no potentially infinite iteration) or aborting (in the one
other case, where clamping might yield an infinite loop).
chg: ignore NoSuchFileException for Pwned Passwords
If we can’t open the Pwned Passwords database because the file does not
exist, there’s no need to print a detailed stack trace: the warning
message should be enough to gently inform the system administrator that
they can improve their security by installing the database. Any other
errors (e. g. permission errors) are still reported.
This is mainly motivated by the dozens of NoSuchFileException stack
traces in CI builds, which this commit should silence.
A new configuration option is added, specifying the path to a file of
known password hashes which Gigi will refuse to accept for user
accounts. If the option is not specified, Gigi attempts to use the Pwned
Passwords database (see the pwned-passwords-bin package) but continues
startup if the database cannot be opened. This is intended to be useful
for developers: production users should always configure the path to the
file explicitly, so that Gigi will refuse to start if the file cannot be
accessed for whatever reason.
The PasswordHashChecker, if used, is chained behind the usual
PasswordStrengthChecker using a DelegatingPasswordChecker.
Felix Dörre [Sun, 14 Jan 2018 23:40:03 +0000 (00:40 +0100)]
add: PasswordHashChecker implementation
The implementation is mostly taken from code in the “lookhash”
repository and its first (only) issue. knownPasswordHash and
estimateHashOffset were written by Felix Dörre, while checkPassword,
compareHashes and the surrounding bits of the class were written by
Lucas Werkmeister.
This PasswordChecker implementation delegates to several other checkers,
which lets us use a series of checkers (e. g. one which rates the
password’s strength and one that checks against a list of known weak
passwords) in place of one.
In theory, this would also let us split up the existing
PasswordStrengthChecker into two checkers, one grading the password
strength in general and one checking whether the password contains parts
of the name or the email address. However, this would remove the current
behavior where a password that contains part of the name or email can be
“redeemed” by being otherwise strong enough: DelegatingPasswordChecker
does not support any such kind of interoperation of checkers.
This provides one centralized place where the PasswordChecker used can
be selected or changed. (setPasswordChecker() is intended for use in the
tests – in normal operation, the PasswordChecker should be set up once
during initialization and then not changed.)
I’d like to do this via dependency injection, but neither User nor
Signup seem like the right places to do this. Perhaps this kind of logic
should be moved to some kind of service where this is more feasible, but
that’s not a refactoring I want to do right now.
PasswordChecker is a generic version of the interface which
PasswordStrengthChecker currently offers. PasswordStrengthChecker is
changed to implement the new interface (currently the only
implementation, but others will be added in the future).
Using this interface instead of PasswordStrengthChecker directly in
other code will let us introduce other ways of checking password
strength as well, e. g. implementing #143.
The interface is placed in the new `passwords` subpackage, and the
PasswordStrengthChecker implementation is also moved there.
mkosi is a tool to build operating system images, possibly with some
software pre-built inside it. This commit adds mkosi configuration files
for building the Debian packages for Gigi on any distribution supported
by mkosi. The *.deb files will be placed in the srv/ directory of the
resulting image (image/srv/*.deb).
Note that mkosi doesn’t include git information in the build tree, so
the changelog used for the packages is whatever is currently in the
source tree. Consider running doc/scripts/genchangelog before mkosi.
The packages are also, unfortunately, not yet deterministic. The
strip-nondeterminism debhelper step uses the date from the changelog (so
if doc/scripts/genchangelog was run before the build started, that part
is deterministic), but it only seems to adjust the timestamps of the
three files in the .deb archives, not of the files within those .tar.*
archives.
A post-install script is included that could potentially be used to
actually install the packages inside the built image. However, that part
doesn’t yet work, so it’s disabled for now: the post-install scripts of
the packages have some extra requirements (more packages, an internet
connection) which mkosi doesn’t satisfy by default, and I didn’t want to
spend more time to find out if it can be made to work. This might be
fixed in a future commit, but even then, it’s not clear if such an image
would be very useful.
INOPIAE [Sat, 3 Mar 2018 06:04:32 +0000 (07:04 +0100)]
chg: apply css 'table' class to table
The 'table' class is built-in from bootstrap to format a table to
spread across the screen. Bootstrap styles tables with the 'table' class
only due to the widespread use of tables for formatting purposes other
than tabular data.