Cypress: Incorrect redirect to malformed url within AUT - adding `_/` in url

[hhudson]

Current behavior:

When I instruct cypress to login to an Oracle APEX application, the authentication re-directs cypress to a '404 not found' page because the authenticated URL is malformed. The malformed URL is the only issue and can simply corrected programmatically (with a find and replace command).

However - it is very important to note that the cypress login correctly returns:

1. a valid cookie
2. a valid session

which is everything you need for authentication.

Desired behavior:

Cypress, ideally, should be able to follow the same authentication redirect that a user would in a regular browser.

Steps to reproduce: (app code and test code)

I created a dummy application with dummy credentials hosted by apex.oracle.com to demonstrate:

it('Login demo', function() {
    cy.visit('https://apex.oracle.com/pls/apex/f?p=54707:LOGIN_DESKTOP')
    cy.get('#P9999_USERNAME').type('ApexUser')
    cy.get('#P9999_PASSWORD').type('Oradoc_db1')
    cy.get('.t-Button').click()
  })

The above code (which should work until the application expires in many months) will redirect to a 404 not found page with a url in the format:
https://apex.oracle.com/__/f?p=54707:1:[session_id]:::::
Outside of cypress the url will have the format:
https://apex.oracle.com/pls/apex/f?p=54707:1:[session_id]:::::

Versions

I have tested this across 4 instances of Oracle APEX (APEX 5.0, 5.1, 18.1 and 19) and this behavior is consistent.

[MaikMichel]

I face the same problem. But only when using chromium. If I use elektron, it works.

[hhudson]

I face the same problem. But only when using chromium. If I use elektron, it works.

That is very good to know. Just teste on Electron 59 to confirm that this works for my case as well. Thank you, @MaikMichel

[jennifer-shehane]

Another issue where 404 is returned due to malformed url containing /_/ https://github.com/cypress-io/cypress/issues/4472

[jennifer-shehane]

I can recreate this issue from the original code provided in the main comment. This is still happening in 3.3.2 pre-release version.

[jennifer-shehane]

Since this issue only exhibits itself within Chrome - we figure it is a change in Chrome that caused this issue to happen in Cypress. I also assume it is not a bug, as the issue still persists in version 77. It may be an intended change in behavior.

Narrowing down the version of Chrome that it was introduced, it was introduce in version 71.0.3572.0, specifically between commits 7e3da6dc3d7cd7eb8a55ef301026fe1ab737f814 and 56dd83c9005f68d55ddbf85c551759526b4e37cd:

• Chrome 61.0.3163.100 - PASSES
• Chrome 69.0.3452.0 - PASSES
• Chrome 71.0.3572.0 - PASSES = Base = 597039 7e3da6dc3d7cd7eb8a55ef301026fe1ab737f814
• Chrome 71.0.3572.0 - FAILS = Base = 597057 56dd83c9005f68d55ddbf85c551759526b4e37cd
• Chrome 72.0.3583.0 - FAILS
• Chrome 73.0.3683.0 - FAILS
• Chrome 74.0.3729.0 - FAILS
• Chrome 77.0.3833.0 - FAILS

⭐️ Changelog where issue was introduced

@flotwig good luck 😅

[hhudson]

Wanted to check back in and confirm that the issue has been resolved in the Chrome 77 browser. Thanks!

[drumbeg]

Issue now present in Cypress 3.5.0 when using Electron.

[drumbeg]

Please re-open this issue. It is apparent in Electron 73 that ships with Cypress 3.5.0.

[flotwig]

Re-opening since others are still running in to this: https://github.com/cypress-io/cypress/issues/5442

[hhudson]

With the new 3.6.0 update, the problem has both regressed and gotten worse, unfortunately. This behavior manifests in both the electron and chrome browsers (when I 1st opened this issue, the issue was restricted to the chrome browser)

[drumbeg]

With the new 3.6.0 update, the problem has both regressed and gotten worse, unfortunately. This behavior manifests in _both_ the electron and chrome browsers (when I 1st opened this issue, the issue was restricted to the chrome browser)

Hayden, do you have a workaround for the issue? I noticed you mentioned programatically replacing part of the url. I'm trying to get this to work, but no luck yet.

[hhudson]

With the new 3.6.0 update, the problem has both regressed and gotten worse, unfortunately. This behavior manifests in _both_ the electron and chrome browsers (when I 1st opened this issue, the issue was restricted to the chrome browser)

Hayden, do you have a workaround for the issue? I noticed you mentioned programatically replacing part of the url. I'm trying to get this to work, but no luck yet.

David - currently my workaround is to use Cypress version 3.4.1, which does not have this issue.

Were I to upgrade, I think I could still live with it because Cypress is technically logging in successfully, i.e. the session id is valid. Therefore, if my purpose is simply to reach pages other than the login page, I can construct a valid url using the session id (and setting the cookie, of course).

[drumbeg]

With the new 3.6.0 update, the problem has both regressed and gotten worse, unfortunately. This behavior manifests in _both_ the electron and chrome browsers (when I 1st opened this issue, the issue was restricted to the chrome browser)

