This adds a password complexity rule during registration to require strong
passwords. This is based on the `zxcvbn` module that we already use for key
backup passphrases.
In addition, this also tweaks validation more generally to allow rules to be
async functions.
In addition to migrating password fields, this also removes the remaining
support for old-style validation in registration now that all checks have been
converted.
When submitting a form, we want to validate more strictly to check for empty
values that might be required. A separate mode is used since we want to ignore
this issue when visiting a field one by one to enter data.
As an example, we convert the pre-existing logic for the username requirement
using this new support.
Since we're keeping the input as a ref anyway, let's use that rather than
requiring the value to be passed to `validate`. This allows others to call
`validate` as well.
This adjusts the submission step to focus the first invalid field and redisplay
validation. This also rearranges the older style field error handling on
registration which is slated for removal once we convert all fields to the new
style.
This updates the registration form to include the new-style validation state
when deciding whether the entire form is valid overall.
In addition, this tweaks the validation helper to take functions instead of
strings for translated text. This allows the validation helper to be create once
per component instead of once every render, which improves performance.
The `BottomLeftMenu` component is not used in the new design. This removes the
component and also any images and sub-components that were only used by it.
The class name handling for validation inadvertently added `undefined` as a
class when validation is not used. This rearranges the logic to avoid the issue.
Fixes https://github.com/vector-im/riot-web/issues/9345
Add i18n entries for rotating images; fix the way `getName` is defined
Signed-off-by: YaoiFangirl420 <48789208+YaoiFangirl420@users.noreply.github.com>
This ensures we always include the current power level in the power selector,
even if it's greater than the level you're allowed to set yourself. This ensures
the selector can display the current value correctly when disabled.
Fixes https://github.com/vector-im/riot-web/issues/9340
When setting, delete the old one. Because delete checks if it exists first, we can safely call this.
The change in FromWidgetPostMessageApi is just something noticed while debugging.
Having the referrer allows widgets to do customisation based on what
riot instance is embedding it. It gets a referrer when we embed it
in the iframe so there's nothing gained by suppressing it here.
Fixes https://github.com/vector-im/riot-web/issues/6437
This also fixes a bug where if the room had apps open and you clicked the sticker picker's title, you'd end up closing the apps and not the picker.
Fixes a bug for some widgets where they cannot do their startup routine (capabilities negotiation, etc) when someone maximizes the widget. By reloading the widget messaging, we ensure the widget is kept in the loop.
When working on the `Field` validation support, I thought `RegistrationForm`'s
refs would be okay to leave as is, but I missed that they also depended on the
value getter.
For the moment, it's quicker to temporarily revive the value getter to get
registration working.
Fixes https://github.com/vector-im/riot-web/issues/9171
Since Scalar (and other integration managers) are loaded as apps into
an iframe, a valid `scalar_token` must exist when loading the app.
It is possible that a scalar_token becomes invalid between the time
when the integration manager button was rendered and the user clicking
the link. Here we make a call to integration manager `/account`
before trying to render the integration manager, which ensures we
have a valid token for the integration manager to work with.
Moving the scalar token revalidation to the cases where it is actually
needed could make it possible to decrease the amount of Scalar /account
calls we do when switching rooms, which is currently 3.
Signed-off-by: Jason Robinson <jasonr@matrix.org>
As part of adding validation to Field, the logic is simpler to follow if we can
assume that all usages of Field use it as a controlled component, instead of
supporting both controlled and uncontrolled.
This converts the uncontrolled usages to controlled.