Slack Oauth Authorize Post
const url = 'https://example.com/api/auth/slack/authorize';const options = { method: 'POST', headers: {'Content-Type': 'application/json'}, body: '{"returnTo":"example"}'};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request POST \ --url https://example.com/api/auth/slack/authorize \ --header 'Content-Type: application/json' \ --data '{ "returnTo": "example" }'Initiate Slack OAuth without leaking returnTo into URLs.
The client POSTs {"returnTo": "/some/path"}. We validate it, stash it
in a short-lived HttpOnly cookie (memosa_oauth_return_to), and return
the Slack authorize URL. The client then navigates to that URL. When the
callback lands, it reads the cookie, not a URL param.
This is the preferred endpoint — the GET variant is retained for backward compatibility with cached frontend bundles during deploy.
Request Body
Section titled “Request Body ”Request body for the Slack OAuth POST initiator.
The only field is returnTo, a same-origin relative path the
browser should land on after the OAuth round-trip. Stored in a
short-lived HttpOnly cookie; _validate_safe_relative_path is the
deep guard against open-redirect / protocol-relative payloads.
Example generated
{ "returnTo": "example"}Responses
Section titled “ Responses ”Successful Response
Response from POST /auth/slack/authorize (the redirect-URL form).
object
Example generated
{ "redirect_url": "example"}Validation Error
object
object
object
Example generated
{ "detail": [ { "loc": [ "example" ], "msg": "example", "type": "example", "input": "example", "ctx": {} } ]}