Hayden, do you have a workaround for the issue? I noticed you mentioned programatically replacing part of the url. I'm trying to get this to work, but no luck yet.

David - currently my workaround is to use Cypress version 3.4.1, which does not have this issue.

Were I to upgrade, I think I could still live with it because Cypress is technically logging in successfully, i.e. the session id is valid. Therefore, if my purpose is simply to reach pages other than the login page, I can construct a valid url using the session id (and setting the cookie, of course).

How would you do this? Do you have an example? I have tried logging in and then replacing the page name in the url whilst keeping the session section whilst also preserving the cookie. I still can't get around the issue though, so if you have a working workaround I would love for you to share it.

[drumbeg]

Tested on 3.6.1. Bug is still apparent.

Was expecting 3.6.1 to contain a resolution for this, but maybe confusing issues.

Our 50 developers are keen to see a fix!

[flotwig]

@drumbeg @hhudson are either of you setting window.location.href or using window.location.replace inside of a setTimeout, setInterval, or requestAnimationFrame callback? Note: your framework may be doing this for you automatically, you may need to examine the stack trace to be sure.

[hhudson]

With the new 3.6.0 update, the problem has both regressed and gotten worse, unfortunately. This behavior manifests in _both_ the electron and chrome browsers (when I 1st opened this issue, the issue was restricted to the chrome browser)

Hayden, do you have a workaround for the issue? I noticed you mentioned programatically replacing part of the url. I'm trying to get this to work, but no luck yet.

David - currently my workaround is to use Cypress version 3.4.1, which does not have this issue.
Were I to upgrade, I think I could still live with it because Cypress is technically logging in successfully, i.e. the session id is valid. Therefore, if my purpose is simply to reach pages other than the login page, I can construct a valid url using the session id (and setting the cookie, of course).

How would you do this? Do you have an example? I have tried logging in and then replacing the page name in the url whilst keeping the session section whilst also preserving the cookie. I still can't get around the issue though, so if you have a working workaround I would love for you to share it.

Hi David - a working example (tested in 3.6) is 'Method 1' from my blog post: https://insum.ca/unit-testing-apex-3-methods-bypass-login-using-cypress-io/ . I find that clearing and setting the cookie can optimize for stability.

[hhudson]

@drumbeg @hhudson are either of you setting window.location.href or using window.location.replace inside of a setTimeout, setInterval, or requestAnimationFrame callback? Note: your framework may be doing this for you automatically, you may need to examine the stack trace to be sure.

@flotwig Can you recommend a method for examining the stack trace? I just attempted a couple of methods to examine the mechanics of the login process (APEX_DEBUG and UTL_CALL_STACK) but neither specified that level of detail.

For your reference, the original example at the top of this issue continues to demonstrate the problem:

it('Login demo', function() {
    cy.visit('https://apex.oracle.com/pls/apex/f?p=54707:LOGIN_DESKTOP')
    cy.get('#P9999_USERNAME').type('ApexUser')
    cy.get('#P9999_PASSWORD').type('Oradoc_db1')
    cy.get('.t-Button').click()
  })

[flotwig]

@hhudson If you can modify the source code, add a console.log(new Error()).stack; throw new Error(); right before the window.location.href is set. The stack trace will appear in the console, and the 2nd error will prevent the page from navigating away and clearing your console.

[drumbeg]

I had a look through the JS loaded by the framework at run-time and couldn't see window.location.href being set.

[flotwig]

@drumbeg What about window.location.replace? Sorry, the OP in this issue has window.location.href, but a similar issue affects both.

[drumbeg]

I searched for both. Could see window.location.href being referenced, but not set.

[drumbeg]

With the new 3.6.0 update, the problem has both regressed and gotten worse, unfortunately. This behavior manifests in _both_ the electron and chrome browsers (when I 1st opened this issue, the issue was restricted to the chrome browser)

Still a problem in 3.7.0.

[drumbeg]

I suspect there are two issues here.

One is the malformed URL issue.
The other is the issue of not preserving cookies in between tests.

The malformed URL issue occurs whenever we issue a redirect in our app.

[MaikMichel]

Hi, I have the same problem. Strangely enough only if I use a Nginx as reverse proxy. We have an APEX in-house app running on Apache. Here the forwarding after a login works.

Unfortunately, I don't know the basic conditions here. (Version, operating system etc.)
Maybe this will help you to find out more here.

[jennifer-shehane]

Another example from https://github.com/cypress-io/cypress/issues/5878

it('should reroute', function () {
  cy.visit('https://rahulshettyacademy.com/seleniumPractise/#/')
  cy.get('.cart-icon > img').click()
  cy.contains('PROCEED TO').click()
})

The url reroutes to the incorrect __/ url, visiting the Test Runner within the Test Runner as shown below. This behavior changed slightly over the versions, but never worked.

3.4.1 w/ Chrome 78

This one reroutes to https://rahulshettyacademy.com/seleniumPractise/__/#/cart

3.4.1 w/ Electron 61

This one reroutes to https://rahulshettyacademy.com/seleniumPractise/#/cart

