Is your feature request related to a problem? Please describe.
This feature request will solve a problem we're currently experiencing when the SSO is used for a cross-origin backend server.
Suppose you have the following
api.example.com - This is an API server
app.example.com - This is a web app that performs cross-origin requests to api.example.com
Both are placed behind the SSO proxy. Thus, in order for any requests to be performed to api.example.com, the user must already be signed into the sso-auth service.
The issue is when app.example.com is loaded for the first time, the following occurs
Request to app.example.com is sent to sso-proxy, the user is not authenticated, so is sent to the SSO sign in page
After the user signs in successfully, they are redirected back to app.example.com where the HTML page is successfully sent to the browser and the web app begins to render
During rendering, the web app (app.example.com) sends a cross-origin request to api.example.com. As the user has never loaded api.example.com, there is no session cookie for that request and is thus redirected to sso-auth
This is where the problem occurs, ideally what happens is
sso-auth sees that the user is already signed in and will redirect them back to api.example.com with the session cookie
But what occurs is
The request to sso-auth is blocked by the browser, as the preflight response from api.example.com (which is performed by sso-auth) does not include the appropriate Access-Control-Allow-Origin header.
Describe the solution you'd like
There's many possible solutions to this, from more general to specific we can
Add the ability to configure headers to add to all sso-auth redirects through environment variables
Add the ability to configure headers to add to all preflight requests to sso-auth through environment variables
Add the ability to configure the Access-Control-Allow-Origin for the redirect responses by sso-auth
Describe alternatives you've considered
All alternatives are also described above. The currently workaround is to directly visit api.example.com before visiting app.example.com, so the session cookie is set for when app.example.com sends a request to api.example.com.
Additional context
Add any other context or screenshots about the feature request here.
Is your feature request related to a problem? Please describe. This feature request will solve a problem we're currently experiencing when the SSO is used for a cross-origin backend server.
Suppose you have the following api.example.com - This is an API server app.example.com - This is a web app that performs cross-origin requests to api.example.com
Both are placed behind the SSO proxy. Thus, in order for any requests to be performed to api.example.com, the user must already be signed into the sso-auth service.
The issue is when app.example.com is loaded for the first time, the following occurs
This is where the problem occurs, ideally what happens is
But what occurs is
Access-Control-Allow-Originheader.Describe the solution you'd like There's many possible solutions to this, from more general to specific we can
Access-Control-Allow-Originfor the redirect responses by sso-authDescribe alternatives you've considered All alternatives are also described above. The currently workaround is to directly visit api.example.com before visiting app.example.com, so the session cookie is set for when app.example.com sends a request to api.example.com.
Additional context Add any other context or screenshots about the feature request here.