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
fix(feishu-auth, dingtalk-auth): bind the authorization code to the session that started the login
Both plugins emitted the login redirect and consumed the callback without a
state parameter, so a code from the query string was accepted regardless of
which session it arrived on.
Generate a random state before redirecting, carry it on the redirect URL, and
require it back on codes taken from the query string. Codes taken from the
configured header are exempt, since those requests come from non-browser
clients.
Also replaces sess:delete(), which does not exist in lua-resty-session 4.x and
crashed the feishu-auth token refresh path.
Once you have enabled the Plugin, incoming requests to the Route are processed as follows:
121
121
122
-
1.**No session and no code**: The user is redirected to `redirect_uri` (typically a DingTalk OAuth login page) with a `302` response.
123
-
2.**Authorization code present** (in the `code` query parameter or `X-DingTalk-Code` header): The Plugin exchanges the code for an access token via `access_token_url`, then retrieves user information from `userinfo_url`. On success, the user information is stored in an encrypted cookie session and the original request proceeds.
122
+
1.**No session and no code**: The Plugin generates a random `state`, stores it in the session cookie, and redirects the user to `redirect_uri` (typically a DingTalk OAuth login page) with a `302` response, appending `state` to the query string. Pass `state` through to DingTalk so that it is returned on the callback.
123
+
2.**Authorization code present** (in the `code` query parameter or `X-DingTalk-Code` header): A code taken from the query parameter must arrive with the `state` bound to the session, otherwise the Plugin responds with `401`. This ties the code to the browser that started the flow. A code taken from the `X-DingTalk-Code` header is exempt, since such requests come from non-browser clients. The Plugin then exchanges the code for an access token via `access_token_url`, then retrieves user information from `userinfo_url`. On success, the user information is stored in an encrypted cookie session and the original request proceeds.
124
124
3.**Valid session cookie**: Subsequent requests carrying the session cookie bypass DingTalk API calls entirely and proceed directly to the upstream.
125
125
126
126
When `set_userinfo_header` is `true` (the default), the upstream receives the DingTalk user information in the `X-Userinfo` header as a Base64-encoded JSON object.
1. A user visits a Route protected by `feishu-auth`.
105
-
2. If no valid session cookie exists and no authorization `code` is present, the plugin redirects the user to `redirect_uri` with HTTP 302. Your application should then redirect the user to the Feishu OAuth authorization page.
105
+
2. If no valid session cookie exists and no authorization `code` is present, the plugin generates a random `state`, stores it in the session cookie, and redirects the user to `redirect_uri` with HTTP 302, appending `state` to the query string. Your application should then redirect the user to the Feishu OAuth authorization page, passing `state` through so that Feishu returns it on the callback.
106
106
3. After the user authorizes, Feishu redirects back to `auth_redirect_uri` with an authorization `code`. The plugin extracts the code either from the `code_query` query parameter or the `code_header` HTTP header.
107
-
4. The plugin exchanges the code for an access token at `access_token_url`, then fetches user information from `userinfo_url`.
108
-
5. User information is stored in an encrypted session cookie (`feishu_session`). Subsequent requests with a valid cookie bypass the OAuth flow.
109
-
6. If `set_userinfo_header` is `true`, the plugin encodes the user information as Base64 JSON and sets it in the `X-Userinfo` request header before forwarding to the upstream.
107
+
4. A code taken from the query string must arrive with the `state` bound to the session, otherwise the plugin responds with HTTP 401. This ties the code to the browser that started the flow. A code taken from the `code_header` HTTP header is exempt, since such requests come from non-browser clients.
108
+
5. The plugin exchanges the code for an access token at `access_token_url`, then fetches user information from `userinfo_url`.
109
+
6. User information is stored in an encrypted session cookie (`feishu_session`). Subsequent requests with a valid cookie bypass the OAuth flow.
110
+
7. If `set_userinfo_header` is `true`, the plugin encodes the user information as Base64 JSON and sets it in the `X-Userinfo` request header before forwarding to the upstream.
0 commit comments