Request initiated in one app being responded to from another.
jbrodie opened this issue · comments
For context, this works fine within Invoker.
Making the transition from invoker to overmind and this process works as expected when running with invoker. I have removed the invoker install and have installed overmind with puma-dev as the replacement.
I have 2 apps running from one Procfile.
app1: echo $PORT > ~/.puma-dev/app1 && env RUBY_DEBUG_OPEN=true bin/rails s --port $PORT
app2: echo $PORT > ~/.puma-dev/app2 && cd ~/app2/ && env RUBY_DEBUG_OPEN=true bin/rails s --port $PORT
These are setup through overmind
Lets call them app1 and app2.
They both start and are responsive on their associated names, app1.test and app2.test.
But once I initiate a SSO SAML login from app1 the response is picked up and processed from app2.
This is all in the same process so the ports don't change.
app1 | Started GET "/auth/saml" for 127.0.0.1 at 2024-04-02 14:48:27 -0400
app1 | I, [2024-04-02T14:48:27.496080 #51144] INFO -- omniauth: (saml) Request phase initiated.
app2 | Started POST "/auth/saml/callback" for 127.0.0.1 at 2024-04-02 14:48:27 -0400
app2 | I, [2024-04-02T14:48:28.053204 #51136] INFO -- omniauth: (saml) Callback phase initiated.
app2 | I, [2024-04-02T14:48:28.077165 #51136] INFO -- omniauth: (saml) Callback phase initiated.
app2 | Processing by OmniauthCallbacksController#saml as HTML
app2 | Parameters: {"SAMLResponse"=>"PHNhbWxwOlJlc3BvbnNlIElEPSJfM2E1ODVjYzAtNzE5MS00YWE3LWIyMTMtNTAwYmUzNGJhMz
The directing to an app is done solely via hostname. Can you verify where the SAML login redirects you to?
Yes, I have confirmed, the SAML redirect is 100% accurate. When running the same combination of sites, through invoker, the results are as expected.
I am confused by this as well. I am not sure how this is confusing the callback on it.
Update:
Through further testing, overmind was being started with puma-dev from the directory of app1. This was causing the redirect to come back to that app for some reason.
I moved the Procfile out to neutral territory (the directory containing the 2 app folders, and updated the Procfile to cd to the proper directory before starting), and started, and the redirect back seems to work.
Not sure on this.
I am going to reverse the tables tomorrow and see if starting from app2 will cause same callback for app1 to respond to app2 instead.
Update:
I have reversed the configurations, and booted the Procfile from app2 and then tried to SSO SAML into app1, and the results are the same, it sends the response for the SSO SAML to app2 rather than app1.
Almost looks like there is some defined default, as when I bring the procfile up from outside of the application folder, things seem to work normally.