I’m trying to login as another user using “Sign in as user”. When I do this, I can see my app getting a POST request to the callback url, but my app is setup (and normal logins work) with GET requests. When I change the response mode to “GET” in the advanced settings, I’m still seeing a POST request to my callback url. Can I force the impersonation page to do GET? Does anyone have a script that uses the impersonation API that I could use instead?
I could not reproduce this situation by obtaining the impersonation link from the Dashboard. I started by obtaining one with a GET response mode which worked, then switched to POST and it did a POST (which not worked because my application was also not expecting a POST) and then finally I switched again to a GET response mode and the new link generated correctly redirected with a GET.
The recommendation would be for you to try to reproduce this with a new client application (it does not need to map to anything running as you can just use the browser tools to inspect if a GET or POST is being done). If you reproduce this with a new client application created from scratch then please update the question with your exact steps to reproduce the whole issue.
I’ve created a new application but I’m not getting that as an option in the “sign in as” dropdown. I did have other applications that are offers and they do indeed submit a get request; it’s just this one application that just submits a post. Both attached to the same database, both set up as a “REGULAR WEB APPLICATION”.
I do see one difference; the one that works offers me a choice between “Server side app” and “Client side app”; the one which doesn’t work only offers me “Server side app”.
(verified in the JS console for both cases BTW)
I’ve created a new application but I’m not getting that as an option in the “sign in as” dropdown. I did have other applications that are offers and they do indeed submit a get request; it’s just this one application that just submits a post. Both attached to the same database, both set up as a “REGULAR WEB APPLICATION”.
I do see one difference; the one that works offers me a choice between “Server side app” and “Client side app”; the one which doesn’t work only offers me “Server side app”.
(verified in the JS console for both cases BTW)
That is indeed useful and intriguing information, but it does explain why I could not reproduce as the situation is tied to a particular client application. I’ll try to see what I come up with in terms of possibilities.
That behavior seems to be caused by enabling the SAML addon for the client application as impersonation will now try to perform an IdP-Initiated SAML login and as far as I’m aware the spec mandates that request is a POST request. When the client application is using OIDC/OAuth2-based authentication then the request can either be a GET or POST because the specification allows for it, but that it’s not the case with SAML. If that application is really meant to be using SAML, then it needs to handle the POST.
That would explain part of the problem – I did recently enable the SAML addon. But I would have expected the POST-enforced behavior to be tied to the SAML URL – I’m getting the POST-enforcement regardless of callback url I select in the “sign in as user” dialog.
I solved it by creating a separate client for the SAML login – everything works as expected now. Thanks for the pointer!