You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Added configuration option to skip OIDC authorization checks for certain endpoints (#969)
* Added posibility to bypass oidc authentication for certain endpoints
* fixxed missing .clone()
* Fixxed oidc_skip_endpoints not being optional
* feat(oidc): Introduce protected path prefixes
This commit replaces the OIDC endpoint blacklist with a path prefix whitelist. This is a more intuitive and secure approach for managing protected routes.
The new `oidc_protected_paths` configuration option allows users to specify a list of URL prefixes that require OIDC authentication. By default, all paths are protected.
The documentation has been updated to reflect this change, with clear examples and more user-friendly language.
* docs(oidc): Improve OIDC documentation and examples
This commit improves the OIDC documentation and the "single sign on"
example to better demonstrate how to create a selective login system.
The main documentation now includes a section on creating a public
login page and the "single sign on" example has been updated to
reflect this pattern.
* Simplify OIDC middleware request handling for unprotected paths
* docs(oidc): Improve single sign on example
This commit improves the "single sign on" example to better
demonstrate a public information page that adapts to the users
login status and a separate protected page.
* docs(oidc): Document oidc_protected_paths in configuration.md
This commit updates the main configuration documentation to reflect the
new `oidc_protected_paths` option. It removes the outdated
`oidc_skip_endpoints` and provides a more detailed explanation of how
to create a mix of public and private pages.
* Improve SSO demo UX
- Update docker compose command to use `--watch` flag - Add watch
configuration for SQLPage development - Enhance login page with hero
component and better styling - Simplify protected page welcome message -
Fix OIDC middleware path check logic - Update protected paths in config
to use `/protected` instead of `/protected.sql`
* Skip OIDC auth for non-protected paths later in middleware
We still want to be able to access authenticated user's info in
non-authenticated parts of the app.
We crucially need to check request.path() == SQLPAGE_REDIRECT_URI before
the protected_paths check
* Added whitelist option
* Update configuration.md
* Improve OIDC public paths documentation
The documentation now provides clearer examples and explains the
interaction between public and protected paths more precisely. Also
removes the now-unused default_oidc_public_paths function since the
field's default is handled by serde's default for Vec.
* Add OidcConfig method to check public paths
The new `is_public_path` method consolidates the logic for checking if a
path should bypass OIDC authentication. This replaces the previous
inline checks for public and protected paths.
* fix default empty public paths
* Update SSO example with new image path and public access rules
- Change hero image path in login page - Remove protected.sql as it's no
longer needed - Update sqlpage.yaml to allow public access to
/protected/public
---------
Co-authored-by: Lenardt Gerhardts <[email protected]>
Co-authored-by: lovasoa <[email protected]>
Copy file name to clipboardExpand all lines: configuration.md
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -25,6 +25,8 @@ Here are the available configuration options and their default values:
25
25
|`configuration_directory`|`./sqlpage/`| The directory where the `sqlpage.json` file is located. This is used to find the path to [`templates/`](https://sql-page.com/custom_components.sql), [`migrations/`](https://sql-page.com/your-first-sql-website/migrations.sql), and `on_connect.sql`. Obviously, this configuration parameter can be set only through environment variables, not through the `sqlpage.json` file itself in order to find the `sqlpage.json` file. Be careful not to use a path that is accessible from the public WEB_ROOT |
26
26
|`allow_exec`| false | Allow usage of the `sqlpage.exec` function. Do this only if all users with write access to sqlpage query files and to the optional `sqlpage_files` table on the database are trusted. |
27
27
|`max_uploaded_file_size`| 5242880 | Maximum size of forms and uploaded files in bytes. Defaults to 5 MiB. |
28
+
|`oidc_protected_paths`|`["/"]`| A list of URL prefixes that should be protected by OIDC authentication. By default, all paths are protected (`["/"]`). If you want to make some pages public, you can restrict authentication to a sub-path, for instance `["/admin", "/users/settings"]`. |
29
+
| `oidc_public_paths` | `[]` | A list of URL prefixes that should be publicly available. By default, no paths are publicly accessible (`[]`). If you want to make some pages public, you can bypass authentication for a sub-path, for instance `["/public/", "/assets/"]`. Keep in mind that without the closing backslashes, that any directory or file starting with `public` or `assets` will be publicly available. This will also overwrite any protected path restriction. If you have a private path `/private` and you define the public path `/private/public/` everything in `/private/public/` will be publicly accessible, while everything else in private will still need authentication.
28
30
|`oidc_issuer_url`|| The base URL of the [OpenID Connect provider](#openid-connect-oidc-authentication). Required for enabling Single Sign-On. |
29
31
|`oidc_client_id`| sqlpage | The ID that identifies your SQLPage application to the OIDC provider. You get this when registering your app with the provider. |
30
32
|`oidc_client_secret`|| The secret key for your SQLPage application. Keep this confidential as it allows your app to authenticate with the OIDC provider. |
@@ -90,7 +92,7 @@ This allows you to keep the password separate from the connection string, which
90
92
91
93
### OpenID Connect (OIDC) Authentication
92
94
93
-
OpenID Connect (OIDC) is a secure way to let users log in to your SQLPage application using their existing accounts from popular services. When OIDC is configured, all access to your SQLPage application will require users to log in through the chosen provider. This enables Single Sign-On (SSO), allowing you to restrict access to your application without having to handle authentication yourself.
95
+
OpenID Connect (OIDC) is a secure way to let users log in to your SQLPage application using their existing accounts from popular services. When OIDC is configured, you can control which parts of your application require authentication using the `oidc_protected_paths` option. By default, all pages are protected. You can specify a list of URL prefixes to protect specific areas, allowing you to have a mix of public and private pages.
94
96
95
97
To set up OIDC, you'll need to:
96
98
1. Register your application with an OIDC provider
Copy file name to clipboardExpand all lines: examples/official-site/sso/single_sign_on.md
+36-5Lines changed: 36 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,5 @@
1
1
# Setting Up Single Sign-On in SQLPage
2
2
3
-
4
3
When you want to add user authentication to your SQLPage application, you have two main options:
5
4
6
5
1. The [authentication component](/component.sql?component=authentication):
@@ -60,9 +59,7 @@ Create or edit `sqlpage/sqlpage.json` to add the following configuration keys:
60
59
When you restart your SQLPage instance, it should automatically contact
61
60
the identity provider, find its login URL, and the public keys that will be used to check the validity of its identity tokens.
62
61
63
-
The next time an user loads page on your SQLPage website, they will be redirected to
64
-
the provider's login page. Upon successful login, they will be redirected back to
65
-
the page they were initially requesting on your website.
62
+
By default, all pages on your website will now require users to log in.
66
63
67
64
## Access User Information in Your SQL
68
65
@@ -89,6 +86,40 @@ values
89
86
(sqlpage.path(), sqlpage.user_info('sub'));
90
87
```
91
88
89
+
## Restricting authentication to a specific set of pages
90
+
91
+
Sometimes, you don't want to protect your entire website with a login, but only a specific section.
92
+
You can achieve this by adding the `oidc_protected_paths` option to your `sqlpage.json` file.
93
+
94
+
This option takes a list of URL prefixes. If a user requests a page whose address starts with one of these prefixes, they will be required to log in.
95
+
96
+
**Example:** Protect only pages in the `/admin` folder.
97
+
98
+
```json
99
+
{
100
+
"oidc_issuer_url": "https://accounts.google.com",
101
+
"oidc_client_id": "your-client-id",
102
+
"oidc_client_secret": "your-client-secret",
103
+
"host": "localhost:8080",
104
+
"oidc_protected_paths": ["/admin"]
105
+
}
106
+
```
107
+
108
+
In this example, a user visiting `/admin/dashboard.sql` will be prompted to log in, while a user visiting `/index.sql` will not.
109
+
110
+
### Creating a public login page
111
+
112
+
A common pattern is to have a public home page with a "Login" button that redirects users to a protected area.
113
+
114
+
With the configuration above, you can create a public page `login.sql` that is not in a protected path. This page can contain a simple link to a protected resource, for instance `/admin/index.sql`:
When a non-authenticated user clicks this "Login" link, SQLPage will automatically redirect them to your identity provider's login page. After they successfully authenticate, they will be sent back to the page they originally requested (`/admin/index.sql`).
122
+
92
123
## Going to Production
93
124
94
125
When deploying to production:
@@ -127,4 +158,4 @@ When deploying to production:
127
158
- Verify your OIDC provider's logs for authentication attempts
128
159
- In production, confirm your domain name matches exactly in both the OIDC provider settings and `sqlpage.json`
129
160
- If [using a reverse proxy](/your-first-sql-website/nginx.sql), ensure it's properly configured to handle the OIDC callback path.
130
-
- If you have checked everything and you think the bug comes from SQLPage itself, [open an issue on our bug tracker](https://github.com/sqlpage/SQLPage/issues).
161
+
- If you have checked everything and you think the bug comes from SQLPage itself, [open an issue on our bug tracker](https://github.com/sqlpage/SQLPage/issues).
Copy file name to clipboardExpand all lines: examples/single sign on/README.md
+10-16Lines changed: 10 additions & 16 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,7 +20,7 @@ Depending on your use case, you can choose the appropriate protocol for your app
20
20
To run the demo, you just need docker and docker-compose installed on your machine. Then, run the following commands:
21
21
22
22
```bash
23
-
docker-compose up
23
+
dockercompose up --watch
24
24
```
25
25
26
26
This will start a Keycloak server and a SQLPage server. You can access the SQLPage application at http://localhost:8080.
@@ -46,14 +46,12 @@ SQLPage has built-in support for OIDC authentication since v0.35.
46
46
This project demonstrates how to use it with the free and open source [Keycloak](https://www.keycloak.org/) OIDC provider.
47
47
You can easily replace Keycloak with another OIDC provider, such as Google, or your enterprise OIDC provider, by following the steps in the [Configuration](#configuration) section.
48
48
49
-
### Important Note About OIDC Protection
49
+
### Public and Protected Pages
50
50
51
-
When using SQLPage's built-in OIDC support, the entire website is protected behind authentication. This means:
52
-
- All pages require users to be logged in
53
-
- There is no way to have public pages alongside protected pages
54
-
- Users will be automatically redirected to the OIDC provider's login page when accessing any page
51
+
By default, SQLPage's built-in OIDC support protects the entire website. However, you can configure it to have a mix of public and protected pages using the `oidc_protected_paths` option in your `sqlpage.json` file.
52
+
53
+
This allows you to create a public-facing area (like a homepage with a login button) and a separate protected area for authenticated users.
55
54
56
-
If you need to have a mix of public and protected pages, you should use the [authentication component](/component.sql?component=authentication) instead.
57
55
58
56
### Configuration
59
57
@@ -65,7 +63,8 @@ you need to configure it in your `sqlpage.json` file:
@@ -91,15 +90,11 @@ select 'text' as component, 'Welcome, ' || sqlpage.user_info('name') || '!' as c
91
90
92
91
The demo includes several SQL files that demonstrate different aspects of OIDC integration:
93
92
94
-
1.`index.sql`: Shows how to:
95
-
- Display user information using `sqlpage.user_info('email')`
96
-
- Show all available user information using `sqlpage.id_token()`
93
+
1.`index.sql`: A public page that shows a welcome message and a login button. If the user is logged in, it displays their email and a link to the protected page.
97
94
98
-
2.`protected.sql`: Demonstrates a page that is accessible to authenticated users
95
+
2.`protected.sql`: A page that is only accessible to authenticated users. It displays the user's information.
99
96
100
-
3.`logout.sql`: Shows how to:
101
-
- Remove the authentication cookie
102
-
- Redirect to the OIDC provider's logout endpoint
97
+
3.`logout.sql`: Logs the user out by removing the authentication cookie and redirecting to the OIDC provider's logout page.
103
98
104
99
### Docker Setup
105
100
@@ -120,4 +115,3 @@ The demo uses Docker Compose to set up both SQLPage and Keycloak. The configurat
Copy file name to clipboardExpand all lines: src/app_config.rs
+26Lines changed: 26 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -201,6 +201,28 @@ pub struct AppConfig {
201
201
#[serde(default = "default_oidc_scopes")]
202
202
puboidc_scopes:String,
203
203
204
+
/// Defines a list of path prefixes that should be protected by OIDC authentication.
205
+
/// By default, all paths are protected.
206
+
/// If you specify a list of prefixes, only requests whose path starts with one of the prefixes will require authentication.
207
+
/// For example, if you set this to `["/private"]`, then requests to `/private/some_page.sql` will require authentication,
208
+
/// but requests to `/index.sql` will not.
209
+
/// NOTE: `OIDC_PUBLIC_PATHS` takes precedence over `OIDC_PROTECTED_PATHS`.
210
+
/// For example, if you have `["/private"]` on the `protected_paths` like before, but also `["/private/public"]` on the `public_paths`, then `/private` requires authentication, but `/private/public` requires not authentication.
211
+
/// You cannot make a path inside a public path private again. So expanding the previous example, if you now add `/private/public/private_again`, then this path will still be accessible.
0 commit comments