placeholder changes and make command copyable. the command always uses
an example email address as the email address, because the email address
is unknown unless you fill in the email address field and mess up the
PGP key field.
Currently, the abused check (and with it, the counter increase for rate
limits) for registration happens before the check if a username is
already taken. This causes legitimate users who are trying to find an
available username to run into the rate limit.
Instead, do the check last thing before commiting the transaction, and
rollback if it fails.
Use make targets to skip "go generate" invocations when unnecessary.
Contrary to the prior iteration in d95f464128 ("makefile: don't
re-generate if unchanged"), this version uses api/graph/api/generated.go
instead of api/graph/schema.resolvers.go to track the freshness of
the GraphQL codegen. This fixes the situation where the GraphQL codegen
is skipped because api/graph/schema.resolvers.go exists and is newer
than its dependencies.
As explained in the comment a few lines above, what is being used here
for the email is the fingerprint of the encryption subkey, which will be
surprising to most users. Only use it if no main key could be
determined. This was already determined, so just use the same
fingerprint as was written to the database.
This reverts commit e8ea0241dc.
The update path does not update the actual key material. Also, the error
handling depends on UI strings, which are not guaranteed to be stable.
The code that uses it has alway looked for it in [meta.sr.ht::settings],
it was apparently put in the wrong section by accident when it was first
added to the example config.
Adds a new setting key-expiration-emails to [meta.sr.ht::settings],
which, when enabled, will make metasrht-daily send out reminders for PGP
keys that are about to expire (for now, in a month). Assuming
metasrht-daily is not run more than once day, only a single email will
be sent for each key.
There is a clash between the GQL API implementation and the RFC:
the GQL API will invalidate the refresh token on expiration, but
the RFC says that the refresh token should remain valid some time
after the access token expires.
It currently updates the key creation date. Instead, have it update the
last_used date. Rename it, to make its purposes more clear, and make it
internal, as its only intended use-case is to let the login scripts
update the last_used date. There is no reason to let users mess with
this.
The current suggestion has been removed from F-Droid. Suggest Aegis
instead, which Does The Job(TM), has some decent features, and seems
reasonable well-maintained.
Currently, when entering a wrong TOTP recovery code, the user will see
an error message claiming their TOTP was created before the introduction
of recovery codes, even when that's not the case (otherwise they
wouldn't have gotten to enter on in the first place).
This commit fixes that by rendering the template with `supported=true`,
as only users with recovery codes can get to this step (or folks messing
around, but then you don't get to complain about misleading UI).
This makes the template render correctly and display the actual error
message again.
Signed-off-by: Conrad Hoffmann <ch@bitfehler.net>
The expectation with the @access directive is that permission
checks are automatically performed by core-go. However this is
actually a no-op for enum values.
Drop the enum value directives to make it clearer that permission
checks must be performed manually.
As of todo.sr.ht 0.74.6 there are no longer any users of these initial
attempts to provided internal email sending services. Everything has
been consolidated in the `sendEmail` mutation.
Signed-off-by: Conrad Hoffmann <ch@bitfehler.net>
If you were once a paying customer, metasrht-daily will call
`charge_user` on you. Adapt its filter to exclude admin accounts. For
good measure, also always return `ChargeResult.account_current` for
admins to avoid any actual charge attempts.
Simon Ser