-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Redirect back to primary URL not working with cy.origin and cy.session #25289
Comments
Please note, I have also tried to use the examples for okta login from following page by creating a javascript function for login as depicted in this page https://docs.cypress.io/guides/end-to-end-testing/okta-authentication#Login-with-cy-origin however, this did not help too. |
@sksajjan Can you verify the same / all cookies have been set/sent with the login request when you compare firefox to chorme? It seems something (likely a cookie) is missing which is causing the re-direct back to the login page. There are two known cookie issues -- one calling out key-cloak and want to verify if you are seeing the same behavior or something else. |
@emilyrohrbough I have looked at both issues and they may seem to be related but I cannot confirm for sure. I have tried the workaround provided in #20476 and that did not help in my case. cy.intercept(Cypress.env('webUrl'), (req) => {
req.continue((res) => {
const value = res.headers['set-cookie'];
const setCookie = Array.isArray(value) ? value : [value];
res.headers['set-cookie'] = setCookie.map((value) =>
value.replace(/ ?Secure;?/, '').replace(/ ?SameSite=None;?/, '')
);
});
}); I have attached chrome and firefox comparison as the test executes to create a session. I do see lot of errors being shown in the console when keycloak url is accessed. I have tried to add Access-Control-Allow-Origin to the base url and that did not help too. It takes a very long time to even hit the APIs and finally, it times out RequestAndResponseDuringSessionCreation.log cy.intercept("Cypress.env('webUrl')", (req)=>{
req.headers['Access-Control-Allow-Origin'] = Cypress.env('redirectDomain')
}) |
@sksajjan any idea if we might be able to reproduce this with the keycloak docker image, kind of like in this other reproduction repository with the SAML config? |
@AtofStryker I will get back to you on this. We were able to use redirect for OKTA login successfully and still having issue with Keycloak. Please keep this issue open until some more time. |
Unfortunately we have to close this issue due to inactivity. Please comment if there is new information to provide concerning the original issue and we can reopen. |
Current behavior
The scenario is that, web application is hosted on server A, it uses keycloak SAML and that is hosted on server B (different domain). When the URL is accessed, it brings up Keycloak login page and on login with valid credentials, it navigates back to login page. Following is the code for login. Here, cy.url().should('contain', 'index.html#home') fails as it does not take user to Home page. The same exact code works fine on Firefox browser and does not work on any other browsers like chrome, electron and edge.
It appears to me that, the cookie is not being passed to the primary URL after login and hence, any further API calls to bring the home page will end in 401 return code and this appears to be leading to redirecting back to logout / login page. Or authorization itself not working within origin block and hence redirecting it back to login page. As this is working in firefox, and not on other chromium browsers, this appears to be some browser configuration issue. I have tried all options and examples provided in cypress documentation for cy.origin and cy.session() nothing actually work on all browsers.
Desired behavior
After clicking on login button, it should take control to home page and should not redirect back to the login page.
Test code to reproduce
Cypress Version
12.2.0
Node version
v18.12.1
Operating System
Windows 10 22H2 (OS build 19045.2364)
Debug Logs
Other
No response
The text was updated successfully, but these errors were encountered: