* initial oidc implementation * add dynamic scheme * e2e test setup * add caching * fix * try this * add libldap-2.5 to runtime dependencies (#2849) * New translations en-us.json (Norwegian) (#2851) * New Crowdin updates (#2855) * New translations en-us.json (Italian) * New translations en-us.json (Norwegian) * New translations en-us.json (Portuguese) * fix * remove cache * cache yarn deps * cache docker image * cleanup action * lint * fix tests * remove not needed variables * run code gen * fix tests * add docs * move code into custom scheme * remove unneeded type * fix oidc admin * add more tests * add better spacing on login page * create auth providers * clean up testing stuff * type fixes * add OIDC auth method to postgres enum * add option to bypass login screen and go directly to iDP * remove check so we can fallback to another auth method oauth fails * Add provider name to be shown at the login screen * add new properties to admin about api * fix spec * add a prompt to change auth method when changing password * Create new auth section. Add more info on auth methods * update docs * run ruff * update docs * format * docs gen * formatting * initialize logger in class * mypy type fixes * docs gen * add models to get proper fields in docs and fix serialization * validate id token before using it * only request a mealie token on initial callback * remove unused method * fix unit tests * docs gen * check for valid idToken before getting token * add iss to mealie token * check to see if we already have a mealie token before getting one * fix lock file * update authlib * update lock file * add remember me environment variable * add user group setting to allow only certain groups to log in --------- Co-authored-by: Carter Mintey <cmintey8@gmail.com> Co-authored-by: Carter <35710697+cmintey@users.noreply.github.com>
2.4 KiB
Permissions and Public Access
Mealie provides various levels of user access and permissions. This includes:
- Authentication and registration (LDAP and OpenID Connect are both supported)
- Customizable user permissions
- Fine-tuned public access for non-users
Customizable User Permissions
Each user can be configured to have varying levels of access. Some of these permissions include:
- Access to Administrator tools
- Access to inviting other users
- Access to manage their group and group data
Administrators can navigate to the Settings page and access the User Management page to configure these settings.
User Management Demo{ .md-button .md-button--primary }
Public Recipe Access
By default, groups are set to private, meaning only logged-in users may access the group. In order for a recipe to be viewable by public (not logged-in) users, two criteria must be met:
- The group must not be private, and the group setting for allowing users outside of your group to see your recipes must be enabled. These can be toggled on the Group Settings page
- The recipe must be set to public. This can be toggled for each recipe individually, or in bulk using the Recipe Data Management page
Additionally, if the group is not private, public users can view all public group data (public recipes, public cookbooks, etc.) from the home page (e.g. the demo home page).
Group Settings Demo{ .md-button .md-button--primary }
More broadly, here are the rules for how recipe access is determined:
- Private links that are generated from the recipe page using the
Sharebutton bypass all group and recipe permissions - Private groups block all access to recipes, including those that are public, except as noted above.
- Groups with "Allow users outside of your group to see your recipes" disabled block all access to recipes, except as noted above.
- Private recipes block all access to the recipe from public links. This does not affect Private Links.
stateDiagram-v2
r1: Request Access
p1: Using Private Link?
p2: Is Group Private?
p3: Is Recipe Private?
s1: Deny Access
n1: Allow Access
r1 --> p1
p1 --> p2: No
p1 --> n1: Yes
p2 --> s1: Yes
p2 --> p3: No
p3 --> s1: Yes
p3 --> n1: No