3.5.0 w/ Chrome 78 or Electron 73

This one reroutes to https://rahulshettyacademy.com/seleniumPractise/__/#/cart

3.7.0 w/ Chrome 78 or Electron 73

This one reroutes to https://rahulshettyacademy.com/seleniumPractise/__/#/cart

[jennifer-shehane]

This also happens in the upcoming release of Firefox, so it seems that this being isolated to Chrome is maybe unfounded.

[jennifer-shehane]

There is an open PR meant to fix this here: https://github.com/cypress-io/cypress/pull/5273 It's complicated and is still a work in progress.

[vitodcampanelli]

Issue persists with any submission via a button (redirect). I am trying to do a find and replace on the url as suggested by @hhudson but having no luck. Would love to have this fixed soon.

[kjalen]

We're having this issue in 3.8.1 exactly as described above.
And thanks for your work on this everyone!

[pweston]

We're having this issue in 3.8.1 exactly as described above.
And thanks for your work on this everyone!

We also have this issue in 3.8.1.
In the mean time we have downgraded to 3.4.1 and running our tests using electron.
Hoping for a fix soon.

[kjalen]

Can confirm this issue is present in 3.8.2

[jwkiker]

This is still occurring in 3.8.3 with both electron and chrome.

[misterx]

This is still in 4.1.0 with electron, chrome and firefox

[cahein]

Unfortunately, 4.2.0 didn't fix the problem. Can't find a workaround either.

[leonleo997]

Does anyone know about a workaround for this problem?

[hhudson]

Does anyone know about a workaround for this problem?

I just used edit the url and redirect like so

cy.url()
      .should("contain", ":1:")
      .then(($url) => {
        loggedInPage = $url.replace("/__/", "/pls/apex/");
        cy.visit(loggedInPage); //necessary due to #redirectmalfunction
      });

An example context : https://github.com/hhudson/bypass_login_w_cypress/blob/master/cypress/integration/method1.login.js

[trips11]

The above solution somehow doesn't work for me. Any other suggestions?

[BasheerBadaha]

@jennifer-shehane Is there a workaround currently until this issue is fixed?

[cahein]

I use the following code as workaround. Replace 'xxx' as needed.

cy.window().then((win) => {
   const location = win.location.href;
   cy.visit(location.replace('__', 'xxx'));
});

[cypress-bot[bot]]

The code for this is done in cypress-io/cypress#5273, but has yet to be released.
We'll update this issue and reference the changelog when it's released.

[cypress-bot[bot]]

Released in 4.6.0.

This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v4.6.0, please open a new issue.

[flotwig]

This fix is available starting in 4.6.0 as an experiment which you can access by setting this config option in your cypress.json or elsewhere:

{
    "experimentalSourceRewriting": true
}

Please use a new issue if you are still running into issues that are not solved by this change.

[rszatkowski]

I tried to set "experimentalSourceRewriting": true and also update Cypress to version 4.6.0 but the issue still occurs.

[jennifer-shehane]

The fix is experimental, so we're hoping to still catch some situations where this _/ rerouting is not fixed before we push it without the experimental flag required.

If you're still experiencing _/ rerouting while setting the experimentalSourceRewriting to true in 4.6.0 - open a new issue with a reproducible example + screenshots, etc - filling out our issue template.

[programmiererei]

I tried to set "experimentalSourceRewriting": true and also update Cypress to version 4.7.0 but the issue still occurs with Oracle Apex 19.1

[bowens-zn]

@jennifer-shehane This error is still occuring with experimentalSourceRewriting set to true. Version 4.12.0. It only occurs when run with cypress run, not with cypress open

[jennifer-shehane]

If you're experiencing this bug still, please open a new issue with a fully reproducible example that we can run. There may be a specific edge case with the issue that we need more detail to fix.

[Yann39]

I am also facing this issue with all browsers including Electron :

• Electron
• Edge 85 (85.0.564.41)
• Chrome 85 (85.0.4183.83)
• Firefox 80 (beta)

Cypress 4.7.0
Node v8.11.3

Same after upgrading to latest versions:
Cypress 5.1.0
Node v12.18.3

it('Login page', () => {

        // visit main home page
        cy.visit('https://tstapex.myhost.ch/ords/f?p=119')

        // make sure we are redirected to login
        cy.url().should('include', 'LOGIN_DESKTOP')

        // log in
        cy.get('#P9999_USERNAME').type('username')
        cy.get('#P9999_PASSWORD').type('password')

        // click login button
        cy.get('#login-button').click();

    })

I'm redirected to https://tstapex.myhost.ch/__/f?p=119:1:28275213605974:::::

Then of course get:

Not Found
The requested URL /__/f was not found on this server.

Setting experimentalSourceRewriting to true does not help.

[gcoombe]

Are there any other workarounds? We can't use the experimental flag since apparently it breaks with react-router https://github.com/cypress-io/cypress/issues/7906 . Currently Cypress just breaks for us on a number of pages.

[intoeetive]

Not really a solution, but following approach worked for me:

cy.wait(20000);
cy.visit(my_url);