This is part 2 (of 3) for passkeys support.
This adds a hidden site setting plus routes and controller actions.
1. registering passkeys
Passkeys are registered in a two-step process. First, `create_passkey`
returns details for the browser to create a passkey. This includes
- a challenge
- the relying party ID and Origin
- the user's secure identifier
- the supported algorithms
- the user's existing passkeys (if any)
Then the browser creates a key with this information, and submits it to
the server via `register_passkey`.
2. authenticating passkeys
A similar process happens here as well. First, a challenge is created
and sent to the browser. Then the browser makes a public key credential
and submits it to the server via `passkey_auth_perform`.
3. renaming/deleting passkeys
These routes allow changing the name of a key and deleting it.
4. checking if session is trusted for sensitive actions
Since a passkey is a password replacement, we want to make sure to confirm the user's identity before allowing adding/deleting passkeys. The u/trusted-session GET route returns success if user has confirmed their session (and failed if user hasn't). In the frontend (in the next PR), we're using these routes to show the password confirmation screen.
The `/u/confirm-session` route allows the user to confirm their session with a password. The latter route's functionality already existed in core, under the 2FA flow, but it has been abstracted into its own here so it can be used independently.
Co-authored-by: Alan Guo Xiang Tan <gxtan1990@gmail.com>
Previously, the `user-tips` service included a couple of calls to `next()`. These were introduced to work around errors like
```
You attempted to update `availableTips` on `<UserTips:ember659>`, but it had already been used previously in the same computation
```
These errors come from the fact that various `<UserTip>` components are rendering at slightly different times in the runloop and stepping on each other. Normally this doesn't happen in Ember, but the implementation details of our 'Widget' system and its 'RenderGlimmer' helper mean that RenderGlimmer components are rendered later than normal Ember components. Using `next()` avoids the problem because it means that all the updates are scheduled together in the following runloop interation.
However, the use of `next()` can create some subtle timing issues, which have been evident in the recent flakiness of some qunit tests. This commit makes a few changes to improve the situation:
1. Use a TrackedMap to provide fine-grained `shouldRender()` reactivity for each user-tip id. That means that different user tips will not be trying to update the same piece of tracked state (previously the entire `availableTips` array was `@tracked`, and was completely re-assigned every time a new `<UserTip>` was rendered
2. Avoid reassigning any tracked state unless the value has actually changed
3. Remove the `next()` workarounds
- Introduces a `deepFreeze` helper to block any mutations to the current-user fixture
- Add `cloneJSON` to any places which were previously causing mutations
When visiting a channel which has unread threads, we will now open the threads list panel.
Note that:
mobile
linking to message
linking to a thread
Won't open the threads list.
Currently, the UI section that contains the title+category+tags of a topic list item (the mobile version) has only one and very generic CSS class, `.right`. Plugins and themes that need to target this section for styling would have to use awkward/very specific CSS selectors in order to avoid incorrectly styling other elements that happen to have the same generic CSS class.
This commit adds an additional class `.topic-item-metadata` to the section to allow easier and more maintainable styling for it.
See https://github.com/discourse/discourse-clickable-topic/pull/4 for a theme that will benefit from this change.
Normally, modules defined under `blah/index` can be imported as `blah`. This is also true of Ember resolver lookups - `<MyComponent />` should resolve to the same as `<MyComponent::Index />`. This was working as expected in Discourse core, but we had not implemented the same in our custom resolver logic for themes/plugins.
This commit implements the `/index` fallback, and adds a test for the behaviour.
This fixes an issue where, on a textarea with a lot of text, the cursor
would jump when adding a new line. See video in PR for a repro.
This is a Chrome bug with scroll anchoring.
Refs: https://bugs.chromium.org/p/chromium/issues/detail?id=997266
The fix here disables `overflow-anchor` on the composer textarea. There
should be no side effects to this change, as scroll anchoring is likely
not needed for the composer textarea element.
The 'create topic' entry in the dropdown was incorrectly using the 'reply as new topic' description. This fixes the logic to use a separate locale key for the description.
Controller queryParam configuration should be wrapped in an array. Omitting the array wrapper seems to work under Ember 3.28, but causes an error under Ember 5.
This commit does a couple of things:
1. Add a new plugin outlet, `above-topic-list-item`, to the `topic-list-item` component
2. Pass the topic in question as an outlet argument for the (existing) `above-latest-topic-list-item` outlet in the `latest-topic-list-item` component.
When a user creates or edits a post, we already were updating
the security of uploads in the post based on site settings and
their access control post, which is important since these uploads
may be switched from secure/not secure based on configuration.
The `with_secure_uploads?` method on a post is used to determine
whether to use the secure-uploads URL for all uploads in the post,
regardless of their individual security, so if this is false and
some of the posts are still secure when rebaking, we end up with
broken URLs.
This commit just makes it so rebaking via the UI also re-evaluates
upload security so that when the post is loaded again after processing,
all of the uploads have the correct security.
For the admin plugin list we want to be able to link to
a meta topic for plugins, but we have no standard way to
do this at the moment. This adds support for meta_topic_id
alongside other plugin metadata like authors, URL etc,
that gets built into a Meta topic URL in the serializer.
It was slightly surprising to have a user card show when click on a thread item list.
More over this commit does:
- moves chat/user-avatar to chat-user-avatar and converts it to gjs
- moves chat/thread/participants to chat-thread-participants
- rewrite the `toggleCheckIfPossible` modifier to only be applied when selecting messages, it prevents the click event to collide with the click of avatars in regular messages
Some time ago, we introduced the `cookAsync` instead of the existing
`cook` function, and planned to migrate everything to it. Then after
migrating, we wanted to raname the function to simply `cook`.
I've checked Core and plugins, and currently we call `cookAsync` everywhere,
there are no calls to the `cook` function anymore. So we're good
to proceed with this refactoring.
This PR makes the first step by making current cookAsync and cook functions
do the same thing. Effectively now the `cook` function becomes an alias
for the `cookAsync` function.
