mirror of
https://github.com/mealie-recipes/mealie.git
synced 2026-08-02 13:00:14 -04:00
feat: Announce OIDC email change and announce new scraper capabilities (#7963)
This commit is contained in:
Michael Genson
GitHub
@@ -20,6 +20,21 @@ Signing in with OAuth will automatically find your account in Mealie and link to
|
||||
|
||||
If a user previously accessed Mealie via credentials and you want to no longer allow users to log in with `LDAP` or `Mealie` credentials, then you can set the user's *Authentication Method* to `OIDC`. Conversely, if a user's auth method is not `OIDC`, then they can still log in with whatever their auth method is as well as OIDC.
|
||||
|
||||
### Email Verification
|
||||
|
||||
:octicons-tag-24: v3.21.0
|
||||
|
||||
!!! warning "Breaking change in v3.21.0"
|
||||
Mealie now requires your IdP to assert that the user's email address is verified. If your IdP does not emit the `email_verified` claim, logins will fail until you either configure the claim or set `OIDC_REQUIRES_EMAIL_VERIFICATION=false`.
|
||||
|
||||
Because Mealie links an OIDC login to an existing account by matching on a claim (`OIDC_USER_CLAIM`, `email` by default), an IdP that lets a user self-assert an arbitrary, unverified email address would allow that user to log into someone else's Mealie account simply by claiming their email. To prevent this, Mealie requires the `email_verified` claim to be present and `true` before authenticating.
|
||||
|
||||
Most identity providers (Authentik, Authelia, Keycloak, Google, Entra ID, ...) emit this claim as part of the `email` scope, and require no changes. If a login is rejected for this reason, the following is written to the server logs:
|
||||
|
||||
[OIDC] email_verified claim is missing or false; refusing to authenticate
|
||||
|
||||
If your IdP cannot emit the claim, you can opt out by setting `OIDC_REQUIRES_EMAIL_VERIFICATION` to `false`. Only do this if you trust your IdP to not allow users to set an arbitrary email address on their own.
|
||||
|
||||
## Provider Setup
|
||||
|
||||
Before you can start using OIDC Authentication, you must first configure a new client application in your identity provider. Your identity provider must support the OAuth **Authorization Code flow with PKCE**. The steps will vary by provider, but generally, the steps are as follows.
|
||||
@@ -50,6 +65,8 @@ Before you can start using OIDC Authentication, you must first configure a new c
|
||||
|
||||
The scopes required are `openid profile email`
|
||||
|
||||
The `email` scope is also what grants the `email_verified` claim required for [email verification](#email-verification)
|
||||
|
||||
If you plan to use the [groups](#groups) to configure access within Mealie, you will need to also add the scope defined by the `OIDC_GROUPS_CLAIM` environment variable. The default claim is `groups`
|
||||
|
||||
## Mealie Setup
|
||||
|
||||
@@ -101,7 +101,7 @@ For usage, see [Usage - OpenID Connect](../authentication/oidc-v2.md)
|
||||
| ----------------------------------------------------------------------------------- | :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| OIDC_AUTH_ENABLED | False | Enables authentication via OpenID Connect |
|
||||
| OIDC_SIGNUP_ENABLED | True | Enables new users to be created when signing in for the first time with OIDC |
|
||||
| OIDC_REQUIRES_EMAIL_VERIFICATION | True | Requires the `email_verified` claim to be true before a user can sign in. This prevents an unverified email from being used to match an existing account. Only disable this if your identity provider does not emit the `email_verified` claim. |
|
||||
| OIDC_REQUIRES_EMAIL_VERIFICATION <br/> :octicons-tag-24: v3.21.0 | True | Requires the `email_verified` claim to be true before a user can sign in. This prevents an unverified email from being used to match an existing account. Only disable this if your identity provider does not emit the `email_verified` claim. For more information see [this page](../authentication/oidc-v2.md#email-verification) |
|
||||
| OIDC_CONFIGURATION_URL<super>[†][secrets]</super> | None | The URL to the OIDC configuration of your provider. This is usually something like https://auth.example.com/.well-known/openid-configuration |
|
||||
| OIDC_CLIENT_ID<super>[†][secrets]</super> | None | The client id of your configured client in your provider |
|
||||
| OIDC_CLIENT_SECRET<super>[†][secrets]</super> <br/> :octicons-tag-24: v2.0.0 | None | The client secret of your configured client in your provider |
|
||||
|
||||
@@ -0,0 +1,64 @@
|
||||
<template>
|
||||
<div>
|
||||
<p>
|
||||
If your server signs users in with an external identity provider (OIDC), Mealie now requires that
|
||||
provider to confirm the user's email address before allowing the login.
|
||||
</p>
|
||||
<p>
|
||||
This prevents an unverified, self-asserted email address from being used to match (and sign in) to
|
||||
an existing Mealie account.
|
||||
</p>
|
||||
<div v-if="user?.admin">
|
||||
<hr class="mt-2 mb-4">
|
||||
<p>
|
||||
As an admin, be aware that this is a <strong>breaking change</strong> for identity providers that do
|
||||
not emit the <code>email_verified</code> claim. Those logins now fail, and
|
||||
<code>[OIDC] email_verified claim is missing or false</code> is written to the server logs.
|
||||
</p>
|
||||
<div class="mb-2">
|
||||
You have two options:
|
||||
<ul class="ml-6">
|
||||
<li>Configure your identity provider to include the <code>email_verified</code> claim (recommended)</li>
|
||||
<li>Set <code>OIDC_REQUIRES_EMAIL_VERIFICATION=false</code> to restore the previous behavior</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>
|
||||
Most providers (Authentik, Authelia, Keycloak, Google, Entra ID, ...) send this claim already and are
|
||||
unaffected. See the OIDC docs for details:
|
||||
<br>
|
||||
<v-btn
|
||||
class="mt-2"
|
||||
color="primary"
|
||||
href="https://docs.mealie.io/documentation/getting-started/authentication/oidc-v2/#email-verification"
|
||||
target="_blank"
|
||||
>
|
||||
OpenID Connect (OIDC)
|
||||
</v-btn>
|
||||
</p>
|
||||
</div>
|
||||
<div v-else>
|
||||
<p>
|
||||
If you can no longer sign in with your external account, contact your server admin. They may need to
|
||||
update the server's OIDC configuration.
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
</template>
|
||||
|
||||
<script setup lang="ts">
|
||||
import type { AnnouncementMeta } from "~/composables/use-announcements";
|
||||
|
||||
const { user } = useMealieAuth();
|
||||
</script>
|
||||
|
||||
<script lang="ts">
|
||||
export const meta: AnnouncementMeta = {
|
||||
title: "OIDC logins now require a verified email",
|
||||
};
|
||||
</script>
|
||||
|
||||
<style scoped lang="css">
|
||||
p {
|
||||
padding-bottom: 8px;
|
||||
}
|
||||
</style>
|
||||
@@ -0,0 +1,71 @@
|
||||
<template>
|
||||
<div>
|
||||
<p>
|
||||
Importing recipes from a URL is now more reliable. Mealie does a better job of looking like a real
|
||||
browser, rotates between several browser signatures, and retries more intelligently when a site
|
||||
pushes back. This works out of the box, with no configuration.
|
||||
</p>
|
||||
<p>
|
||||
Some sites sit behind bot protection (such as Cloudflare) that blocks requests made by a server, no
|
||||
matter how they're made. For those, Mealie can now optionally fall back to two extra layers.
|
||||
</p>
|
||||
<div class="mb-2">
|
||||
<ul class="ml-6">
|
||||
<li>
|
||||
<strong>Proxy support</strong>, which routes recipe and image requests through a proxy. This
|
||||
helps with sites that block your server's IP address.
|
||||
</li>
|
||||
<li>
|
||||
<strong>FlareSolverr support</strong>, which hands the page to a real headless browser as a last
|
||||
resort. This helps with challenges that Mealie can't get past on its own.
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div v-if="user?.admin">
|
||||
<hr class="mt-2 mb-4">
|
||||
<p>
|
||||
Both are optional and off by default, so nothing changes unless you configure them. Mealie
|
||||
escalates only as far as it needs to for each import: a direct fetch first, then the proxy (if
|
||||
set), then FlareSolverr (if set, and only when the page is still blocked).
|
||||
</p>
|
||||
<p>
|
||||
Both are enabled with environment variables. Mealie does not ship or manage either one. You supply
|
||||
the proxy, and host FlareSolverr yourself (it runs nicely as a sidecar container). See the
|
||||
configuration docs for the settings, setup details, and an example compose file:
|
||||
<br>
|
||||
<v-btn
|
||||
class="mt-2"
|
||||
color="primary"
|
||||
href="https://docs.mealie.io/documentation/getting-started/installation/backend-config/#recipe-scraper"
|
||||
target="_blank"
|
||||
>
|
||||
Backend Configuration
|
||||
</v-btn>
|
||||
</p>
|
||||
</div>
|
||||
<div v-else>
|
||||
<p>
|
||||
If a recipe URL still refuses to import, let your server admin know. They can enable these extra
|
||||
options on the server.
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
</template>
|
||||
|
||||
<script setup lang="ts">
|
||||
import type { AnnouncementMeta } from "~/composables/use-announcements";
|
||||
|
||||
const { user } = useMealieAuth();
|
||||
</script>
|
||||
|
||||
<script lang="ts">
|
||||
export const meta: AnnouncementMeta = {
|
||||
title: "Better recipe imports, with proxy and FlareSolverr support",
|
||||
};
|
||||
</script>
|
||||
|
||||
<style scoped lang="css">
|
||||
p {
|
||||
padding-bottom: 8px;
|
||||
}
|
||||
</style>
|
||||
Reference in New Issue
Block a user