Mirrors/mealie
1
0
Fork 0
mirror of https://github.com/mealie-recipes/mealie.git synced 2026-08-02 13:00:14 -04:00
Code Issues Packages Projects Releases Wiki Activity

feat: Announce OIDC email change and announce new scraper capabilities (#7963)

Browse Source
This commit is contained in:
Michael Genson
2026-07-27 19:40:33 -05:00
committed by GitHub
parent 73f155f08a
commit e151c2467e
4 changed files with 153 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
docs/docs/documentation/getting-started/authentication/oidc-v2.md
View File

@@ -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. 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 ## 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. 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 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` 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 ## Mealie Setup

2
docs/docs/documentation/getting-started/installation/backend-config.md
View File

@@ -101,7 +101,7 @@ For usage, see [Usage - OpenID Connect](../authentication/oidc-v2.md)
| ----------------------------------------------------------------------------------- | :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | ----------------------------------------------------------------------------------- | :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| OIDC_AUTH_ENABLED | False | Enables authentication via OpenID Connect | | 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_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>[&dagger;][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_CONFIGURATION_URL<super>[&dagger;][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>[&dagger;][secrets]</super> | None | The client id of your configured client in your provider | | OIDC_CLIENT_ID<super>[&dagger;][secrets]</super> | None | The client id of your configured client in your provider |
| OIDC_CLIENT_SECRET<super>[&dagger;][secrets]</super> <br/> :octicons-tag-24: v2.0.0 | None | The client secret of your configured client in your provider | | OIDC_CLIENT_SECRET<super>[&dagger;][secrets]</super> <br/> :octicons-tag-24: v2.0.0 | None | The client secret of your configured client in your provider |

64
frontend/app/components/Domain/Announcement/Announcements/2026-07-27_1_oidc-email-verification.vue Normal file
View File

@@ -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>

71
frontend/app/components/Domain/Announcement/Announcements/2026-07-27_2_scraper-proxy-flaresolverr.vue Normal file
View File

@@ -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>