diff --git a/internal/httpclient/api/openapi.yaml b/internal/httpclient/api/openapi.yaml index dea8f28c55cf..01006f9356da 100644 --- a/internal/httpclient/api/openapi.yaml +++ b/internal/httpclient/api/openapi.yaml @@ -656,16 +656,16 @@ paths: API flows expect `application/json` to be sent in the body and responds with HTTP 200 and a application/json body with the session token on success; - HTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; + HTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; HTTP 400 on form validation errors. Browser flows expect a Content-Type of `application/x-www-form-urlencoded` or `application/json` to be sent in the body and respond with - a HTTP 302 redirect to the post/after login URL or the `return_to` value if it was set and if the login succeeded; - a HTTP 302 redirect to the login UI URL with the flow ID containing the validation errors otherwise. + a HTTP 303 redirect to the post/after login URL or the `return_to` value if it was set and if the login succeeded; + a HTTP 303 redirect to the login UI URL with the flow ID containing the validation errors otherwise. Browser flows with an accept header of `application/json` will not redirect but instead respond with HTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success; - HTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; + HTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; HTTP 400 on form validation errors. If this endpoint is called with `Accept: application/json` in the header, the response contains the flow without a redirect. In the @@ -716,7 +716,7 @@ paths: schema: $ref: '#/components/schemas/successfulSelfServiceLoginWithoutBrowser' description: successfulSelfServiceLoginWithoutBrowser - "302": + "303": description: Empty responses are sent when, for example, resources are deleted. The HTTP status code for empty responses is typically 201. "400": @@ -888,7 +888,7 @@ paths: schema: $ref: '#/components/schemas/selfServiceLoginFlow' description: selfServiceLoginFlow - "302": + "303": description: Empty responses are sent when, for example, resources are deleted. The HTTP status code for empty responses is typically 201. "400": @@ -997,7 +997,7 @@ paths: description: |- This endpoint logs out an identity in a self-service manner. - If the `Accept` HTTP header is not set to `application/json`, the browser will be redirected (HTTP 302 Found) + If the `Accept` HTTP header is not set to `application/json`, the browser will be redirected (HTTP 303 See Other) to the `return_to` parameter of the initial request or fall back to `urls.default_return_to`. If the `Accept` HTTP header is set to `application/json`, a 204 No Content response @@ -1034,7 +1034,7 @@ paths: "204": description: Empty responses are sent when, for example, resources are deleted. The HTTP status code for empty responses is typically 201. - "302": + "303": description: Empty responses are sent when, for example, resources are deleted. The HTTP status code for empty responses is typically 201. "500": @@ -1142,12 +1142,12 @@ paths: `choose_method` expects `flow` (in the URL query) and `email` (in the body) to be sent and works with API- and Browser-initiated flows. For API clients and Browser clients with HTTP Header `Accept: application/json` it either returns a HTTP 200 OK when the form is valid and HTTP 400 OK when the form is invalid. - and a HTTP 302 Found redirect with a fresh recovery flow if the flow was otherwise invalid (e.g. expired). - For Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 302 Found redirect to the Recovery UI URL with the Recovery Flow ID appended. + and a HTTP 303 See Other redirect with a fresh recovery flow if the flow was otherwise invalid (e.g. expired). + For Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 303 See Other redirect to the Recovery UI URL with the Recovery Flow ID appended. `sent_email` is the success state after `choose_method` for the `link` method and allows the user to request another recovery email. It works for both API and Browser-initiated flows and returns the same responses as the flow in `choose_method` state. `passed_challenge` expects a `token` to be sent in the URL query and given the nature of the flow ("sending a recovery link") - does not have any API capabilities. The server responds with a HTTP 302 Found redirect either to the Settings UI URL + does not have any API capabilities. The server responds with a HTTP 303 See Other redirect either to the Settings UI URL (if the link was valid) and instructs the user to update their password, or a redirect to the Recover UI URL with a new Recovery Flow ID which contains an error message that the recovery link was invalid. @@ -1196,7 +1196,7 @@ paths: schema: $ref: '#/components/schemas/selfServiceRecoveryFlow' description: selfServiceRecoveryFlow - "302": + "303": description: Empty responses are sent when, for example, resources are deleted. The HTTP status code for empty responses is typically 201. "400": @@ -1284,7 +1284,7 @@ paths: schema: $ref: '#/components/schemas/selfServiceRecoveryFlow' description: selfServiceRecoveryFlow - "302": + "303": description: Empty responses are sent when, for example, resources are deleted. The HTTP status code for empty responses is typically 201. "400": @@ -1386,16 +1386,16 @@ paths: API flows expect `application/json` to be sent in the body and respond with HTTP 200 and a application/json body with the created identity success - if the session hook is configured the `session` and `session_token` will also be included; - HTTP 302 redirect to a fresh registration flow if the original flow expired with the appropriate error messages set; + HTTP 303 redirect to a fresh registration flow if the original flow expired with the appropriate error messages set; HTTP 400 on form validation errors. Browser flows expect a Content-Type of `application/x-www-form-urlencoded` or `application/json` to be sent in the body and respond with - a HTTP 302 redirect to the post/after registration URL or the `return_to` value if it was set and if the registration succeeded; - a HTTP 302 redirect to the registration UI URL with the flow ID containing the validation errors otherwise. + a HTTP 303 redirect to the post/after registration URL or the `return_to` value if it was set and if the registration succeeded; + a HTTP 303 redirect to the registration UI URL with the flow ID containing the validation errors otherwise. Browser flows with an accept header of `application/json` will not redirect but instead respond with HTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success; - HTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; + HTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; HTTP 400 on form validation errors. If this endpoint is called with `Accept: application/json` in the header, the response contains the flow without a redirect. In the @@ -1438,7 +1438,7 @@ paths: schema: $ref: '#/components/schemas/successfulSelfServiceRegistrationWithoutBrowser' description: successfulSelfServiceRegistrationWithoutBrowser - "302": + "303": description: Empty responses are sent when, for example, resources are deleted. The HTTP status code for empty responses is typically 201. "400": @@ -1552,7 +1552,7 @@ paths: schema: $ref: '#/components/schemas/selfServiceRegistrationFlow' description: selfServiceRegistrationFlow - "302": + "303": description: Empty responses are sent when, for example, resources are deleted. The HTTP status code for empty responses is typically 201. "500": @@ -1658,20 +1658,20 @@ paths: API-initiated flows expect `application/json` to be sent in the body and respond with HTTP 200 and an application/json body with the session token on success; - HTTP 302 redirect to a fresh settings flow if the original flow expired with the appropriate error messages set; + HTTP 303 redirect to a fresh settings flow if the original flow expired with the appropriate error messages set; HTTP 400 on form validation errors. HTTP 401 when the endpoint is called without a valid session token. HTTP 403 when `selfservice.flows.settings.privileged_session_max_age` was reached or the session's AAL is too low. Implies that the user needs to re-authenticate. Browser flows without HTTP Header `Accept` or with `Accept: text/*` respond with - a HTTP 302 redirect to the post/after settings URL or the `return_to` value if it was set and if the flow succeeded; - a HTTP 302 redirect to the Settings UI URL with the flow ID containing the validation errors otherwise. - a HTTP 302 redirect to the login endpoint when `selfservice.flows.settings.privileged_session_max_age` was reached or the session's AAL is too low. + a HTTP 303 redirect to the post/after settings URL or the `return_to` value if it was set and if the flow succeeded; + a HTTP 303 redirect to the Settings UI URL with the flow ID containing the validation errors otherwise. + a HTTP 303 redirect to the login endpoint when `selfservice.flows.settings.privileged_session_max_age` was reached or the session's AAL is too low. Browser flows with HTTP Header `Accept: application/json` respond with HTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success; - HTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; + HTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; HTTP 401 when the endpoint is called without a valid session cookie. HTTP 403 when the page is accessed without a session cookie or the session's AAL is too low. HTTP 400 on form validation errors. @@ -1734,7 +1734,7 @@ paths: schema: $ref: '#/components/schemas/selfServiceSettingsFlow' description: selfServiceSettingsFlow - "302": + "303": description: Empty responses are sent when, for example, resources are deleted. The HTTP status code for empty responses is typically 201. "400": @@ -1875,7 +1875,7 @@ paths: schema: $ref: '#/components/schemas/selfServiceSettingsFlow' description: selfServiceSettingsFlow - "302": + "303": description: Empty responses are sent when, for example, resources are deleted. The HTTP status code for empty responses is typically 201. "400": @@ -2015,12 +2015,12 @@ paths: `choose_method` expects `flow` (in the URL query) and `email` (in the body) to be sent and works with API- and Browser-initiated flows. For API clients and Browser clients with HTTP Header `Accept: application/json` it either returns a HTTP 200 OK when the form is valid and HTTP 400 OK when the form is invalid - and a HTTP 302 Found redirect with a fresh verification flow if the flow was otherwise invalid (e.g. expired). - For Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 302 Found redirect to the Verification UI URL with the Verification Flow ID appended. + and a HTTP 303 See Other redirect with a fresh verification flow if the flow was otherwise invalid (e.g. expired). + For Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 303 See Other redirect to the Verification UI URL with the Verification Flow ID appended. `sent_email` is the success state after `choose_method` when using the `link` method and allows the user to request another verification email. It works for both API and Browser-initiated flows and returns the same responses as the flow in `choose_method` state. `passed_challenge` expects a `token` to be sent in the URL query and given the nature of the flow ("sending a verification link") - does not have any API capabilities. The server responds with a HTTP 302 Found redirect either to the Settings UI URL + does not have any API capabilities. The server responds with a HTTP 303 See Other redirect either to the Settings UI URL (if the link was valid) and instructs the user to update their password, or a redirect to the Verification UI URL with a new Verification Flow ID which contains an error message that the verification link was invalid. @@ -2069,7 +2069,7 @@ paths: schema: $ref: '#/components/schemas/selfServiceVerificationFlow' description: selfServiceVerificationFlow - "302": + "303": description: Empty responses are sent when, for example, resources are deleted. The HTTP status code for empty responses is typically 201. "400": @@ -2152,7 +2152,7 @@ paths: schema: $ref: '#/components/schemas/selfServiceVerificationFlow' description: selfServiceVerificationFlow - "302": + "303": description: Empty responses are sent when, for example, resources are deleted. The HTTP status code for empty responses is typically 201. "500": diff --git a/internal/httpclient/api_v0alpha2.go b/internal/httpclient/api_v0alpha2.go index ba815408f974..0e601314fabc 100644 --- a/internal/httpclient/api_v0alpha2.go +++ b/internal/httpclient/api_v0alpha2.go @@ -786,16 +786,16 @@ type V0alpha2Api interface { API flows expect `application/json` to be sent in the body and responds with HTTP 200 and a application/json body with the session token on success; - HTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; + HTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; HTTP 400 on form validation errors. Browser flows expect a Content-Type of `application/x-www-form-urlencoded` or `application/json` to be sent in the body and respond with - a HTTP 302 redirect to the post/after login URL or the `return_to` value if it was set and if the login succeeded; - a HTTP 302 redirect to the login UI URL with the flow ID containing the validation errors otherwise. + a HTTP 303 redirect to the post/after login URL or the `return_to` value if it was set and if the login succeeded; + a HTTP 303 redirect to the login UI URL with the flow ID containing the validation errors otherwise. Browser flows with an accept header of `application/json` will not redirect but instead respond with HTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success; - HTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; + HTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; HTTP 400 on form validation errors. If this endpoint is called with `Accept: application/json` in the header, the response contains the flow without a redirect. In the @@ -823,7 +823,7 @@ type V0alpha2Api interface { * SubmitSelfServiceLogoutFlow Complete Self-Service Logout * This endpoint logs out an identity in a self-service manner. - If the `Accept` HTTP header is not set to `application/json`, the browser will be redirected (HTTP 302 Found) + If the `Accept` HTTP header is not set to `application/json`, the browser will be redirected (HTTP 303 See Other) to the `return_to` parameter of the initial request or fall back to `urls.default_return_to`. If the `Accept` HTTP header is set to `application/json`, a 204 No Content response @@ -872,12 +872,12 @@ type V0alpha2Api interface { `choose_method` expects `flow` (in the URL query) and `email` (in the body) to be sent and works with API- and Browser-initiated flows. For API clients and Browser clients with HTTP Header `Accept: application/json` it either returns a HTTP 200 OK when the form is valid and HTTP 400 OK when the form is invalid. - and a HTTP 302 Found redirect with a fresh recovery flow if the flow was otherwise invalid (e.g. expired). - For Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 302 Found redirect to the Recovery UI URL with the Recovery Flow ID appended. + and a HTTP 303 See Other redirect with a fresh recovery flow if the flow was otherwise invalid (e.g. expired). + For Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 303 See Other redirect to the Recovery UI URL with the Recovery Flow ID appended. `sent_email` is the success state after `choose_method` for the `link` method and allows the user to request another recovery email. It works for both API and Browser-initiated flows and returns the same responses as the flow in `choose_method` state. `passed_challenge` expects a `token` to be sent in the URL query and given the nature of the flow ("sending a recovery link") - does not have any API capabilities. The server responds with a HTTP 302 Found redirect either to the Settings UI URL + does not have any API capabilities. The server responds with a HTTP 303 See Other redirect either to the Settings UI URL (if the link was valid) and instructs the user to update their password, or a redirect to the Recover UI URL with a new Recovery Flow ID which contains an error message that the recovery link was invalid. @@ -901,16 +901,16 @@ type V0alpha2Api interface { API flows expect `application/json` to be sent in the body and respond with HTTP 200 and a application/json body with the created identity success - if the session hook is configured the `session` and `session_token` will also be included; - HTTP 302 redirect to a fresh registration flow if the original flow expired with the appropriate error messages set; + HTTP 303 redirect to a fresh registration flow if the original flow expired with the appropriate error messages set; HTTP 400 on form validation errors. Browser flows expect a Content-Type of `application/x-www-form-urlencoded` or `application/json` to be sent in the body and respond with - a HTTP 302 redirect to the post/after registration URL or the `return_to` value if it was set and if the registration succeeded; - a HTTP 302 redirect to the registration UI URL with the flow ID containing the validation errors otherwise. + a HTTP 303 redirect to the post/after registration URL or the `return_to` value if it was set and if the registration succeeded; + a HTTP 303 redirect to the registration UI URL with the flow ID containing the validation errors otherwise. Browser flows with an accept header of `application/json` will not redirect but instead respond with HTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success; - HTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; + HTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; HTTP 400 on form validation errors. If this endpoint is called with `Accept: application/json` in the header, the response contains the flow without a redirect. In the @@ -941,20 +941,20 @@ type V0alpha2Api interface { API-initiated flows expect `application/json` to be sent in the body and respond with HTTP 200 and an application/json body with the session token on success; - HTTP 302 redirect to a fresh settings flow if the original flow expired with the appropriate error messages set; + HTTP 303 redirect to a fresh settings flow if the original flow expired with the appropriate error messages set; HTTP 400 on form validation errors. HTTP 401 when the endpoint is called without a valid session token. HTTP 403 when `selfservice.flows.settings.privileged_session_max_age` was reached or the session's AAL is too low. Implies that the user needs to re-authenticate. Browser flows without HTTP Header `Accept` or with `Accept: text/*` respond with - a HTTP 302 redirect to the post/after settings URL or the `return_to` value if it was set and if the flow succeeded; - a HTTP 302 redirect to the Settings UI URL with the flow ID containing the validation errors otherwise. - a HTTP 302 redirect to the login endpoint when `selfservice.flows.settings.privileged_session_max_age` was reached or the session's AAL is too low. + a HTTP 303 redirect to the post/after settings URL or the `return_to` value if it was set and if the flow succeeded; + a HTTP 303 redirect to the Settings UI URL with the flow ID containing the validation errors otherwise. + a HTTP 303 redirect to the login endpoint when `selfservice.flows.settings.privileged_session_max_age` was reached or the session's AAL is too low. Browser flows with HTTP Header `Accept: application/json` respond with HTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success; - HTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; + HTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; HTTP 401 when the endpoint is called without a valid session cookie. HTTP 403 when the page is accessed without a session cookie or the session's AAL is too low. HTTP 400 on form validation errors. @@ -998,12 +998,12 @@ type V0alpha2Api interface { `choose_method` expects `flow` (in the URL query) and `email` (in the body) to be sent and works with API- and Browser-initiated flows. For API clients and Browser clients with HTTP Header `Accept: application/json` it either returns a HTTP 200 OK when the form is valid and HTTP 400 OK when the form is invalid - and a HTTP 302 Found redirect with a fresh verification flow if the flow was otherwise invalid (e.g. expired). - For Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 302 Found redirect to the Verification UI URL with the Verification Flow ID appended. + and a HTTP 303 See Other redirect with a fresh verification flow if the flow was otherwise invalid (e.g. expired). + For Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 303 See Other redirect to the Verification UI URL with the Verification Flow ID appended. `sent_email` is the success state after `choose_method` when using the `link` method and allows the user to request another verification email. It works for both API and Browser-initiated flows and returns the same responses as the flow in `choose_method` state. `passed_challenge` expects a `token` to be sent in the URL query and given the nature of the flow ("sending a verification link") - does not have any API capabilities. The server responds with a HTTP 302 Found redirect either to the Settings UI URL + does not have any API capabilities. The server responds with a HTTP 303 See Other redirect either to the Settings UI URL (if the link was valid) and instructs the user to update their password, or a redirect to the Verification UI URL with a new Verification Flow ID which contains an error message that the verification link was invalid. @@ -5795,16 +5795,16 @@ behaves differently for API and browser flows. API flows expect `application/json` to be sent in the body and responds with HTTP 200 and a application/json body with the session token on success; -HTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; +HTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; HTTP 400 on form validation errors. Browser flows expect a Content-Type of `application/x-www-form-urlencoded` or `application/json` to be sent in the body and respond with -a HTTP 302 redirect to the post/after login URL or the `return_to` value if it was set and if the login succeeded; -a HTTP 302 redirect to the login UI URL with the flow ID containing the validation errors otherwise. +a HTTP 303 redirect to the post/after login URL or the `return_to` value if it was set and if the login succeeded; +a HTTP 303 redirect to the login UI URL with the flow ID containing the validation errors otherwise. Browser flows with an accept header of `application/json` will not redirect but instead respond with HTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success; -HTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; +HTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; HTTP 400 on form validation errors. If this endpoint is called with `Accept: application/json` in the header, the response contains the flow without a redirect. In the @@ -5968,7 +5968,7 @@ func (r V0alpha2ApiApiSubmitSelfServiceLogoutFlowRequest) Execute() (*http.Respo * SubmitSelfServiceLogoutFlow Complete Self-Service Logout * This endpoint logs out an identity in a self-service manner. -If the `Accept` HTTP header is not set to `application/json`, the browser will be redirected (HTTP 302 Found) +If the `Accept` HTTP header is not set to `application/json`, the browser will be redirected (HTTP 303 See Other) to the `return_to` parameter of the initial request or fall back to `urls.default_return_to`. If the `Accept` HTTP header is set to `application/json`, a 204 No Content response @@ -6232,12 +6232,12 @@ behaves differently for API and browser flows and has several states: `choose_method` expects `flow` (in the URL query) and `email` (in the body) to be sent and works with API- and Browser-initiated flows. For API clients and Browser clients with HTTP Header `Accept: application/json` it either returns a HTTP 200 OK when the form is valid and HTTP 400 OK when the form is invalid. -and a HTTP 302 Found redirect with a fresh recovery flow if the flow was otherwise invalid (e.g. expired). -For Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 302 Found redirect to the Recovery UI URL with the Recovery Flow ID appended. +and a HTTP 303 See Other redirect with a fresh recovery flow if the flow was otherwise invalid (e.g. expired). +For Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 303 See Other redirect to the Recovery UI URL with the Recovery Flow ID appended. `sent_email` is the success state after `choose_method` for the `link` method and allows the user to request another recovery email. It works for both API and Browser-initiated flows and returns the same responses as the flow in `choose_method` state. `passed_challenge` expects a `token` to be sent in the URL query and given the nature of the flow ("sending a recovery link") -does not have any API capabilities. The server responds with a HTTP 302 Found redirect either to the Settings UI URL +does not have any API capabilities. The server responds with a HTTP 303 See Other redirect either to the Settings UI URL (if the link was valid) and instructs the user to update their password, or a redirect to the Recover UI URL with a new Recovery Flow ID which contains an error message that the recovery link was invalid. @@ -6387,16 +6387,16 @@ behaves differently for API and browser flows. API flows expect `application/json` to be sent in the body and respond with HTTP 200 and a application/json body with the created identity success - if the session hook is configured the `session` and `session_token` will also be included; -HTTP 302 redirect to a fresh registration flow if the original flow expired with the appropriate error messages set; +HTTP 303 redirect to a fresh registration flow if the original flow expired with the appropriate error messages set; HTTP 400 on form validation errors. Browser flows expect a Content-Type of `application/x-www-form-urlencoded` or `application/json` to be sent in the body and respond with -a HTTP 302 redirect to the post/after registration URL or the `return_to` value if it was set and if the registration succeeded; -a HTTP 302 redirect to the registration UI URL with the flow ID containing the validation errors otherwise. +a HTTP 303 redirect to the post/after registration URL or the `return_to` value if it was set and if the registration succeeded; +a HTTP 303 redirect to the registration UI URL with the flow ID containing the validation errors otherwise. Browser flows with an accept header of `application/json` will not redirect but instead respond with HTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success; -HTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; +HTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; HTTP 400 on form validation errors. If this endpoint is called with `Accept: application/json` in the header, the response contains the flow without a redirect. In the @@ -6565,20 +6565,20 @@ behaves differently for API and browser flows. API-initiated flows expect `application/json` to be sent in the body and respond with HTTP 200 and an application/json body with the session token on success; -HTTP 302 redirect to a fresh settings flow if the original flow expired with the appropriate error messages set; +HTTP 303 redirect to a fresh settings flow if the original flow expired with the appropriate error messages set; HTTP 400 on form validation errors. HTTP 401 when the endpoint is called without a valid session token. HTTP 403 when `selfservice.flows.settings.privileged_session_max_age` was reached or the session's AAL is too low. Implies that the user needs to re-authenticate. Browser flows without HTTP Header `Accept` or with `Accept: text/*` respond with -a HTTP 302 redirect to the post/after settings URL or the `return_to` value if it was set and if the flow succeeded; -a HTTP 302 redirect to the Settings UI URL with the flow ID containing the validation errors otherwise. -a HTTP 302 redirect to the login endpoint when `selfservice.flows.settings.privileged_session_max_age` was reached or the session's AAL is too low. +a HTTP 303 redirect to the post/after settings URL or the `return_to` value if it was set and if the flow succeeded; +a HTTP 303 redirect to the Settings UI URL with the flow ID containing the validation errors otherwise. +a HTTP 303 redirect to the login endpoint when `selfservice.flows.settings.privileged_session_max_age` was reached or the session's AAL is too low. Browser flows with HTTP Header `Accept: application/json` respond with HTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success; -HTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; +HTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; HTTP 401 when the endpoint is called without a valid session cookie. HTTP 403 when the page is accessed without a session cookie or the session's AAL is too low. HTTP 400 on form validation errors. @@ -6783,12 +6783,12 @@ behaves differently for API and browser flows and has several states: `choose_method` expects `flow` (in the URL query) and `email` (in the body) to be sent and works with API- and Browser-initiated flows. For API clients and Browser clients with HTTP Header `Accept: application/json` it either returns a HTTP 200 OK when the form is valid and HTTP 400 OK when the form is invalid -and a HTTP 302 Found redirect with a fresh verification flow if the flow was otherwise invalid (e.g. expired). -For Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 302 Found redirect to the Verification UI URL with the Verification Flow ID appended. +and a HTTP 303 See Other redirect with a fresh verification flow if the flow was otherwise invalid (e.g. expired). +For Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 303 See Other redirect to the Verification UI URL with the Verification Flow ID appended. `sent_email` is the success state after `choose_method` when using the `link` method and allows the user to request another verification email. It works for both API and Browser-initiated flows and returns the same responses as the flow in `choose_method` state. `passed_challenge` expects a `token` to be sent in the URL query and given the nature of the flow ("sending a verification link") -does not have any API capabilities. The server responds with a HTTP 302 Found redirect either to the Settings UI URL +does not have any API capabilities. The server responds with a HTTP 303 See Other redirect either to the Settings UI URL (if the link was valid) and instructs the user to update their password, or a redirect to the Verification UI URL with a new Verification Flow ID which contains an error message that the verification link was invalid. diff --git a/selfservice/errorx/manager.go b/selfservice/errorx/manager.go index 517aa90eb85e..26778c23c4c9 100644 --- a/selfservice/errorx/manager.go +++ b/selfservice/errorx/manager.go @@ -70,5 +70,5 @@ func (m *Manager) Forward(ctx context.Context, w http.ResponseWriter, r *http.Re return } - http.Redirect(w, r, to, http.StatusFound) + http.Redirect(w, r, to, http.StatusSeeOther) } diff --git a/selfservice/flow/login/error.go b/selfservice/flow/login/error.go index a741c5afe9ef..a22a351f5231 100644 --- a/selfservice/flow/login/error.go +++ b/selfservice/flow/login/error.go @@ -111,7 +111,7 @@ func (s *ErrorHandler) WriteFlowError(w http.ResponseWriter, r *http.Request, f } if f.Type == flow.TypeBrowser && !x.IsJSONRequest(r) { - http.Redirect(w, r, f.AppendTo(s.d.Config(r.Context()).SelfServiceFlowLoginUI()).String(), http.StatusFound) + http.Redirect(w, r, f.AppendTo(s.d.Config(r.Context()).SelfServiceFlowLoginUI()).String(), http.StatusSeeOther) return } diff --git a/selfservice/flow/login/handler.go b/selfservice/flow/login/handler.go index 83537da08f97..4da8153d27ed 100644 --- a/selfservice/flow/login/handler.go +++ b/selfservice/flow/login/handler.go @@ -319,7 +319,7 @@ type initializeSelfServiceLoginFlowForBrowsers struct { // // Responses: // 200: selfServiceLoginFlow -// 302: emptyResponse +// 303: emptyResponse // 400: jsonError // 500: jsonError func (h *Handler) initBrowserFlow(w http.ResponseWriter, r *http.Request, ps httprouter.Params) { @@ -476,16 +476,16 @@ type submitSelfServiceLoginFlowBody struct{} // // API flows expect `application/json` to be sent in the body and responds with // - HTTP 200 and a application/json body with the session token on success; -// - HTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; +// - HTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; // - HTTP 400 on form validation errors. // // Browser flows expect a Content-Type of `application/x-www-form-urlencoded` or `application/json` to be sent in the body and respond with -// - a HTTP 302 redirect to the post/after login URL or the `return_to` value if it was set and if the login succeeded; -// - a HTTP 302 redirect to the login UI URL with the flow ID containing the validation errors otherwise. +// - a HTTP 303 redirect to the post/after login URL or the `return_to` value if it was set and if the login succeeded; +// - a HTTP 303 redirect to the login UI URL with the flow ID containing the validation errors otherwise. // // Browser flows with an accept header of `application/json` will not redirect but instead respond with // - HTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success; -// - HTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; +// - HTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; // - HTTP 400 on form validation errors. // // If this endpoint is called with `Accept: application/json` in the header, the response contains the flow without a redirect. In the @@ -513,7 +513,7 @@ type submitSelfServiceLoginFlowBody struct{} // // Responses: // 200: successfulSelfServiceLoginWithoutBrowser -// 302: emptyResponse +// 303: emptyResponse // 400: selfServiceLoginFlow // 422: selfServiceBrowserLocationChangeRequiredError // 500: jsonError diff --git a/selfservice/flow/login/handler_test.go b/selfservice/flow/login/handler_test.go index 506e1a232a5d..7dbf63086b67 100644 --- a/selfservice/flow/login/handler_test.go +++ b/selfservice/flow/login/handler_test.go @@ -462,7 +462,26 @@ func TestFlowLifecycle(t *testing.T) { assertion(body, true, false) assert.Contains(t, res.Request.URL.String(), loginTS.URL) }) + + t.Run("case=redirects with 303", func(t *testing.T) { + c := &http.Client{} + // don't get the reference, instead copy the values, so we don't alter the client directly. + *c = *ts.Client() + // prevent the redirect + c.CheckRedirect = func(req *http.Request, via []*http.Request) error { + return http.ErrUseLastResponse + } + req, err := http.NewRequest("GET", ts.URL+login.RouteInitBrowserFlow, nil) + require.NoError(t, err) + + res, err := c.Do(req) + require.NoError(t, err) + // here we check that the redirect status is 303 + require.Equal(t, http.StatusSeeOther, res.StatusCode) + defer res.Body.Close() + }) }) + t.Run("case=relative redirect when self-service login ui is a relative URL", func(t *testing.T) { reg.Config(context.Background()).MustSet(config.ViperKeySelfServiceLoginUI, "/login-ts") assert.Regexp( diff --git a/selfservice/flow/logout/handler.go b/selfservice/flow/logout/handler.go index 9b05e3931da9..c19f267a37ae 100644 --- a/selfservice/flow/logout/handler.go +++ b/selfservice/flow/logout/handler.go @@ -218,7 +218,7 @@ type submitSelfServiceLogoutFlow struct { // // This endpoint logs out an identity in a self-service manner. // -// If the `Accept` HTTP header is not set to `application/json`, the browser will be redirected (HTTP 302 Found) +// If the `Accept` HTTP header is not set to `application/json`, the browser will be redirected (HTTP 303 See Other) // to the `return_to` parameter of the initial request or fall back to `urls.default_return_to`. // // If the `Accept` HTTP header is set to `application/json`, a 204 No Content response @@ -236,7 +236,7 @@ type submitSelfServiceLogoutFlow struct { // Schemes: http, https // // Responses: -// 302: emptyResponse +// 303: emptyResponse // 204: emptyResponse // 500: jsonError func (h *Handler) submitLogout(w http.ResponseWriter, r *http.Request, ps httprouter.Params) { diff --git a/selfservice/flow/logout/handler_test.go b/selfservice/flow/logout/handler_test.go index e81df42f741b..288ad037eb60 100644 --- a/selfservice/flow/logout/handler_test.go +++ b/selfservice/flow/logout/handler_test.go @@ -223,4 +223,22 @@ func TestLogout(t *testing.T) { assert.EqualValues(t, http.StatusUnauthorized, res.StatusCode) assert.EqualValues(t, "No active session was found in this request.", gjson.GetBytes(body, "error.reason").String(), "%s", body) }) + + t.Run("case=init logout through browser does 303 redirect", func(t *testing.T) { + // init the logout + hc, logoutUrl := getLogoutUrl(t) + // prevent the redirect, so we can get check the status code + hc.CheckRedirect = func(req *http.Request, via []*http.Request) error { + return http.ErrUseLastResponse + } + // submit the login + req, err := http.NewRequest("GET", logoutUrl, nil) + require.NoError(t, err) + + res, err := hc.Do(req) + require.NoError(t, err) + // here we check that the redirect status is 303 + require.Equal(t, http.StatusSeeOther, res.StatusCode) + defer res.Body.Close() + }) } diff --git a/selfservice/flow/recovery/handler.go b/selfservice/flow/recovery/handler.go index 92f4efd3f53a..20482545b9c8 100644 --- a/selfservice/flow/recovery/handler.go +++ b/selfservice/flow/recovery/handler.go @@ -164,7 +164,7 @@ type initializeSelfServiceRecoveryFlowWithoutBrowser struct { // // Responses: // 200: selfServiceRecoveryFlow -// 302: emptyResponse +// 303: emptyResponse // 400: jsonError // 500: jsonError func (h *Handler) initBrowserFlow(w http.ResponseWriter, r *http.Request, _ httprouter.Params) { @@ -320,12 +320,12 @@ type submitSelfServiceRecoveryFlowBody struct{} // - `choose_method` expects `flow` (in the URL query) and `email` (in the body) to be sent // and works with API- and Browser-initiated flows. // - For API clients and Browser clients with HTTP Header `Accept: application/json` it either returns a HTTP 200 OK when the form is valid and HTTP 400 OK when the form is invalid. -// and a HTTP 302 Found redirect with a fresh recovery flow if the flow was otherwise invalid (e.g. expired). -// - For Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 302 Found redirect to the Recovery UI URL with the Recovery Flow ID appended. +// and a HTTP 303 See Other redirect with a fresh recovery flow if the flow was otherwise invalid (e.g. expired). +// - For Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 303 See Other redirect to the Recovery UI URL with the Recovery Flow ID appended. // - `sent_email` is the success state after `choose_method` for the `link` method and allows the user to request another recovery email. It // works for both API and Browser-initiated flows and returns the same responses as the flow in `choose_method` state. // - `passed_challenge` expects a `token` to be sent in the URL query and given the nature of the flow ("sending a recovery link") -// does not have any API capabilities. The server responds with a HTTP 302 Found redirect either to the Settings UI URL +// does not have any API capabilities. The server responds with a HTTP 303 See Other redirect either to the Settings UI URL // (if the link was valid) and instructs the user to update their password, or a redirect to the Recover UI URL with // a new Recovery Flow ID which contains an error message that the recovery link was invalid. // @@ -343,7 +343,7 @@ type submitSelfServiceRecoveryFlowBody struct{} // Responses: // 200: selfServiceRecoveryFlow // 400: selfServiceRecoveryFlow -// 302: emptyResponse +// 303: emptyResponse // 500: jsonError func (h *Handler) submitFlow(w http.ResponseWriter, r *http.Request, ps httprouter.Params) { rid, err := flow.GetFlowID(r) diff --git a/selfservice/flow/recovery/handler_test.go b/selfservice/flow/recovery/handler_test.go index 50366de576ae..8af92bb9f2da 100644 --- a/selfservice/flow/recovery/handler_test.go +++ b/selfservice/flow/recovery/handler_test.go @@ -154,10 +154,12 @@ func TestInitFlow(t *testing.T) { assertion(body, false, false) assert.Contains(t, res.Request.URL.String(), recoveryTS.URL) }) + t.Run("case=fails on authenticated request", func(t *testing.T) { res, _ := initAuthenticatedFlow(t, false, false) assert.Contains(t, res.Request.URL.String(), "https://www.ory.sh") }) + t.Run("case=relative redirect when self-service recovery ui is a relative URL", func(t *testing.T) { reg.Config(context.Background()).MustSet(config.ViperKeySelfServiceRecoveryUI, "/recovery-ts") assert.Regexp( @@ -167,6 +169,23 @@ func TestInitFlow(t *testing.T) { ) }) + t.Run("case=redirects with 303", func(t *testing.T) { + c := &http.Client{} + // don't get the reference, instead copy the values, so we don't alter the client directly. + *c = *publicTS.Client() + // prevent the redirect + c.CheckRedirect = func(req *http.Request, via []*http.Request) error { + return http.ErrUseLastResponse + } + req, err := http.NewRequest("GET", publicTS.URL+recovery.RouteInitBrowserFlow, nil) + require.NoError(t, err) + + res, err := c.Do(req) + require.NoError(t, err) + // here we check that the redirect status is 303 + require.Equal(t, http.StatusSeeOther, res.StatusCode) + defer res.Body.Close() + }) }) } diff --git a/selfservice/flow/registration/handler.go b/selfservice/flow/registration/handler.go index 42b595af0ab3..867a0f31aa44 100644 --- a/selfservice/flow/registration/handler.go +++ b/selfservice/flow/registration/handler.go @@ -224,7 +224,7 @@ type initializeSelfServiceRegistrationFlowForBrowsers struct { // // Responses: // 200: selfServiceRegistrationFlow -// 302: emptyResponse +// 303: emptyResponse // 500: jsonError func (h *Handler) initBrowserFlow(w http.ResponseWriter, r *http.Request, ps httprouter.Params) { a, err := h.NewRegistrationFlow(w, r, flow.TypeBrowser) @@ -375,16 +375,16 @@ type submitSelfServiceRegistrationFlowBody struct{} // API flows expect `application/json` to be sent in the body and respond with // - HTTP 200 and a application/json body with the created identity success - if the session hook is configured the // `session` and `session_token` will also be included; -// - HTTP 302 redirect to a fresh registration flow if the original flow expired with the appropriate error messages set; +// - HTTP 303 redirect to a fresh registration flow if the original flow expired with the appropriate error messages set; // - HTTP 400 on form validation errors. // // Browser flows expect a Content-Type of `application/x-www-form-urlencoded` or `application/json` to be sent in the body and respond with -// - a HTTP 302 redirect to the post/after registration URL or the `return_to` value if it was set and if the registration succeeded; -// - a HTTP 302 redirect to the registration UI URL with the flow ID containing the validation errors otherwise. +// - a HTTP 303 redirect to the post/after registration URL or the `return_to` value if it was set and if the registration succeeded; +// - a HTTP 303 redirect to the registration UI URL with the flow ID containing the validation errors otherwise. // // Browser flows with an accept header of `application/json` will not redirect but instead respond with // - HTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success; -// - HTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; +// - HTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; // - HTTP 400 on form validation errors. // // If this endpoint is called with `Accept: application/json` in the header, the response contains the flow without a redirect. In the @@ -409,7 +409,7 @@ type submitSelfServiceRegistrationFlowBody struct{} // // Responses: // 200: successfulSelfServiceRegistrationWithoutBrowser -// 302: emptyResponse +// 303: emptyResponse // 400: selfServiceRegistrationFlow // 422: selfServiceBrowserLocationChangeRequiredError // 500: jsonError @@ -428,7 +428,7 @@ func (h *Handler) submitFlow(w http.ResponseWriter, r *http.Request, _ httproute if _, err := h.d.SessionManager().FetchFromRequest(r.Context(), r); err == nil { if f.Type == flow.TypeBrowser { - http.Redirect(w, r, h.d.Config(r.Context()).SelfServiceBrowserDefaultReturnTo().String(), http.StatusFound) + http.Redirect(w, r, h.d.Config(r.Context()).SelfServiceBrowserDefaultReturnTo().String(), http.StatusSeeOther) return } diff --git a/selfservice/flow/registration/handler_test.go b/selfservice/flow/registration/handler_test.go index 8c8f2bcfdc62..14b067f75aea 100644 --- a/selfservice/flow/registration/handler_test.go +++ b/selfservice/flow/registration/handler_test.go @@ -167,6 +167,24 @@ func TestInitFlow(t *testing.T) { testhelpers.GetSelfServiceRedirectLocation(t, publicTS.URL+registration.RouteInitBrowserFlow), ) }) + + t.Run("case=redirects with 303", func(t *testing.T) { + c := &http.Client{} + // don't get the reference, instead copy the values, so we don't alter the client directly. + *c = *publicTS.Client() + // prevent the redirect + c.CheckRedirect = func(req *http.Request, via []*http.Request) error { + return http.ErrUseLastResponse + } + req, err := http.NewRequest("GET", publicTS.URL+registration.RouteInitBrowserFlow, nil) + require.NoError(t, err) + + res, err := c.Do(req) + require.NoError(t, err) + // here we check that the redirect status is 303 + require.Equal(t, http.StatusSeeOther, res.StatusCode) + defer res.Body.Close() + }) }) } diff --git a/selfservice/flow/settings/handler.go b/selfservice/flow/settings/handler.go index 2d62aa94c723..7287e6a67668 100644 --- a/selfservice/flow/settings/handler.go +++ b/selfservice/flow/settings/handler.go @@ -86,7 +86,7 @@ func (h *Handler) RegisterPublicRoutes(public *x.RouterPublic) { if x.IsJSONRequest(r) { h.d.Writer().WriteError(w, r, session.NewErrNoActiveSessionFound()) } else { - http.Redirect(w, r, h.d.Config(r.Context()).SelfServiceFlowLoginUI().String(), http.StatusFound) + http.Redirect(w, r, h.d.Config(r.Context()).SelfServiceFlowLoginUI().String(), http.StatusSeeOther) } })) @@ -255,7 +255,7 @@ type initializeSelfServiceSettingsFlowForBrowsers struct { // // Responses: // 200: selfServiceSettingsFlow -// 302: emptyResponse +// 303: emptyResponse // 401: jsonError // 403: jsonError // 400: jsonError @@ -427,20 +427,20 @@ type submitSelfServiceSettingsFlowBody struct{} // // API-initiated flows expect `application/json` to be sent in the body and respond with // - HTTP 200 and an application/json body with the session token on success; -// - HTTP 302 redirect to a fresh settings flow if the original flow expired with the appropriate error messages set; +// - HTTP 303 redirect to a fresh settings flow if the original flow expired with the appropriate error messages set; // - HTTP 400 on form validation errors. // - HTTP 401 when the endpoint is called without a valid session token. // - HTTP 403 when `selfservice.flows.settings.privileged_session_max_age` was reached or the session's AAL is too low. // Implies that the user needs to re-authenticate. // // Browser flows without HTTP Header `Accept` or with `Accept: text/*` respond with -// - a HTTP 302 redirect to the post/after settings URL or the `return_to` value if it was set and if the flow succeeded; -// - a HTTP 302 redirect to the Settings UI URL with the flow ID containing the validation errors otherwise. -// - a HTTP 302 redirect to the login endpoint when `selfservice.flows.settings.privileged_session_max_age` was reached or the session's AAL is too low. +// - a HTTP 303 redirect to the post/after settings URL or the `return_to` value if it was set and if the flow succeeded; +// - a HTTP 303 redirect to the Settings UI URL with the flow ID containing the validation errors otherwise. +// - a HTTP 303 redirect to the login endpoint when `selfservice.flows.settings.privileged_session_max_age` was reached or the session's AAL is too low. // // Browser flows with HTTP Header `Accept: application/json` respond with // - HTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success; -// - HTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; +// - HTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set; // - HTTP 401 when the endpoint is called without a valid session cookie. // - HTTP 403 when the page is accessed without a session cookie or the session's AAL is too low. // - HTTP 400 on form validation errors. @@ -480,7 +480,7 @@ type submitSelfServiceSettingsFlowBody struct{} // // Responses: // 200: selfServiceSettingsFlow -// 302: emptyResponse +// 303: emptyResponse // 400: selfServiceSettingsFlow // 401: jsonError // 403: jsonError diff --git a/selfservice/flow/settings/handler_test.go b/selfservice/flow/settings/handler_test.go index 9c98b6f288aa..f6dc207f267d 100644 --- a/selfservice/flow/settings/handler_test.go +++ b/selfservice/flow/settings/handler_test.go @@ -159,6 +159,22 @@ func TestHandler(t *testing.T) { assert.Contains(t, res.Request.URL.String(), reg.Config(context.Background()).SelfServiceFlowLoginUI().String()) assert.EqualValues(t, "Please complete the second authentication challenge.", gjson.GetBytes(body, "ui.messages.0.text").String(), "%s", body) }) + + t.Run("case=redirects with 303", func(t *testing.T) { + c := testhelpers.NewHTTPClientWithArbitrarySessionCookie(t, reg) + // prevent the redirect + c.CheckRedirect = func(req *http.Request, via []*http.Request) error { + return http.ErrUseLastResponse + } + req, err := http.NewRequest("GET", publicTS.URL+settings.RouteInitBrowserFlow, nil) + require.NoError(t, err) + + res, err := c.Do(req) + require.NoError(t, err) + // here we check that the redirect status is 303 + require.Equal(t, http.StatusSeeOther, res.StatusCode) + defer res.Body.Close() + }) }) t.Run("description=init a flow as SPA", func(t *testing.T) { diff --git a/selfservice/flow/verification/handler.go b/selfservice/flow/verification/handler.go index de2c3243209e..fea9f6472c36 100644 --- a/selfservice/flow/verification/handler.go +++ b/selfservice/flow/verification/handler.go @@ -148,7 +148,7 @@ type initializeSelfServiceVerificationFlowForBrowsers struct { // // Responses: // 200: selfServiceVerificationFlow -// 302: emptyResponse +// 303: emptyResponse // 500: jsonError func (h *Handler) initBrowserFlow(w http.ResponseWriter, r *http.Request, ps httprouter.Params) { if !h.d.Config(r.Context()).SelfServiceFlowVerificationEnabled() { @@ -302,12 +302,12 @@ type submitSelfServiceVerificationFlowBody struct{} // - `choose_method` expects `flow` (in the URL query) and `email` (in the body) to be sent // and works with API- and Browser-initiated flows. // - For API clients and Browser clients with HTTP Header `Accept: application/json` it either returns a HTTP 200 OK when the form is valid and HTTP 400 OK when the form is invalid -// and a HTTP 302 Found redirect with a fresh verification flow if the flow was otherwise invalid (e.g. expired). -// - For Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 302 Found redirect to the Verification UI URL with the Verification Flow ID appended. +// and a HTTP 303 See Other redirect with a fresh verification flow if the flow was otherwise invalid (e.g. expired). +// - For Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 303 See Other redirect to the Verification UI URL with the Verification Flow ID appended. // - `sent_email` is the success state after `choose_method` when using the `link` method and allows the user to request another verification email. It // works for both API and Browser-initiated flows and returns the same responses as the flow in `choose_method` state. // - `passed_challenge` expects a `token` to be sent in the URL query and given the nature of the flow ("sending a verification link") -// does not have any API capabilities. The server responds with a HTTP 302 Found redirect either to the Settings UI URL +// does not have any API capabilities. The server responds with a HTTP 303 See Other redirect either to the Settings UI URL // (if the link was valid) and instructs the user to update their password, or a redirect to the Verification UI URL with // a new Verification Flow ID which contains an error message that the verification link was invalid. // @@ -325,7 +325,7 @@ type submitSelfServiceVerificationFlowBody struct{} // Responses: // 200: selfServiceVerificationFlow // 400: selfServiceVerificationFlow -// 302: emptyResponse +// 303: emptyResponse // 500: jsonError func (h *Handler) submitFlow(w http.ResponseWriter, r *http.Request, ps httprouter.Params) { rid, err := flow.GetFlowID(r) @@ -372,7 +372,7 @@ func (h *Handler) submitFlow(w http.ResponseWriter, r *http.Request, ps httprout } if f.Type == flow.TypeBrowser && !x.IsJSONRequest(r) { - http.Redirect(w, r, f.AppendTo(h.d.Config(r.Context()).SelfServiceFlowVerificationUI()).String(), http.StatusFound) + http.Redirect(w, r, f.AppendTo(h.d.Config(r.Context()).SelfServiceFlowVerificationUI()).String(), http.StatusSeeOther) return } diff --git a/selfservice/flow/verification/handler_test.go b/selfservice/flow/verification/handler_test.go index f8e6809116a9..d4c8e8c194d5 100644 --- a/selfservice/flow/verification/handler_test.go +++ b/selfservice/flow/verification/handler_test.go @@ -151,4 +151,25 @@ func TestGetFlow(t *testing.T) { res, _ := x.EasyGet(t, client, public.URL+verification.RouteGetFlow+"?id="+x.NewUUID().String()) assert.EqualValues(t, http.StatusNotFound, res.StatusCode) }) + + t.Run("case=redirects with 303", func(t *testing.T) { + router := x.NewRouterPublic() + ts, _ := testhelpers.NewKratosServerWithRouters(t, reg, router, x.NewRouterAdmin()) + + c := &http.Client{} + // don't get the reference, instead copy the values, so we don't alter the client directly. + *c = *ts.Client() + // prevent the redirect + c.CheckRedirect = func(req *http.Request, via []*http.Request) error { + return http.ErrUseLastResponse + } + req, err := http.NewRequest("GET", ts.URL+verification.RouteInitBrowserFlow, nil) + require.NoError(t, err) + + res, err := c.Do(req) + require.NoError(t, err) + // here we check that the redirect status is 303 + require.Equal(t, http.StatusSeeOther, res.StatusCode) + defer res.Body.Close() + }) } diff --git a/spec/api.json b/spec/api.json index 894aaa787813..10920f86d934 100755 --- a/spec/api.json +++ b/spec/api.json @@ -2833,7 +2833,7 @@ }, "/self-service/login": { "post": { - "description": ":::info\n\nThis endpoint is EXPERIMENTAL and subject to potential breaking changes in the future.\n\n:::\n\nUse this endpoint to complete a login flow. This endpoint\nbehaves differently for API and browser flows.\n\nAPI flows expect `application/json` to be sent in the body and responds with\nHTTP 200 and a application/json body with the session token on success;\nHTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set;\nHTTP 400 on form validation errors.\n\nBrowser flows expect a Content-Type of `application/x-www-form-urlencoded` or `application/json` to be sent in the body and respond with\na HTTP 302 redirect to the post/after login URL or the `return_to` value if it was set and if the login succeeded;\na HTTP 302 redirect to the login UI URL with the flow ID containing the validation errors otherwise.\n\nBrowser flows with an accept header of `application/json` will not redirect but instead respond with\nHTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success;\nHTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set;\nHTTP 400 on form validation errors.\n\nIf this endpoint is called with `Accept: application/json` in the header, the response contains the flow without a redirect. In the\ncase of an error, the `error.id` of the JSON response body can be one of:\n\n`session_already_available`: The user is already signed in.\n`security_csrf_violation`: Unable to fetch the flow because a CSRF violation occurred.\n`security_identity_mismatch`: The requested `?return_to` address is not allowed to be used. Adjust this in the configuration!\n`browser_location_change_required`: Usually sent when an AJAX request indicates that the browser needs to open a specific URL.\nMost likely used in Social Sign In flows.\n\nMore information can be found at [Ory Kratos User Login and User Registration Documentation](https://www.ory.sh/docs/next/kratos/self-service/flows/user-login-user-registration).", + "description": ":::info\n\nThis endpoint is EXPERIMENTAL and subject to potential breaking changes in the future.\n\n:::\n\nUse this endpoint to complete a login flow. This endpoint\nbehaves differently for API and browser flows.\n\nAPI flows expect `application/json` to be sent in the body and responds with\nHTTP 200 and a application/json body with the session token on success;\nHTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set;\nHTTP 400 on form validation errors.\n\nBrowser flows expect a Content-Type of `application/x-www-form-urlencoded` or `application/json` to be sent in the body and respond with\na HTTP 303 redirect to the post/after login URL or the `return_to` value if it was set and if the login succeeded;\na HTTP 303 redirect to the login UI URL with the flow ID containing the validation errors otherwise.\n\nBrowser flows with an accept header of `application/json` will not redirect but instead respond with\nHTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success;\nHTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set;\nHTTP 400 on form validation errors.\n\nIf this endpoint is called with `Accept: application/json` in the header, the response contains the flow without a redirect. In the\ncase of an error, the `error.id` of the JSON response body can be one of:\n\n`session_already_available`: The user is already signed in.\n`security_csrf_violation`: Unable to fetch the flow because a CSRF violation occurred.\n`security_identity_mismatch`: The requested `?return_to` address is not allowed to be used. Adjust this in the configuration!\n`browser_location_change_required`: Usually sent when an AJAX request indicates that the browser needs to open a specific URL.\nMost likely used in Social Sign In flows.\n\nMore information can be found at [Ory Kratos User Login and User Registration Documentation](https://www.ory.sh/docs/next/kratos/self-service/flows/user-login-user-registration).", "operationId": "submitSelfServiceLoginFlow", "parameters": [ { @@ -2880,7 +2880,7 @@ }, "description": "successfulSelfServiceLoginWithoutBrowser" }, - "302": { + "303": { "$ref": "#/components/responses/emptyResponse" }, "400": { @@ -3029,7 +3029,7 @@ }, "description": "selfServiceLoginFlow" }, - "302": { + "303": { "$ref": "#/components/responses/emptyResponse" }, "400": { @@ -3142,7 +3142,7 @@ }, "/self-service/logout": { "get": { - "description": "This endpoint logs out an identity in a self-service manner.\n\nIf the `Accept` HTTP header is not set to `application/json`, the browser will be redirected (HTTP 302 Found)\nto the `return_to` parameter of the initial request or fall back to `urls.default_return_to`.\n\nIf the `Accept` HTTP header is set to `application/json`, a 204 No Content response\nwill be sent on successful logout instead.\n\nThis endpoint is NOT INTENDED for API clients and only works\nwith browsers (Chrome, Firefox, ...). For API clients you can\ncall the `/self-service/logout/api` URL directly with the Ory Session Token.\n\nMore information can be found at [Ory Kratos User Logout Documentation](https://www.ory.sh/docs/next/kratos/self-service/flows/user-logout).", + "description": "This endpoint logs out an identity in a self-service manner.\n\nIf the `Accept` HTTP header is not set to `application/json`, the browser will be redirected (HTTP 303 See Other)\nto the `return_to` parameter of the initial request or fall back to `urls.default_return_to`.\n\nIf the `Accept` HTTP header is set to `application/json`, a 204 No Content response\nwill be sent on successful logout instead.\n\nThis endpoint is NOT INTENDED for API clients and only works\nwith browsers (Chrome, Firefox, ...). For API clients you can\ncall the `/self-service/logout/api` URL directly with the Ory Session Token.\n\nMore information can be found at [Ory Kratos User Logout Documentation](https://www.ory.sh/docs/next/kratos/self-service/flows/user-logout).", "operationId": "submitSelfServiceLogoutFlow", "parameters": [ { @@ -3166,7 +3166,7 @@ "204": { "$ref": "#/components/responses/emptyResponse" }, - "302": { + "303": { "$ref": "#/components/responses/emptyResponse" }, "500": { @@ -3286,7 +3286,7 @@ }, "/self-service/recovery": { "post": { - "description": "Use this endpoint to complete a recovery flow. This endpoint\nbehaves differently for API and browser flows and has several states:\n\n`choose_method` expects `flow` (in the URL query) and `email` (in the body) to be sent\nand works with API- and Browser-initiated flows.\nFor API clients and Browser clients with HTTP Header `Accept: application/json` it either returns a HTTP 200 OK when the form is valid and HTTP 400 OK when the form is invalid.\nand a HTTP 302 Found redirect with a fresh recovery flow if the flow was otherwise invalid (e.g. expired).\nFor Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 302 Found redirect to the Recovery UI URL with the Recovery Flow ID appended.\n`sent_email` is the success state after `choose_method` for the `link` method and allows the user to request another recovery email. It\nworks for both API and Browser-initiated flows and returns the same responses as the flow in `choose_method` state.\n`passed_challenge` expects a `token` to be sent in the URL query and given the nature of the flow (\"sending a recovery link\")\ndoes not have any API capabilities. The server responds with a HTTP 302 Found redirect either to the Settings UI URL\n(if the link was valid) and instructs the user to update their password, or a redirect to the Recover UI URL with\na new Recovery Flow ID which contains an error message that the recovery link was invalid.\n\nMore information can be found at [Ory Kratos Account Recovery Documentation](../self-service/flows/account-recovery.mdx).", + "description": "Use this endpoint to complete a recovery flow. This endpoint\nbehaves differently for API and browser flows and has several states:\n\n`choose_method` expects `flow` (in the URL query) and `email` (in the body) to be sent\nand works with API- and Browser-initiated flows.\nFor API clients and Browser clients with HTTP Header `Accept: application/json` it either returns a HTTP 200 OK when the form is valid and HTTP 400 OK when the form is invalid.\nand a HTTP 303 See Other redirect with a fresh recovery flow if the flow was otherwise invalid (e.g. expired).\nFor Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 303 See Other redirect to the Recovery UI URL with the Recovery Flow ID appended.\n`sent_email` is the success state after `choose_method` for the `link` method and allows the user to request another recovery email. It\nworks for both API and Browser-initiated flows and returns the same responses as the flow in `choose_method` state.\n`passed_challenge` expects a `token` to be sent in the URL query and given the nature of the flow (\"sending a recovery link\")\ndoes not have any API capabilities. The server responds with a HTTP 303 See Other redirect either to the Settings UI URL\n(if the link was valid) and instructs the user to update their password, or a redirect to the Recover UI URL with\na new Recovery Flow ID which contains an error message that the recovery link was invalid.\n\nMore information can be found at [Ory Kratos Account Recovery Documentation](../self-service/flows/account-recovery.mdx).", "operationId": "submitSelfServiceRecoveryFlow", "parameters": [ { @@ -3333,7 +3333,7 @@ }, "description": "selfServiceRecoveryFlow" }, - "302": { + "303": { "$ref": "#/components/responses/emptyResponse" }, "400": { @@ -3430,7 +3430,7 @@ }, "description": "selfServiceRecoveryFlow" }, - "302": { + "303": { "$ref": "#/components/responses/emptyResponse" }, "400": { @@ -3533,7 +3533,7 @@ }, "/self-service/registration": { "post": { - "description": "Use this endpoint to complete a registration flow by sending an identity's traits and password. This endpoint\nbehaves differently for API and browser flows.\n\nAPI flows expect `application/json` to be sent in the body and respond with\nHTTP 200 and a application/json body with the created identity success - if the session hook is configured the\n`session` and `session_token` will also be included;\nHTTP 302 redirect to a fresh registration flow if the original flow expired with the appropriate error messages set;\nHTTP 400 on form validation errors.\n\nBrowser flows expect a Content-Type of `application/x-www-form-urlencoded` or `application/json` to be sent in the body and respond with\na HTTP 302 redirect to the post/after registration URL or the `return_to` value if it was set and if the registration succeeded;\na HTTP 302 redirect to the registration UI URL with the flow ID containing the validation errors otherwise.\n\nBrowser flows with an accept header of `application/json` will not redirect but instead respond with\nHTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success;\nHTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set;\nHTTP 400 on form validation errors.\n\nIf this endpoint is called with `Accept: application/json` in the header, the response contains the flow without a redirect. In the\ncase of an error, the `error.id` of the JSON response body can be one of:\n\n`session_already_available`: The user is already signed in.\n`security_csrf_violation`: Unable to fetch the flow because a CSRF violation occurred.\n`security_identity_mismatch`: The requested `?return_to` address is not allowed to be used. Adjust this in the configuration!\n`browser_location_change_required`: Usually sent when an AJAX request indicates that the browser needs to open a specific URL.\nMost likely used in Social Sign In flows.\n\nMore information can be found at [Ory Kratos User Login and User Registration Documentation](https://www.ory.sh/docs/next/kratos/self-service/flows/user-login-user-registration).", + "description": "Use this endpoint to complete a registration flow by sending an identity's traits and password. This endpoint\nbehaves differently for API and browser flows.\n\nAPI flows expect `application/json` to be sent in the body and respond with\nHTTP 200 and a application/json body with the created identity success - if the session hook is configured the\n`session` and `session_token` will also be included;\nHTTP 303 redirect to a fresh registration flow if the original flow expired with the appropriate error messages set;\nHTTP 400 on form validation errors.\n\nBrowser flows expect a Content-Type of `application/x-www-form-urlencoded` or `application/json` to be sent in the body and respond with\na HTTP 303 redirect to the post/after registration URL or the `return_to` value if it was set and if the registration succeeded;\na HTTP 303 redirect to the registration UI URL with the flow ID containing the validation errors otherwise.\n\nBrowser flows with an accept header of `application/json` will not redirect but instead respond with\nHTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success;\nHTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set;\nHTTP 400 on form validation errors.\n\nIf this endpoint is called with `Accept: application/json` in the header, the response contains the flow without a redirect. In the\ncase of an error, the `error.id` of the JSON response body can be one of:\n\n`session_already_available`: The user is already signed in.\n`security_csrf_violation`: Unable to fetch the flow because a CSRF violation occurred.\n`security_identity_mismatch`: The requested `?return_to` address is not allowed to be used. Adjust this in the configuration!\n`browser_location_change_required`: Usually sent when an AJAX request indicates that the browser needs to open a specific URL.\nMost likely used in Social Sign In flows.\n\nMore information can be found at [Ory Kratos User Login and User Registration Documentation](https://www.ory.sh/docs/next/kratos/self-service/flows/user-login-user-registration).", "operationId": "submitSelfServiceRegistrationFlow", "parameters": [ { @@ -3572,7 +3572,7 @@ }, "description": "successfulSelfServiceRegistrationWithoutBrowser" }, - "302": { + "303": { "$ref": "#/components/responses/emptyResponse" }, "400": { @@ -3679,7 +3679,7 @@ }, "description": "selfServiceRegistrationFlow" }, - "302": { + "303": { "$ref": "#/components/responses/emptyResponse" }, "500": { @@ -3782,7 +3782,7 @@ }, "/self-service/settings": { "post": { - "description": "Use this endpoint to complete a settings flow by sending an identity's updated password. This endpoint\nbehaves differently for API and browser flows.\n\nAPI-initiated flows expect `application/json` to be sent in the body and respond with\nHTTP 200 and an application/json body with the session token on success;\nHTTP 302 redirect to a fresh settings flow if the original flow expired with the appropriate error messages set;\nHTTP 400 on form validation errors.\nHTTP 401 when the endpoint is called without a valid session token.\nHTTP 403 when `selfservice.flows.settings.privileged_session_max_age` was reached or the session's AAL is too low.\nImplies that the user needs to re-authenticate.\n\nBrowser flows without HTTP Header `Accept` or with `Accept: text/*` respond with\na HTTP 302 redirect to the post/after settings URL or the `return_to` value if it was set and if the flow succeeded;\na HTTP 302 redirect to the Settings UI URL with the flow ID containing the validation errors otherwise.\na HTTP 302 redirect to the login endpoint when `selfservice.flows.settings.privileged_session_max_age` was reached or the session's AAL is too low.\n\nBrowser flows with HTTP Header `Accept: application/json` respond with\nHTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success;\nHTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set;\nHTTP 401 when the endpoint is called without a valid session cookie.\nHTTP 403 when the page is accessed without a session cookie or the session's AAL is too low.\nHTTP 400 on form validation errors.\n\nDepending on your configuration this endpoint might return a 403 error if the session has a lower Authenticator\nAssurance Level (AAL) than is possible for the identity. This can happen if the identity has password + webauthn\ncredentials (which would result in AAL2) but the session has only AAL1. If this error occurs, ask the user\nto sign in with the second factor (happens automatically for server-side browser flows) or change the configuration.\n\nIf this endpoint is called with a `Accept: application/json` HTTP header, the response contains the flow without a redirect. In the\ncase of an error, the `error.id` of the JSON response body can be one of:\n\n`session_refresh_required`: The identity requested to change something that needs a privileged session. Redirect\nthe identity to the login init endpoint with query parameters `?refresh=true\u0026return_to=\u003cthe-current-browser-url\u003e`,\nor initiate a refresh login flow otherwise.\n`security_csrf_violation`: Unable to fetch the flow because a CSRF violation occurred.\n`session_inactive`: No Ory Session was found - sign in a user first.\n`security_identity_mismatch`: The flow was interrupted with `session_refresh_required` but apparently some other\nidentity logged in instead.\n`security_identity_mismatch`: The requested `?return_to` address is not allowed to be used. Adjust this in the configuration!\n`browser_location_change_required`: Usually sent when an AJAX request indicates that the browser needs to open a specific URL.\nMost likely used in Social Sign In flows.\n\nMore information can be found at [Ory Kratos User Settings \u0026 Profile Management Documentation](../self-service/flows/user-settings).", + "description": "Use this endpoint to complete a settings flow by sending an identity's updated password. This endpoint\nbehaves differently for API and browser flows.\n\nAPI-initiated flows expect `application/json` to be sent in the body and respond with\nHTTP 200 and an application/json body with the session token on success;\nHTTP 303 redirect to a fresh settings flow if the original flow expired with the appropriate error messages set;\nHTTP 400 on form validation errors.\nHTTP 401 when the endpoint is called without a valid session token.\nHTTP 403 when `selfservice.flows.settings.privileged_session_max_age` was reached or the session's AAL is too low.\nImplies that the user needs to re-authenticate.\n\nBrowser flows without HTTP Header `Accept` or with `Accept: text/*` respond with\na HTTP 303 redirect to the post/after settings URL or the `return_to` value if it was set and if the flow succeeded;\na HTTP 303 redirect to the Settings UI URL with the flow ID containing the validation errors otherwise.\na HTTP 303 redirect to the login endpoint when `selfservice.flows.settings.privileged_session_max_age` was reached or the session's AAL is too low.\n\nBrowser flows with HTTP Header `Accept: application/json` respond with\nHTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success;\nHTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set;\nHTTP 401 when the endpoint is called without a valid session cookie.\nHTTP 403 when the page is accessed without a session cookie or the session's AAL is too low.\nHTTP 400 on form validation errors.\n\nDepending on your configuration this endpoint might return a 403 error if the session has a lower Authenticator\nAssurance Level (AAL) than is possible for the identity. This can happen if the identity has password + webauthn\ncredentials (which would result in AAL2) but the session has only AAL1. If this error occurs, ask the user\nto sign in with the second factor (happens automatically for server-side browser flows) or change the configuration.\n\nIf this endpoint is called with a `Accept: application/json` HTTP header, the response contains the flow without a redirect. In the\ncase of an error, the `error.id` of the JSON response body can be one of:\n\n`session_refresh_required`: The identity requested to change something that needs a privileged session. Redirect\nthe identity to the login init endpoint with query parameters `?refresh=true\u0026return_to=\u003cthe-current-browser-url\u003e`,\nor initiate a refresh login flow otherwise.\n`security_csrf_violation`: Unable to fetch the flow because a CSRF violation occurred.\n`session_inactive`: No Ory Session was found - sign in a user first.\n`security_identity_mismatch`: The flow was interrupted with `session_refresh_required` but apparently some other\nidentity logged in instead.\n`security_identity_mismatch`: The requested `?return_to` address is not allowed to be used. Adjust this in the configuration!\n`browser_location_change_required`: Usually sent when an AJAX request indicates that the browser needs to open a specific URL.\nMost likely used in Social Sign In flows.\n\nMore information can be found at [Ory Kratos User Settings \u0026 Profile Management Documentation](../self-service/flows/user-settings).", "operationId": "submitSelfServiceSettingsFlow", "parameters": [ { @@ -3829,7 +3829,7 @@ }, "description": "selfServiceSettingsFlow" }, - "302": { + "303": { "$ref": "#/components/responses/emptyResponse" }, "400": { @@ -3971,7 +3971,7 @@ }, "description": "selfServiceSettingsFlow" }, - "302": { + "303": { "$ref": "#/components/responses/emptyResponse" }, "400": { @@ -4122,7 +4122,7 @@ }, "/self-service/verification": { "post": { - "description": "Use this endpoint to complete a verification flow. This endpoint\nbehaves differently for API and browser flows and has several states:\n\n`choose_method` expects `flow` (in the URL query) and `email` (in the body) to be sent\nand works with API- and Browser-initiated flows.\nFor API clients and Browser clients with HTTP Header `Accept: application/json` it either returns a HTTP 200 OK when the form is valid and HTTP 400 OK when the form is invalid\nand a HTTP 302 Found redirect with a fresh verification flow if the flow was otherwise invalid (e.g. expired).\nFor Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 302 Found redirect to the Verification UI URL with the Verification Flow ID appended.\n`sent_email` is the success state after `choose_method` when using the `link` method and allows the user to request another verification email. It\nworks for both API and Browser-initiated flows and returns the same responses as the flow in `choose_method` state.\n`passed_challenge` expects a `token` to be sent in the URL query and given the nature of the flow (\"sending a verification link\")\ndoes not have any API capabilities. The server responds with a HTTP 302 Found redirect either to the Settings UI URL\n(if the link was valid) and instructs the user to update their password, or a redirect to the Verification UI URL with\na new Verification Flow ID which contains an error message that the verification link was invalid.\n\nMore information can be found at [Ory Kratos Email and Phone Verification Documentation](https://www.ory.sh/docs/kratos/selfservice/flows/verify-email-account-activation).", + "description": "Use this endpoint to complete a verification flow. This endpoint\nbehaves differently for API and browser flows and has several states:\n\n`choose_method` expects `flow` (in the URL query) and `email` (in the body) to be sent\nand works with API- and Browser-initiated flows.\nFor API clients and Browser clients with HTTP Header `Accept: application/json` it either returns a HTTP 200 OK when the form is valid and HTTP 400 OK when the form is invalid\nand a HTTP 303 See Other redirect with a fresh verification flow if the flow was otherwise invalid (e.g. expired).\nFor Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 303 See Other redirect to the Verification UI URL with the Verification Flow ID appended.\n`sent_email` is the success state after `choose_method` when using the `link` method and allows the user to request another verification email. It\nworks for both API and Browser-initiated flows and returns the same responses as the flow in `choose_method` state.\n`passed_challenge` expects a `token` to be sent in the URL query and given the nature of the flow (\"sending a verification link\")\ndoes not have any API capabilities. The server responds with a HTTP 303 See Other redirect either to the Settings UI URL\n(if the link was valid) and instructs the user to update their password, or a redirect to the Verification UI URL with\na new Verification Flow ID which contains an error message that the verification link was invalid.\n\nMore information can be found at [Ory Kratos Email and Phone Verification Documentation](https://www.ory.sh/docs/kratos/selfservice/flows/verify-email-account-activation).", "operationId": "submitSelfServiceVerificationFlow", "parameters": [ { @@ -4169,7 +4169,7 @@ }, "description": "selfServiceVerificationFlow" }, - "302": { + "303": { "$ref": "#/components/responses/emptyResponse" }, "400": { @@ -4266,7 +4266,7 @@ }, "description": "selfServiceVerificationFlow" }, - "302": { + "303": { "$ref": "#/components/responses/emptyResponse" }, "500": { diff --git a/spec/swagger.json b/spec/swagger.json index f52b0d92db11..d40b48aa22c5 100755 --- a/spec/swagger.json +++ b/spec/swagger.json @@ -737,7 +737,7 @@ }, "/self-service/login": { "post": { - "description": ":::info\n\nThis endpoint is EXPERIMENTAL and subject to potential breaking changes in the future.\n\n:::\n\nUse this endpoint to complete a login flow. This endpoint\nbehaves differently for API and browser flows.\n\nAPI flows expect `application/json` to be sent in the body and responds with\nHTTP 200 and a application/json body with the session token on success;\nHTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set;\nHTTP 400 on form validation errors.\n\nBrowser flows expect a Content-Type of `application/x-www-form-urlencoded` or `application/json` to be sent in the body and respond with\na HTTP 302 redirect to the post/after login URL or the `return_to` value if it was set and if the login succeeded;\na HTTP 302 redirect to the login UI URL with the flow ID containing the validation errors otherwise.\n\nBrowser flows with an accept header of `application/json` will not redirect but instead respond with\nHTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success;\nHTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set;\nHTTP 400 on form validation errors.\n\nIf this endpoint is called with `Accept: application/json` in the header, the response contains the flow without a redirect. In the\ncase of an error, the `error.id` of the JSON response body can be one of:\n\n`session_already_available`: The user is already signed in.\n`security_csrf_violation`: Unable to fetch the flow because a CSRF violation occurred.\n`security_identity_mismatch`: The requested `?return_to` address is not allowed to be used. Adjust this in the configuration!\n`browser_location_change_required`: Usually sent when an AJAX request indicates that the browser needs to open a specific URL.\nMost likely used in Social Sign In flows.\n\nMore information can be found at [Ory Kratos User Login and User Registration Documentation](https://www.ory.sh/docs/next/kratos/self-service/flows/user-login-user-registration).", + "description": ":::info\n\nThis endpoint is EXPERIMENTAL and subject to potential breaking changes in the future.\n\n:::\n\nUse this endpoint to complete a login flow. This endpoint\nbehaves differently for API and browser flows.\n\nAPI flows expect `application/json` to be sent in the body and responds with\nHTTP 200 and a application/json body with the session token on success;\nHTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set;\nHTTP 400 on form validation errors.\n\nBrowser flows expect a Content-Type of `application/x-www-form-urlencoded` or `application/json` to be sent in the body and respond with\na HTTP 303 redirect to the post/after login URL or the `return_to` value if it was set and if the login succeeded;\na HTTP 303 redirect to the login UI URL with the flow ID containing the validation errors otherwise.\n\nBrowser flows with an accept header of `application/json` will not redirect but instead respond with\nHTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success;\nHTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set;\nHTTP 400 on form validation errors.\n\nIf this endpoint is called with `Accept: application/json` in the header, the response contains the flow without a redirect. In the\ncase of an error, the `error.id` of the JSON response body can be one of:\n\n`session_already_available`: The user is already signed in.\n`security_csrf_violation`: Unable to fetch the flow because a CSRF violation occurred.\n`security_identity_mismatch`: The requested `?return_to` address is not allowed to be used. Adjust this in the configuration!\n`browser_location_change_required`: Usually sent when an AJAX request indicates that the browser needs to open a specific URL.\nMost likely used in Social Sign In flows.\n\nMore information can be found at [Ory Kratos User Login and User Registration Documentation](https://www.ory.sh/docs/next/kratos/self-service/flows/user-login-user-registration).", "consumes": [ "application/json", "application/x-www-form-urlencoded" @@ -785,7 +785,7 @@ "$ref": "#/definitions/successfulSelfServiceLoginWithoutBrowser" } }, - "302": { + "303": { "$ref": "#/responses/emptyResponse" }, "400": { @@ -908,7 +908,7 @@ "$ref": "#/definitions/selfServiceLoginFlow" } }, - "302": { + "303": { "$ref": "#/responses/emptyResponse" }, "400": { @@ -992,7 +992,7 @@ }, "/self-service/logout": { "get": { - "description": "This endpoint logs out an identity in a self-service manner.\n\nIf the `Accept` HTTP header is not set to `application/json`, the browser will be redirected (HTTP 302 Found)\nto the `return_to` parameter of the initial request or fall back to `urls.default_return_to`.\n\nIf the `Accept` HTTP header is set to `application/json`, a 204 No Content response\nwill be sent on successful logout instead.\n\nThis endpoint is NOT INTENDED for API clients and only works\nwith browsers (Chrome, Firefox, ...). For API clients you can\ncall the `/self-service/logout/api` URL directly with the Ory Session Token.\n\nMore information can be found at [Ory Kratos User Logout Documentation](https://www.ory.sh/docs/next/kratos/self-service/flows/user-logout).", + "description": "This endpoint logs out an identity in a self-service manner.\n\nIf the `Accept` HTTP header is not set to `application/json`, the browser will be redirected (HTTP 303 See Other)\nto the `return_to` parameter of the initial request or fall back to `urls.default_return_to`.\n\nIf the `Accept` HTTP header is set to `application/json`, a 204 No Content response\nwill be sent on successful logout instead.\n\nThis endpoint is NOT INTENDED for API clients and only works\nwith browsers (Chrome, Firefox, ...). For API clients you can\ncall the `/self-service/logout/api` URL directly with the Ory Session Token.\n\nMore information can be found at [Ory Kratos User Logout Documentation](https://www.ory.sh/docs/next/kratos/self-service/flows/user-logout).", "produces": [ "application/json" ], @@ -1023,7 +1023,7 @@ "204": { "$ref": "#/responses/emptyResponse" }, - "302": { + "303": { "$ref": "#/responses/emptyResponse" }, "500": { @@ -1129,7 +1129,7 @@ }, "/self-service/recovery": { "post": { - "description": "Use this endpoint to complete a recovery flow. This endpoint\nbehaves differently for API and browser flows and has several states:\n\n`choose_method` expects `flow` (in the URL query) and `email` (in the body) to be sent\nand works with API- and Browser-initiated flows.\nFor API clients and Browser clients with HTTP Header `Accept: application/json` it either returns a HTTP 200 OK when the form is valid and HTTP 400 OK when the form is invalid.\nand a HTTP 302 Found redirect with a fresh recovery flow if the flow was otherwise invalid (e.g. expired).\nFor Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 302 Found redirect to the Recovery UI URL with the Recovery Flow ID appended.\n`sent_email` is the success state after `choose_method` for the `link` method and allows the user to request another recovery email. It\nworks for both API and Browser-initiated flows and returns the same responses as the flow in `choose_method` state.\n`passed_challenge` expects a `token` to be sent in the URL query and given the nature of the flow (\"sending a recovery link\")\ndoes not have any API capabilities. The server responds with a HTTP 302 Found redirect either to the Settings UI URL\n(if the link was valid) and instructs the user to update their password, or a redirect to the Recover UI URL with\na new Recovery Flow ID which contains an error message that the recovery link was invalid.\n\nMore information can be found at [Ory Kratos Account Recovery Documentation](../self-service/flows/account-recovery.mdx).", + "description": "Use this endpoint to complete a recovery flow. This endpoint\nbehaves differently for API and browser flows and has several states:\n\n`choose_method` expects `flow` (in the URL query) and `email` (in the body) to be sent\nand works with API- and Browser-initiated flows.\nFor API clients and Browser clients with HTTP Header `Accept: application/json` it either returns a HTTP 200 OK when the form is valid and HTTP 400 OK when the form is invalid.\nand a HTTP 303 See Other redirect with a fresh recovery flow if the flow was otherwise invalid (e.g. expired).\nFor Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 303 See Other redirect to the Recovery UI URL with the Recovery Flow ID appended.\n`sent_email` is the success state after `choose_method` for the `link` method and allows the user to request another recovery email. It\nworks for both API and Browser-initiated flows and returns the same responses as the flow in `choose_method` state.\n`passed_challenge` expects a `token` to be sent in the URL query and given the nature of the flow (\"sending a recovery link\")\ndoes not have any API capabilities. The server responds with a HTTP 303 See Other redirect either to the Settings UI URL\n(if the link was valid) and instructs the user to update their password, or a redirect to the Recover UI URL with\na new Recovery Flow ID which contains an error message that the recovery link was invalid.\n\nMore information can be found at [Ory Kratos Account Recovery Documentation](../self-service/flows/account-recovery.mdx).", "consumes": [ "application/json", "application/x-www-form-urlencoded" @@ -1175,7 +1175,7 @@ "$ref": "#/definitions/selfServiceRecoveryFlow" } }, - "302": { + "303": { "$ref": "#/responses/emptyResponse" }, "400": { @@ -1254,7 +1254,7 @@ "$ref": "#/definitions/selfServiceRecoveryFlow" } }, - "302": { + "303": { "$ref": "#/responses/emptyResponse" }, "400": { @@ -1332,7 +1332,7 @@ }, "/self-service/registration": { "post": { - "description": "Use this endpoint to complete a registration flow by sending an identity's traits and password. This endpoint\nbehaves differently for API and browser flows.\n\nAPI flows expect `application/json` to be sent in the body and respond with\nHTTP 200 and a application/json body with the created identity success - if the session hook is configured the\n`session` and `session_token` will also be included;\nHTTP 302 redirect to a fresh registration flow if the original flow expired with the appropriate error messages set;\nHTTP 400 on form validation errors.\n\nBrowser flows expect a Content-Type of `application/x-www-form-urlencoded` or `application/json` to be sent in the body and respond with\na HTTP 302 redirect to the post/after registration URL or the `return_to` value if it was set and if the registration succeeded;\na HTTP 302 redirect to the registration UI URL with the flow ID containing the validation errors otherwise.\n\nBrowser flows with an accept header of `application/json` will not redirect but instead respond with\nHTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success;\nHTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set;\nHTTP 400 on form validation errors.\n\nIf this endpoint is called with `Accept: application/json` in the header, the response contains the flow without a redirect. In the\ncase of an error, the `error.id` of the JSON response body can be one of:\n\n`session_already_available`: The user is already signed in.\n`security_csrf_violation`: Unable to fetch the flow because a CSRF violation occurred.\n`security_identity_mismatch`: The requested `?return_to` address is not allowed to be used. Adjust this in the configuration!\n`browser_location_change_required`: Usually sent when an AJAX request indicates that the browser needs to open a specific URL.\nMost likely used in Social Sign In flows.\n\nMore information can be found at [Ory Kratos User Login and User Registration Documentation](https://www.ory.sh/docs/next/kratos/self-service/flows/user-login-user-registration).", + "description": "Use this endpoint to complete a registration flow by sending an identity's traits and password. This endpoint\nbehaves differently for API and browser flows.\n\nAPI flows expect `application/json` to be sent in the body and respond with\nHTTP 200 and a application/json body with the created identity success - if the session hook is configured the\n`session` and `session_token` will also be included;\nHTTP 303 redirect to a fresh registration flow if the original flow expired with the appropriate error messages set;\nHTTP 400 on form validation errors.\n\nBrowser flows expect a Content-Type of `application/x-www-form-urlencoded` or `application/json` to be sent in the body and respond with\na HTTP 303 redirect to the post/after registration URL or the `return_to` value if it was set and if the registration succeeded;\na HTTP 303 redirect to the registration UI URL with the flow ID containing the validation errors otherwise.\n\nBrowser flows with an accept header of `application/json` will not redirect but instead respond with\nHTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success;\nHTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set;\nHTTP 400 on form validation errors.\n\nIf this endpoint is called with `Accept: application/json` in the header, the response contains the flow without a redirect. In the\ncase of an error, the `error.id` of the JSON response body can be one of:\n\n`session_already_available`: The user is already signed in.\n`security_csrf_violation`: Unable to fetch the flow because a CSRF violation occurred.\n`security_identity_mismatch`: The requested `?return_to` address is not allowed to be used. Adjust this in the configuration!\n`browser_location_change_required`: Usually sent when an AJAX request indicates that the browser needs to open a specific URL.\nMost likely used in Social Sign In flows.\n\nMore information can be found at [Ory Kratos User Login and User Registration Documentation](https://www.ory.sh/docs/next/kratos/self-service/flows/user-login-user-registration).", "consumes": [ "application/json", "application/x-www-form-urlencoded" @@ -1372,7 +1372,7 @@ "$ref": "#/definitions/successfulSelfServiceRegistrationWithoutBrowser" } }, - "302": { + "303": { "$ref": "#/responses/emptyResponse" }, "400": { @@ -1460,7 +1460,7 @@ "$ref": "#/definitions/selfServiceRegistrationFlow" } }, - "302": { + "303": { "$ref": "#/responses/emptyResponse" }, "500": { @@ -1543,7 +1543,7 @@ "sessionToken": [] } ], - "description": "Use this endpoint to complete a settings flow by sending an identity's updated password. This endpoint\nbehaves differently for API and browser flows.\n\nAPI-initiated flows expect `application/json` to be sent in the body and respond with\nHTTP 200 and an application/json body with the session token on success;\nHTTP 302 redirect to a fresh settings flow if the original flow expired with the appropriate error messages set;\nHTTP 400 on form validation errors.\nHTTP 401 when the endpoint is called without a valid session token.\nHTTP 403 when `selfservice.flows.settings.privileged_session_max_age` was reached or the session's AAL is too low.\nImplies that the user needs to re-authenticate.\n\nBrowser flows without HTTP Header `Accept` or with `Accept: text/*` respond with\na HTTP 302 redirect to the post/after settings URL or the `return_to` value if it was set and if the flow succeeded;\na HTTP 302 redirect to the Settings UI URL with the flow ID containing the validation errors otherwise.\na HTTP 302 redirect to the login endpoint when `selfservice.flows.settings.privileged_session_max_age` was reached or the session's AAL is too low.\n\nBrowser flows with HTTP Header `Accept: application/json` respond with\nHTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success;\nHTTP 302 redirect to a fresh login flow if the original flow expired with the appropriate error messages set;\nHTTP 401 when the endpoint is called without a valid session cookie.\nHTTP 403 when the page is accessed without a session cookie or the session's AAL is too low.\nHTTP 400 on form validation errors.\n\nDepending on your configuration this endpoint might return a 403 error if the session has a lower Authenticator\nAssurance Level (AAL) than is possible for the identity. This can happen if the identity has password + webauthn\ncredentials (which would result in AAL2) but the session has only AAL1. If this error occurs, ask the user\nto sign in with the second factor (happens automatically for server-side browser flows) or change the configuration.\n\nIf this endpoint is called with a `Accept: application/json` HTTP header, the response contains the flow without a redirect. In the\ncase of an error, the `error.id` of the JSON response body can be one of:\n\n`session_refresh_required`: The identity requested to change something that needs a privileged session. Redirect\nthe identity to the login init endpoint with query parameters `?refresh=true\u0026return_to=\u003cthe-current-browser-url\u003e`,\nor initiate a refresh login flow otherwise.\n`security_csrf_violation`: Unable to fetch the flow because a CSRF violation occurred.\n`session_inactive`: No Ory Session was found - sign in a user first.\n`security_identity_mismatch`: The flow was interrupted with `session_refresh_required` but apparently some other\nidentity logged in instead.\n`security_identity_mismatch`: The requested `?return_to` address is not allowed to be used. Adjust this in the configuration!\n`browser_location_change_required`: Usually sent when an AJAX request indicates that the browser needs to open a specific URL.\nMost likely used in Social Sign In flows.\n\nMore information can be found at [Ory Kratos User Settings \u0026 Profile Management Documentation](../self-service/flows/user-settings).", + "description": "Use this endpoint to complete a settings flow by sending an identity's updated password. This endpoint\nbehaves differently for API and browser flows.\n\nAPI-initiated flows expect `application/json` to be sent in the body and respond with\nHTTP 200 and an application/json body with the session token on success;\nHTTP 303 redirect to a fresh settings flow if the original flow expired with the appropriate error messages set;\nHTTP 400 on form validation errors.\nHTTP 401 when the endpoint is called without a valid session token.\nHTTP 403 when `selfservice.flows.settings.privileged_session_max_age` was reached or the session's AAL is too low.\nImplies that the user needs to re-authenticate.\n\nBrowser flows without HTTP Header `Accept` or with `Accept: text/*` respond with\na HTTP 303 redirect to the post/after settings URL or the `return_to` value if it was set and if the flow succeeded;\na HTTP 303 redirect to the Settings UI URL with the flow ID containing the validation errors otherwise.\na HTTP 303 redirect to the login endpoint when `selfservice.flows.settings.privileged_session_max_age` was reached or the session's AAL is too low.\n\nBrowser flows with HTTP Header `Accept: application/json` respond with\nHTTP 200 and a application/json body with the signed in identity and a `Set-Cookie` header on success;\nHTTP 303 redirect to a fresh login flow if the original flow expired with the appropriate error messages set;\nHTTP 401 when the endpoint is called without a valid session cookie.\nHTTP 403 when the page is accessed without a session cookie or the session's AAL is too low.\nHTTP 400 on form validation errors.\n\nDepending on your configuration this endpoint might return a 403 error if the session has a lower Authenticator\nAssurance Level (AAL) than is possible for the identity. This can happen if the identity has password + webauthn\ncredentials (which would result in AAL2) but the session has only AAL1. If this error occurs, ask the user\nto sign in with the second factor (happens automatically for server-side browser flows) or change the configuration.\n\nIf this endpoint is called with a `Accept: application/json` HTTP header, the response contains the flow without a redirect. In the\ncase of an error, the `error.id` of the JSON response body can be one of:\n\n`session_refresh_required`: The identity requested to change something that needs a privileged session. Redirect\nthe identity to the login init endpoint with query parameters `?refresh=true\u0026return_to=\u003cthe-current-browser-url\u003e`,\nor initiate a refresh login flow otherwise.\n`security_csrf_violation`: Unable to fetch the flow because a CSRF violation occurred.\n`session_inactive`: No Ory Session was found - sign in a user first.\n`security_identity_mismatch`: The flow was interrupted with `session_refresh_required` but apparently some other\nidentity logged in instead.\n`security_identity_mismatch`: The requested `?return_to` address is not allowed to be used. Adjust this in the configuration!\n`browser_location_change_required`: Usually sent when an AJAX request indicates that the browser needs to open a specific URL.\nMost likely used in Social Sign In flows.\n\nMore information can be found at [Ory Kratos User Settings \u0026 Profile Management Documentation](../self-service/flows/user-settings).", "consumes": [ "application/json", "application/x-www-form-urlencoded" @@ -1589,7 +1589,7 @@ "$ref": "#/definitions/selfServiceSettingsFlow" } }, - "302": { + "303": { "$ref": "#/responses/emptyResponse" }, "400": { @@ -1694,7 +1694,7 @@ "$ref": "#/definitions/selfServiceSettingsFlow" } }, - "302": { + "303": { "$ref": "#/responses/emptyResponse" }, "400": { @@ -1802,7 +1802,7 @@ }, "/self-service/verification": { "post": { - "description": "Use this endpoint to complete a verification flow. This endpoint\nbehaves differently for API and browser flows and has several states:\n\n`choose_method` expects `flow` (in the URL query) and `email` (in the body) to be sent\nand works with API- and Browser-initiated flows.\nFor API clients and Browser clients with HTTP Header `Accept: application/json` it either returns a HTTP 200 OK when the form is valid and HTTP 400 OK when the form is invalid\nand a HTTP 302 Found redirect with a fresh verification flow if the flow was otherwise invalid (e.g. expired).\nFor Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 302 Found redirect to the Verification UI URL with the Verification Flow ID appended.\n`sent_email` is the success state after `choose_method` when using the `link` method and allows the user to request another verification email. It\nworks for both API and Browser-initiated flows and returns the same responses as the flow in `choose_method` state.\n`passed_challenge` expects a `token` to be sent in the URL query and given the nature of the flow (\"sending a verification link\")\ndoes not have any API capabilities. The server responds with a HTTP 302 Found redirect either to the Settings UI URL\n(if the link was valid) and instructs the user to update their password, or a redirect to the Verification UI URL with\na new Verification Flow ID which contains an error message that the verification link was invalid.\n\nMore information can be found at [Ory Kratos Email and Phone Verification Documentation](https://www.ory.sh/docs/kratos/selfservice/flows/verify-email-account-activation).", + "description": "Use this endpoint to complete a verification flow. This endpoint\nbehaves differently for API and browser flows and has several states:\n\n`choose_method` expects `flow` (in the URL query) and `email` (in the body) to be sent\nand works with API- and Browser-initiated flows.\nFor API clients and Browser clients with HTTP Header `Accept: application/json` it either returns a HTTP 200 OK when the form is valid and HTTP 400 OK when the form is invalid\nand a HTTP 303 See Other redirect with a fresh verification flow if the flow was otherwise invalid (e.g. expired).\nFor Browser clients without HTTP Header `Accept` or with `Accept: text/*` it returns a HTTP 303 See Other redirect to the Verification UI URL with the Verification Flow ID appended.\n`sent_email` is the success state after `choose_method` when using the `link` method and allows the user to request another verification email. It\nworks for both API and Browser-initiated flows and returns the same responses as the flow in `choose_method` state.\n`passed_challenge` expects a `token` to be sent in the URL query and given the nature of the flow (\"sending a verification link\")\ndoes not have any API capabilities. The server responds with a HTTP 303 See Other redirect either to the Settings UI URL\n(if the link was valid) and instructs the user to update their password, or a redirect to the Verification UI URL with\na new Verification Flow ID which contains an error message that the verification link was invalid.\n\nMore information can be found at [Ory Kratos Email and Phone Verification Documentation](https://www.ory.sh/docs/kratos/selfservice/flows/verify-email-account-activation).", "consumes": [ "application/json", "application/x-www-form-urlencoded" @@ -1848,7 +1848,7 @@ "$ref": "#/definitions/selfServiceVerificationFlow" } }, - "302": { + "303": { "$ref": "#/responses/emptyResponse" }, "400": { @@ -1927,7 +1927,7 @@ "$ref": "#/definitions/selfServiceVerificationFlow" } }, - "302": { + "303": { "$ref": "#/responses/emptyResponse" }, "500": {